Сеть TCP/IP и набор команд ip¶

Утилиты ifconfig/route/arp, которые вы найдёте в старых руководствах, устарели, и во многих современных дистрибутивах даже не установлены по умолчанию. Всё, что они делали, теперь делает одна команда: ip, часть пакета iproute2.

Как это устроено¶

Интерфейсы и адреса¶

$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.0.2.10/24 fe80::21a:4aff:fe9a:1b2c/64
eth1             UP             10.0.0.5/24 fe80::21a:4aff:fe9a:1b2d/64
docker0          DOWN           172.17.0.1/16

-br («brief») даёт сводку по одной строке на интерфейс: имя, операционное состояние (UP/ DOWN/UNKNOWN — UNKNOWN нормально для loopback, это просто означает, что ядро не отслеживает для него состояние несущей), и назначенные адреса (IPv4 и IPv6 вместе).

Добавление/удаление адреса вручную (полезно для диагностики — это не сохраняется после перезагрузки, для этого нужно настраивать через netplan/NetworkManager//etc/network/interfaces):

sudo ip addr add 192.0.2.20/24 dev eth0
sudo ip addr del 192.0.2.20/24 dev eth0

Маршрутизация¶

$ ip route show
default via 192.0.2.1 dev eth0 proto dhcp src 192.0.2.10 metric 100
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.5
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.10

Читайте концептуально снизу вверх: ядро сначала ищет наиболее конкретное совпадение (longest prefix match), и только если ничего более конкретного не подошло, использует default. Хост с двумя интерфейсами (как в примере — один в 192.0.2.0/24, другой в 10.0.0.0/24) автоматически направляет трафик для каждой подсети через свой интерфейс, а всё остальное идёт через default.

metric важен, когда существует несколько default-маршрутов (обычно на мультихоумед-хостах, или хостах с проводным соединением и VPN одновременно): меньший metric побеждает как предпочитаемый маршрут.

sudo ip route add 203.0.113.0/24 via 192.0.2.1 dev eth0
sudo ip route del 203.0.113.0/24
sudo ip route add default via 192.0.2.1 dev eth0 metric 50   # сделать этот маршрут предпочитаемым по умолчанию

Проверка связности по уровням¶

Когда «сеть сломана», двигайтесь вверх по стеку, а не гадайте:

ip link show eth0                 # 1. Интерфейс вообще физически поднят?
ip addr show eth0                 # 2. У него тот адрес, что вы ожидаете?
ip route get 8.8.8.8              # 3. Какой маршрут/интерфейс будет использован до цели?
ping -c 3 192.0.2.1                # 4. Доступен ли шлюз по умолчанию вообще?
ping -c 3 8.8.8.8                  # 5. Доступен ли интернет по IP (исключает DNS)?
curl -v https://example.com        # 6. Проходит ли полный обмен TCP+TLS+HTTP?

ip route get <ip> недооценён и очень полезен — он не отправляет никакого трафика, а просто спрашивает у таблицы маршрутизации ядра, какой интерфейс/шлюз/исходный адрес были бы использованы, чего часто достаточно, чтобы заметить неверно настроенный маршрут, не генерируя ни одного реального пакета.

Наблюдение за живыми соединениями¶

ss -tulnp

-t TCP, -u UDP, -l только слушающие сокеты, -n числовой вывод (пропускает медленные DNS/service-name lookups), -p показать владеющий процесс (нужен root для чужих процессов). Это современная замена netstat -tulnp, который устарел так же, как ifconfig.

Различия Ubuntu/Debian и RHEL-подобных систем¶

Сам ip идентичен. Различается уровень постоянной конфигурации:

	Ubuntu/Debian	RHEL-подобные
Инструмент конфигурации	netplan (YAML), генерирующий конфиг для systemd-networkd или NetworkManager	NetworkManager (`nmcli`, `/etc/sysconfig/network-scripts/` на старых релизах, keyfiles на новых)
Применить конфиг	`sudo netplan apply`	`sudo nmcli connection reload` / `nmcli con up <name>`

Практическое задание¶

Выполните ip -br addr show и определите, у какого интерфейса есть default-маршрут (сверьтесь с ip route show).
Выполните ip route get 1.1.1.1 и убедитесь, что указанный интерфейс совпадает с default маршрутом.
Временно добавьте второй адрес на некритичный интерфейс, подтвердите через ip -br addr show, затем удалите его обратно через ip addr del.

Как проверить, что всё сделано правильно¶

После добавления адреса ip -br addr show <iface> должен перечислить и исходный, и новый адрес в одной строке.
После ip addr del он должен исчезнуть, никак не повлияв на исходный адрес или таблицу маршрутов.

Типичные ошибки¶

Забыть, что изменения ip addr add/route add не переживают перезагрузку. Они только runtime; постоянная конфигурация всегда идёт через систему конфигурации дистрибутива (netplan, NetworkManager, /etc/network/interfaces).
Диагностика проблем с DNS через ping <hostname> без предварительной проверки ping <ip> — если пинг по IP тоже не проходит, проблема вообще не в DNS, а в маршрутизации/ связности, и погоня за конфигом DNS в первую очередь тратит время впустую.
Предположение, что UP в ip link show означает «работает». Это означает, что административное состояние поднято — несущая (кабель вставлен, линк согласован) — отдельный флаг LOWER_UP, видимый в полном (не -br) выводе ip link show.

⚠ Опасные команды¶

ip addr flush dev <iface> мгновенно удаляет все адреса с интерфейса, включая тот, через который вы сейчас подключены по SSH — выполнение этого на единственном доступном интерфейсе удалённого бокса немедленно отрезает вас, без локальной консоли. Если нужно сбросить адреса на удалённом хосте, сначала обеспечьте доступ вне полосы (консоль/IPMI).
ip route del default в той же удалённой сессии, что идёт через этот маршрут, обрывает соединение раньше, чем команда успеет вернуть результат.

Связанные статьи¶

Разрешение DNS и диагностика

Контрольные вопросы¶

Что контролирует значение metric маршрута, и когда оно имеет значение?
Почему ip route get <ip> безопасно запускать на продакшн-системе, хотя она и описывается как «маршрутизирующая» команда?
В чём практическая разница между интерфейсом в состоянии UP административно и наличием LOWER_UP (несущей)?
Почему стоит проверять ping <ip> раньше ping <hostname> при диагностике «интернет не работает»?