Перейти к содержанию

5. Сеть в Linux (DevOps core)

TCP/IP стек в Linux, iproute2 (ip/ss), ARP/маршрутизация, NAT/conntrack, DNS (resolv.conf, nsswitch.conf), iptables/nftables и практическая диагностика сетевых проблем.

Стек TCP/IP в Linux

В ядре реализованы протоколы L2–L4: драйверы сетевых интерфейсов, IP-маршрутизация, TCP/UDP, сокеты. Приложения работают через сокеты (syscalls); ядро формирует пакеты, передаёт их в драйвер и в сеть. Обработка входящих: драйвер → IP → маршрутизация → фильтры (netfilter) → доставка в сокет или пересылка (FORWARD). Понимание стека нужно, чтобы идти по цепочке при отладке: линк → адрес → маршрут → firewall → приложение.

iproute2: ip и ss

ip

Набор ip заменяет устаревшие ifconfig, route, arp. Управление интерфейсами, адресами, маршрутами, соседями (ARP/NDP):

ip link show
ip addr show
ip route show
ip neigh show
ip route get 8.8.8.8   # какой маршрут выберется до цели

ss

ss — просмотр сокетов (современная замена netstat): быстрее и показывает больше деталей из ядра.

ss -tlnp   # слушающие TCP с процессами
ss -tunap  # все TCP/UDP с процессами
ss -o state established

Использование ip и ss — базовый набор для диагностики сети и сокетов на Linux.

ARP и таблица маршрутизации

  • ARP — определение MAC по IP в одной L2-подсети. Кэш: ip neigh show или arp -a. При проблемах «не пингуется в той же подсети» проверять линк и ARP.
  • Таблица маршрутизации — по ней ядро выбирает, куда отправить пакет (next hop, интерфейс). Команда: ip route; проверка маршрута до хоста: ip route get <IP>. Default route (0.0.0.0/0) задаёт шлюз «по умолчанию».

Подробнее — в разделе Networking (IP-сети и маршрутизация, Linux Networking).

NAT и conntrack

NAT (подмена адресов/портов) реализуется в ядре через правила iptables/nftables. Для работы stateful NAT ядро ведёт conntrack — таблицу активных соединений. Ответные пакеты сопоставляются с записью и обратно подменяются. При проблемах «исходящее есть, ответ не приходит» часто виноват conntrack (таблица переполнена или правила NAT/фильтра сломаны). Просмотр: conntrack -L; при необходимости увеличить лимиты conntrack в sysctl.

Разрешение DNS: resolv.conf и nsswitch.conf

/etc/resolv.conf

Содержит адреса резолверов (nameserver) и опции (search, options). Откуда берётся файл, зависит от системы: вручную, через systemd-resolved, DHCP или менеджер сети. Проверка: cat /etc/resolv.conf. Если имена не резолвятся — проверить доступность резолвера (ping, порт 53) и сам резолвинг: dig @8.8.8.8 example.com (в обход локального).

nsswitch.conf

Файл /etc/nsswitch.conf задаёт порядок источников для разрешения имён хостов, пользователей и т.д. Строка hosts: files dns означает: сначала /etc/hosts (files), затем DNS. Если порядок изменён (например, только files) или DNS отключён в цепочке — резолвинг через DNS не сработает. При проблемах с DNS на хосте смотреть и resolv.conf, и nsswitch.conf.

Firewall: iptables и nftables (концепции)

Правила фильтрации и NAT задаются через iptables или nftables (интерфейсы к подсистеме netfilter). Пакет проходит цепочки: PREROUTING → маршрутизация → INPUT (для хоста) или FORWARD (пересылка) → OUTPUT. В цепочках могут быть DROP, REJECT, ACCEPT и правила NAT. Для диагностики «доступен локально, но не извне» важно проверить: не режет ли firewall входящий трафик на порт (цепочка INPUT или FORWARD на пути к сервису). Команды: iptables -L -n -v, nft list ruleset. Подробнее — в разделе Networking (Linux Networking).

Практика

Диагностировать «сервис доступен локально, но не извне»

Последовательность:

  1. Где слушает сервис — ss -tlnp: на каком адресе (0.0.0.0 или 127.0.0.1)? Если только 127.0.0.1, снаружи до порта не достучаться; нужно слушать на 0.0.0.0 или на IP интерфейса.
  2. Маршрут — с внешнего узла пакеты доходят до этого хоста? ping, traceroute.
  3. Firewall — на целевом хосте (и на пути) нет ли DROP/REJECT для этого порта в INPUT (и при необходимости в FORWARD)? Временно проверить отключением правил (осторожно в production).
  4. NAT — если трафик идёт через другой хост с NAT, учтены ли правила DNAT/SNAT и conntrack?

Итого: привязка к 127.0.0.1 и firewall — самые частые причины «локально есть, извне нет».

Найти проблему с DNS

  1. Резолвится ли имя с проблемного хоста — nslookup hostname, dig hostname.
  2. Содержимое resolv.conf — правильные ли nameserver и search?
  3. nsswitch.conf — в строке hosts есть dns? Порядок files dns.
  4. Доступность резолвера — ping на IP резолвера; с хоста порт 53 (UDP/TCP) не закрыт firewall?
  5. Через другой резолвер — dig @8.8.8.8 hostname. Если через 8.8.8.8 резолвится, а локально нет — проблема в локальном резолвере или в его upstream.

Разница ss и netstat

Критерий ss netstat
Источник данных Напрямую из структур ядра (netlink) Читает /proc/net и др.
Скорость Быстрее на системах с большим числом сокетов Медленнее
Вывод Богаче (таймеры, состояние и т.д.) Классический формат
Статус Рекомендуется, входит в iproute2 Устарел, в net-tools

В новых системах использовать ss; netstat оставить для совместимости со старыми скриптами или когда ss недоступен.

!!! tip "Практика"

При любой сетевой проблеме на хосте: 1) ip addr, ip route — линк и маршруты; 2) ss -tlnp — кто и на каком адресе слушает; 3) resolv.conf и nsswitch при проблемах с именами; 4) iptables/nftables при «не доходит» при нормальном маршруте.

Паттерны и антипаттерны

Паттерн Описание
Проверять привязку сервиса 127.0.0.1 — только localhost; для доступа извне — 0.0.0.0 или конкретный IP.
Использовать ss и ip Стандартный и быстрый способ смотреть сокеты и сеть.
При DNS — resolv.conf и nsswitch Оба влияют на то, как резолвятся имена.
Антипаттерн Почему плохо Что делать
Считать «раз с машины работает — значит снаружи тоже» Локально может идти на 127.0.0.1; снаружи — другой путь и firewall. Проверять привязку и правила извне.
Менять firewall без понимания цепочек Легко заблокировать нужный трафик или сломать NAT. Знать INPUT/FORWARD и порядок правил.

Дополнительные материалы