ЯдроКодаподготовка к экзаменам
Учебная платформа

Загружаем материалы

Подготавливаем материалы и навигацию по разделу.

Сеть Linux: IP, маршруты, Netplan и диагностика соединений

Автор: · Обновлено

Сетевая ошибка может возникнуть на уровне интерфейса, маршрута, DNS, TCP или приложения. Проверяйте их в таком порядке: отсутствие IP не исправляется заменой DNS, а открытый порт…

Сетевая ошибка может возникнуть на уровне интерфейса, маршрута, DNS, TCP или приложения. Проверяйте их в таком порядке: отсутствие IP не исправляется заменой DNS, а открытый порт не доказывает корректный HTTP-ответ. Начинаем с чтения состояния; изменение маршрутов и профилей выполняют на учебной VM с доступной консолью, потому что ошибка способна оборвать SSH.

TCP и UDP: как передаются данные

TCP устанавливает соединение и предоставляет приложению упорядоченный поток байтов: повторяет потерянные данные, устраняет повторы и управляет потоком и перегрузкой. Границы отдельных отправок не сохраняются, поэтому прикладной протокол сам выделяет сообщения. Разрыв связи всё равно возможен; подтверждение TCP не доказывает, что сервер записал бизнес-операцию на диск.

UDP передаёт отдельные дейтаграммы и сохраняет их границы, но сам не гарантирует доставку, порядок или отсутствие повторов. Подтверждения и повторные попытки при необходимости реализует протокол поверх UDP. У обоих транспортов есть порты, поэтому TCP/443 и UDP/443 — разные назначения. UDP не означает автоматически «быстрее», а TCP — «медленно»: результат зависит от протокола, потерь и нагрузки. Для диагностики смотрите, какой транспорт использует приложение: ss -t показывает TCP, ss -u — UDP. Firewall и проверка порта должны учитывать выбранный транспорт.

IPv4 и IPv6: что выбрать

IPv4 использует 32-битные адреса, например 192.0.2.10, IPv6 — 128-битные, например 2001:db8::10. Большое адресное пространство IPv6 снижает необходимость экономить публичные адреса через NAT. Переход на IPv6 сам по себе не шифрует трафик и не гарантирует ускорение. Выбор определяется поддержкой провайдера, сети, клиентов и приложения; для совместимости часто используют dual stack, когда работают оба семейства.

При dual stack отдельно проверяйте адреса и маршруты через ip -4 address, ip -6 address, ip -4 route, ip -6 route, DNS-записи A и AAAA, listener и правила firewall. Если опубликована AAAA-запись, но IPv6-путь сломан, часть клиентов столкнётся с задержкой или отказом. Отсутствие NAT не означает общий доступ ко всем портам: входящие соединения ограничивает firewall. Универсально «лучшей» версии для любой машины нет; рабочая конфигурация должна обеспечивать доступ целевой аудитории и наблюдаемость обоих путей.

Узнать локальный адрес и выбранный маршрут

ip -br link
ip -br address
ip route show
ip route get 192.0.2.20

Первая команда показывает интерфейсы и MAC, вторая — их адреса. В маршруте видны via для шлюза, dev для интерфейса и src для выбранного исходного IP. Ответ зависит от сети машины; Network is unreachable тоже является полезным результатом. Запись 192.168.50.10/24 означает 24 бита сетевого префикса, то есть маску 255.255.255.0, а не номер порта.

Локальный адрес за NAT отличается от внешнего. Узнать внешний адрес можно через согласованный внешний сервис, например curl -fsS https://api.ipify.org; сервис увидит источник соединения и получит ваш запрос. Результат описывает выход именно этого запроса, включая VPN или proxy. Имя по адресу проверяют dig -x IP +short, адрес по FQDN — getent ahosts имя или dig; обратная DNS-запись может отсутствовать и не обязана совпадать с hostname машины.

ip neigh show связывает IP с MAC соседей локального сегмента. Узнать MAC удалённого сервера через маршрутизатор так нельзя: таблица покажет ближайший шлюз. Состояние FAILED говорит об отсутствии ответа соседа, а не о неисправности всей сети.

Ping, маршрут и порт отвечают на разные вопросы

ping -c 3 127.0.0.1
ping -c 3 -s 1200 127.0.0.1

