Пара 7: Сеть: sockets, маршруты, Netfilter и Wi-Fi
90 минут · 3 курс, ML.
Содержание и результат
Проверить путь HTTP-запроса и различать ошибки DNS, соединения и приложения.
План занятия
0–15: адрес, маска, route и DNS. 15–35: TCP, socket и HTTP. 35–50: Netfilter hooks, nft/iptables и DROP/REJECT. 50–60: Wi-Fi режимы и граница WSL2. 60–80: диагностика localhost и разобранных сетевых симптомов. 80–90: фиксация работающего пути.
Практика выполняется в своей учебной папке и на localhost. Подготовка окружения описана в lab/README.md.
Адрес и порт
IP выбирает узел, порт — точку приёма на нём.
На одной машине может работать много сетевых служб. IP помогает доставить пакет к узлу, порт помогает операционной системе выбрать сокет. 127.0.0.1 — loopback текущей среды; внутри контейнера позже это будет сам контейнер. 0.0.0.0 в bind означает слушать на всех IPv4-интерфейсах, а не адрес, который надо сообщить пользователю. Прослушивание не доказывает доступность снаружи: нужны маршруты и разрешение firewall. В WSL Windows localhost часто перенаправляется в Linux, но режим сети и настройки имеют значение. Не публикуем учебные порты в интернет ради первого опыта.
Аналогия: адрес дома и номер квартиры.
DNS и TCP
Имя сначала нужно разрешить, затем установить соединение.
DNS преобразует имя в записи, часто A/AAAA для адресов. Кеш и TTL означают, что изменения не обязательно мгновенно видны всем. Успешный DNS не гарантирует, что по адресу работает нужный сервер. TCP устанавливает соединение; timeout отличается от connection refused. ping не проверяет HTTP и может блокироваться даже у исправного сервиса. getent hosts использует системное разрешение имён, полезное для проверки того, что видит приложение. Разделяем вопросы: имя разрешилось? порт доступен? HTTP ответил? Это уменьшает случайные перезапуски.
Аналогия: справочник может знать адрес магазина, даже если магазин закрыт.
HTTP — запрос и ответ
Статус, заголовки и тело дают разные доказательства.
Метод и путь задают действие; заголовки несут метаданные, тело — данные. Для курса используем GET /healthz и POST /predict. Статусы 2xx говорят об успешной обработке в смысле HTTP, 4xx — проблеме запроса/доступа, 5xx — ошибке серверной обработки. 200 не гарантирует, что предсказание научно правильно. HTTPS добавляет TLS: шифрование и проверку идентичности сервера сертификатом. curl -i показывает ответ с заголовками, curl -v помогает исследовать соединение, но может раскрывать чувствительные заголовки. На демонстрации используем только фиктивные запросы.
Аналогия: бланк заказа, служебная отметка и результат заказа.
Подробный разбор: Путь пакета, firewall и режимы Wi-Fi
Пакет проходит маршрутизацию и hooks Netfilter
Локальный получатель, транзит и локальный отправитель имеют разные пути.
Входящий IP-пакет попадает в сетевой стек, проходит соответствующие hooks и решение маршрута. Для локального адресата важен INPUT, для пересылки через хост — FORWARD; локально сформированный пакет проходит OUTPUT, перед выходом участвует POSTROUTING. PREROUTING расположен до решения маршрута. Это упрощённая карта: конкретные priorities, families, bridge/ingress и connection tracking добавляют детали. Firewall проверяет правила в нужной точке, а NAT меняет адреса или порты; NAT не является синонимом ограничения доступа. Если процесс слушает только 127.0.0.1, открытие firewall не заставит его слушать внешний адрес. При таймауте отдельно проверяют наличие слушателя, route и filter, а DNS лишь определяет адрес. Правила на удалённом сервере без запасного доступа не меняем. Учебная демонстрация — схема и чтение имеющегося ruleset, а не очистка правил хоста.
Практическое следствие: Локальный HTTP-сервис нужен в INPUT-пути, router-трафик — в FORWARD. Адрес/порт приложения всё равно проверяются отдельно.
iptables и nftables — способы настроить правила
Важен реальный backend, а не только имя команды.
Netfilter — инфраструктура обработки пакетов в ядре. Iptables является историческим интерфейсом управления xtables; nftables даёт другой ruleset и nft CLI. На многих современных системах iptables-nft переводит знакомый синтаксис в nft backend, тогда как iptables-legacy обращается к legacy механизму. Поэтому iptables --version и nft list ruleset помогают выяснить, что действительно используется. UFW и firewalld — ещё один слой управления, который может генерировать правила; ручное изменение параллельно менеджеру может быть перезаписано. В nftables ruleset состоит из tables, chains и rules; base chain подключается к hook с priority и policy. DROP молча отбрасывает пакет, REJECT возвращает отказ по выбранному механизму. Stateful фильтрация использует состояние соединения, но понятие established не делает приложение доверенным. Пример конфигурации хранится в файле и проверяется в изолированной VM/namespace, без nft flush ruleset на ноутбуке.
Практическое следствие: Ubuntu: nft --version; iptables --version; sudo nft list ruleset — только чтение. WSL2 имеет также сетевые ограничения Windows-хоста.
wlo1 — имя интерфейса, managed — режим
Radio-возможности определяются PHY, драйвером и поддержанными сочетаниями.
Predictable interface names вроде wlo1 или wlp2s0 обозначают интерфейс по правилам именования, а не режим «взлома» или тип firewall. Managed/station — Wi-Fi клиент, AP — точка доступа, monitor — получение радио-кадров в пределах возможностей адаптера. Iw dev показывает интерфейсы и type, iw list — capabilities PHY. Не каждый адаптер поддерживает monitor, AP или одновременные комбинации; виртуальная машина может не получить прямого Wi-Fi доступа. WSL2 обычно видит виртуальную сеть, поэтому iw может не показывать Wi-Fi PHY ноутбука. Monitor не равен promiscuous mode обычного Ethernet и не гарантирует расшифровку защищённого трафика. В занятии читаем режимы своего устройства и обсуждаем схему. Переключение рабочего Wi-Fi на monitor отключит обычное подключение; такую демонстрацию делают только на отдельном собственном адаптере, а не на сети аудитории.
Практическое следствие: Kali не создаёт аппаратную возможность monitor. Используется тот же Linux wireless stack и поддержка конкретного драйвера.
Опыт: связать рисунок с наблюдением
ip -brief address
ip route
ss -lnt
getent hosts example.com
nft --version
iptables --version
# Physical Linux with iw and a supported wireless adapter
iw dev
iw list | head -n 40
# Isolated user + network namespace; no host rules changed
unshare -Urn sh -c 'nft --check -f lab/experiments/firewall.nft && nft -f lab/experiments/firewall.nft && nft list table inet devops_demo'
Соберите путь собственного HTTP-запроса от curl до LISTEN. Firewall-пример применяется только внутри unshare -Urn, то есть собственного user/network namespace. Если user namespaces заблокированы политикой системы, используйте отдельную VM. Не выполняйте nft -f этого файла в обычном namespace хоста. В ruleset отдельная inet table, base chain INPUT, loopback, established/related и TCP 8000; policy drop блокирует остальное в изолированной среде. В WSL при отсутствии iw PHY запишите границу виртуальной среды; это не повод устанавливать Kali.
Источники подробного разбора
Команды и наблюдения
Окружение: Ubuntu / Bash, два терминала.
mkdir -p ~/devops-course/web
cd ~/devops-course/web
printf "hello from Ubuntu
" > index.html
python3 -m http.server 8080 --bind 127.0.0.1
# In another Ubuntu terminal
curl -i http://127.0.0.1:8080/
curl -i http://127.0.0.1:8080/missing
ss -ltnp | grep :8080
getent hosts example.com
Демонстрационный http.server не используем как production-сервер. Останавливаем Ctrl+C в первом терминале.
Ожидаемый результат: Для / ответ 200, для /missing — 404; ss показывает слушающий 127.0.0.1:8080.
Вариант для macOS
curl и Python-команды одинаковы при наличии Python. Вместо ss — lsof; вместо getent hosts — dscacheutil для системного разрешения имени. DNS, TCP и HTTP объясняются одинаково, но инструменты и сетевые режимы ОС отличаются.
python3 -m http.server 8080 --bind 127.0.0.1
# In another Terminal window
curl -i http://127.0.0.1:8080/
lsof -nP -iTCP:8080 -sTCP:LISTEN
dscacheutil -q host -a name example.com
Практика: Три диагноза одного симптома
- Запустите учебный HTTP-сервер и получите нормальный ответ.
- Запросите несуществующий путь и запишите HTTP-статус.
- Остановите сервер и повторите запрос: сравните ошибку соединения с 404.
- Проверьте несуществующее имя учебного домена с getent; составьте порядок диагностики.
Результат: Таблица DNS / TCP / HTTP с командой и наблюдаемым результатом.
Проверка: Студент не лечит 404 изменением DNS; соединение и ответ различаются.
Неисправность для разбора: localhost одного компьютера ошибочно используется как адрес другого.
Решение и диагностика
Для ошибки имени используйте getent hosts definitely-missing.invalid; .invalid зарезервирован для несуществующих имён. Для остановленного порта curl --connect-timeout 3 http://127.0.0.1:8080/ даст ошибку соединения. Для работающего сервера curl -i .../missing даст HTTP 404. Порядок: URL и среда → разрешение имени → слушающий процесс/порт → HTTP-ответ → журнал приложения.
Основные выводы
- Нет, он не выполняет HTTP-запрос.
- Сам контейнер, а не соседний сервис.
Самостоятельная работа
Проверить публичную учебную презентацию через curl -I; объяснить HTTPS и статус без сканирования посторонних портов.