-c ограничивает число пакетов, -s задаёт размер данных ICMP без заголовков. Бесконечный интерактивный ping останавливается Ctrl+C. Для выбранного исходного интерфейса или адреса используют ping -I интерфейс адрес; адрес должен принадлежать машине. ICMP не имеет TCP-порта, поэтому «ping по порту 443» проверяют другим инструментом: nc -vz -w 3 сервер 443 или curl для HTTP(S). Отказ ICMP не доказывает закрытый TCP-порт.

mtr -r -c 10 сервер показывает несколько проб к промежуточным узлам, traceroute — путь отдельными пробами. Потери на одном промежуточном маршрутизаторе при нормальном ответе последнего узла могут быть ограничением ICMP, а не потерей пользовательского трафика. TIME_WAIT в ss — обычное состояние после закрытия TCP; множество коротких соединений требует оценки повторного использования соединений приложением до изменения параметров ядра.

Временные и постоянные маршруты

Пример только для VM, где 192.168.50.1 действительно достижим через enp1s0: sudo ip route add 198.51.100.0/24 via 192.168.50.1 dev enp1s0. Удаление той же записи: sudo ip route del 198.51.100.0/24 via 192.168.50.1 dev enp1s0. Команда ip route add default via ... создаёт маршрут для адресов без более специфичного совпадения; существующий default и метрики нужно проверить заранее.

Изменения через ip обычно исчезают после перезапуска или перенастройки сети. Для постоянного маршрута редактируют конфигурацию владельца интерфейса — Netplan, NetworkManager либо systemd-networkd. Не создавайте параллельно разные конфигурации одного интерфейса.

Статический IP в Netplan

Пример для учебной сети, где указанный адрес свободен, а шлюз одновременно предоставляет DNS. Имя интерфейса возьмите из ip link; для настоящей сети согласуйте все адреса.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
        - to: 198.51.100.0/24
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

Перед применением сохраните старую конфигурацию, проверьте синтаксис через netplan generate и применяйте из консоли VM через netplan try. Режим try ожидает подтверждение и пытается откатить неподтверждённую конфигурацию, но консоль всё равно нужна для проверки фактического восстановления. В YAML важны отступы; успешная генерация не доказывает доступность шлюза или уникальность IP.

/etc/network/interfaces и ifupdown

На Debian-системах с ifupdown постоянная конфигурация может находиться в /etc/network/interfaces и подключаемых оттуда файлах interfaces.d. Это отдельный формат, не YAML Netplan и не профиль NetworkManager. Сначала установите, кто управляет конкретным интерфейсом: наличие файла само по себе ещё не доказывает, что система его применяет. Не поручайте один интерфейс одновременно ifupdown и другому сетевому менеджеру.

Следующий файл предназначен для учебной VM с интерфейсом enp1s0, свободным адресом 192.168.50.10 и достижимым шлюзом. Пример сначала сохраняется во временном файле и только читается:

interfaces_demo=$(mktemp)
cat >"$interfaces_demo" <<'NETWORK'
auto lo
iface lo inet loopback

auto enp1s0
iface enp1s0 inet static
    address 192.168.50.10/24
    gateway 192.168.50.1
NETWORK
ifquery -i "$interfaces_demo" --list
ifquery -i "$interfaces_demo" enp1s0
rm -- "$interfaces_demo"

При установленном ifupdown список должен содержать lo и enp1s0, а второй вывод — заданные address и gateway. ifquery читает определения; это не проверка доступности шлюза и не применение адреса. Для просмотра штатного файла используйте ifquery --list и ifquery enp1s0. auto включает интерфейс в ifup -a, inet static задаёт статический IPv4. DNS настраивается через используемый в системе резолвер: наличие address/gateway само не добавляет DNS-сервер.

После проверки перенести определение в рабочую конфигурацию и применить ifup/ifdown можно только из консоли VM с сохранённым исходным файлом и установленным владельцем интерфейса. ifdown разрывает соединения, поэтому выполнение через единственный SSH-канал без консоли не является безопасным способом проверки. При переходе на Netplan или NetworkManager сначала устраните конкурирующее управление, затем проверяйте новый профиль и фактические адреса.

Профили NetworkManager и Wi-Fi

nmcli device status показывает устройства, nmcli connection show — сохранённые профили. Для учебного профиля команда nmcli connection modify lab ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1 ipv4.dns 192.168.50.1 задаёт статическую конфигурацию, а nmcli connection up lab применяет её. Постоянный маршрут добавляют свойству +ipv4.routes "198.51.100.0/24 192.168.50.1" этого же профиля.

Для Wi-Fi сначала выполните nmcli device wifi list, затем nmcli --ask device wifi connect 'имя-сети'. --ask запрашивает пароль интерактивно, не оставляя его аргументом в истории. Выключенный radio проверяют через nmcli radio wifi и rfkill; отсутствующий интерфейс требует диагностики адаптера и драйвера. Эти команды относятся к системе с NetworkManager, а не к любому Linux автоматически.

Пакеты и пропускная способность

sudo tcpdump -ni интерфейс -c 20 'tcp port 443' ограничивает захват двадцатью подходящими пакетами. Остановить ожидание можно Ctrl+C. Фильтр host IP and port 443 сужает наблюдение; наличие SYN без ответа направляет проверку к пути и фильтрации, а TCP handshake без успешного HTTP — выше по стеку. Захват может содержать чувствительные данные, поэтому сохраняйте только нужную выборку и контролируйте доступ к ней.

Безопасная локальная тренировка iperf3: в первом терминале iperf3 -s -1 -B 127.0.0.1, во втором iperf3 -c 127.0.0.1 -t 3. Получится измерение loopback, не скорости интернета. Для двух собственных тестовых машин сервер слушает согласованный адрес, клиент соединяется с ним; -R меняет направление. Значение зависит от CPU, маршрута, параллелизма и нагрузки, поэтому единичный прогон не является гарантированной характеристикой канала.

Отдельная сеть через netns и veth

Network namespace имеет собственные интерфейсы, маршруты и сокеты, а veth связывает два сетевых конца. В отдельной VM создайте пространства sudo ip netns add course-a и sudo ip netns add course-b, затем пару sudo ip link add ca type veth peer name cb. Перенесите концы: sudo ip link set ca netns course-a, аналогично cb в course-b. Вызов sudo ip -n course-a address add 10.203.0.1/30 dev ca задаёт первый адрес, в course-b назначьте 10.203.0.2/30 на cb. Поднимите оба интерфейса и loopback через ip -n имя link set интерфейс up.

Проверка sudo ip netns exec course-a ping -c 2 10.203.0.2 должна получить ответы: пакет проходит через veth, без внешнего маршрутизатора. Таблицы смотрят через ip -n course-a route. По окончании удалите оба учебных namespace через ip netns del; связанных запущенных процессов оставаться не должно. Эта лаборатория не меняет адрес основного интерфейса VM и наглядно объясняет сетевую изоляцию контейнеров.

Ошибка и диагностика

Could not resolve host требует проверить само имя, getent, DNS и proxy-переменные, а не отключать TLS-проверку. Если IP доступен, имя нет — исследуйте резолвер. Если локальный сервис слушает только 127.0.0.1, разрешение порта firewall не сделает его доступным извне. После каждого изменения сравнивайте ip address, route, ss и прикладной запрос, сохраняя предыдущую конфигурацию для отката.

Практика

Запишите интерфейс, локальный IP, маску и маршрут к выбранному адресу без изменения сети. Сравните ping loopback и проверку реально запущенного локального сервиса. Выполните оба конца iperf3 и объясните, почему результат не характеризует провайдера. Для VM подготовьте постоянную конфигурацию отдельно, укажите способ восстановления через консоль и контрольные команды после применения.

Что важно запомнить

Адрес, маршрут, DNS, порт и протокол приложения проверяются независимо. Постоянную конфигурацию хранит владелец интерфейса; случайная смесь менеджеров приводит к изменениям, исчезающим после перезапуска.

Частые вопросы

Почему маршрут есть, а соединение не устанавливается?

Маршрут только выбирает следующий шаг. Дополнительно нужны доступный сосед, обратный путь, разрешающие правила и работающий сервис на нужном адресе и порту.

Где увидеть открытые порты локально?

Используйте ss -tulpn, при необходимости с правами администратора для имён чужих процессов. LISTEN подтверждает локальный сокет, но внешний доступ проверяется с другой машины.

Можно ли применить статический адрес удалённо?

Можно при подготовленном доступе к консоли и проверенном откате. Изменение единственного сетевого пути без такого доступа способно оставить машину недоступной даже при правильном файле.

Источники