Firewall и маршрутизация

Маршрутизация: куда уйдёт пакет

Когда хост отправляет пакет, он смотрит в таблицу маршрутов и решает, через какой интерфейс и шлюз его слать:

ip route
# default via 192.168.1.1 dev eth0
# 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.42

Читается так:

• 192.168.1.0/24 dev eth0: "адреса этой подсети — соседи, шлю напрямую через eth0",
• default via 192.168.1.1: "всё остальное отдаю шлюзу 192.168.1.1".

default — это маршрут по умолчанию (default gateway). Нет default gateway — нет интернета, даже при правильном IP: пакету наружу некуда идти.

Узнать, каким маршрутом уйдёт конкретный адрес:

ip route get 8.8.8.8
# 8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.42

Добавить маршрут руками (например, до отдельной подсети через другой шлюз):

ip route add 10.10.0.0/16 via 192.168.1.254

На проде статические маршруты обычно прописывают не командой (она живёт до перезагрузки), а в конфиге сети (netplan / NetworkManager / /etc/network/interfaces).

Firewall на Linux: netfilter

Фильтрацию пакетов в ядре Linux делает netfilter. Управляют им через iptables (классика) или nftables (преемник). Поверх часто ставят обёртки попроще: ufw в Debian и Ubuntu, firewalld в RHEL, Rocky, Alma и Fedora.

iptables сегодня это фронтенд к nftables

На Debian 10+, Ubuntu 20.10+ и RHEL 8+ команда iptables больше не пишет правила в старый механизм. Это iptables-nft: привычный синтаксис, но правила уезжают в nftables. Два «параллельных варианта» из старых статей на деле давно один движок с двумя интерфейсами.

Практическое следствие кусается на диагностике. Правила, созданные напрямую через nft, в выводе iptables -L не появятся: тот показывает только свои таблицы. Хост выглядит «без правил», а трафик всё равно режется.

nft list ruleset           # полная картина netfilter
iptables -L -n -v          # только то, что положил туда iptables

Проверить, какой фронтенд стоит, и переключить его:

iptables --version                        # выведет (nf_tables) или (legacy)
sudo update-alternatives --config iptables

В списке альтернатив будут iptables-nft и iptables-legacy. Менять стоит осознанно: правила из одного механизма в другом не видны, а два включённых одновременно дают трудноуловимые эффекты.

Переписать готовое правило на язык nftables помогает iptables-translate:

$ iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
nft add rule ip filter INPUT tcp dport 22 counter accept

Ключевые понятия iptables:

• таблицы: filter (разрешить/запретить), nat (подмена адресов, см. урок про NAT), и другие,
• цепочки в таблице filter: INPUT (входящие к нам), OUTPUT (исходящие от нас), FORWARD (транзит, когда мы роутер),
• правила: условие + действие (-j ACCEPT, -j DROP, -j REJECT),
• политика по умолчанию: что делать, если ни одно правило не подошло.

iptables -L -n -v          # показать правила filter с счётчиками
iptables -t nat -L -n      # правила таблицы nat

Пример: пустить SSH и закрыть всё остальное входящее.

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP

iptables правила живут до перезагрузки; чтобы пережили ребут, их сохраняют (iptables-save / netfilter-persistent), или используют ufw/nftables, которые делают это сами.

ufw: простой фасад

Прямое управление iptables многословно. ufw (Uncomplicated FireWall) — удобная обёртка для типовых задач на одном хосте:

ufw allow 22/tcp        # пустить SSH
ufw allow 80,443/tcp    # HTTP/HTTPS
ufw default deny incoming
ufw enable
ufw status verbose      # что сейчас открыто

Под капотом ufw всё равно генерирует правила netfilter. Для одиночного сервера его обычно достаточно.

В RHEL, Rocky, Alma и Fedora по умолчанию стоит другая обёртка, firewalld. Она работает с зонами вместо плоского списка правил:

firewall-cmd --state
firewall-cmd --list-all                          # что открыто в активной зоне
firewall-cmd --add-port=8080/tcp --permanent
firewall-cmd --reload

Без --permanent правило живёт до перезагрузки, а без --reload permanent-правило не применится к текущей конфигурации. Обе половины нужны.

Облачный firewall — отдельный слой

Важная ловушка: в облаке (Yandex Cloud, AWS, Selectel) есть второй firewall снаружи ОС: security groups / network ACL. Пакет проходит сначала его, потом firewall внутри ОС.

Поэтому классическое "порт открыт в ufw, сервис слушает 0.0.0.0, а снаружи всё равно недоступно" — чаще всего закрытый порт в облачной security group. Проверяй оба слоя.

Почему ping не отвечает, хотя сервис жив

ping использует протокол ICMP (echo request/reply), а не TCP. Это отдельный трафик, и его очень часто режут:

• firewall дропает ICMP по политике безопасности,
• облачная security group не пропускает ICMP,
• хост сам настроен не отвечать на echo.

При этом TCP-порты (80, 443, 22) могут быть открыты и сервис прекрасно работает. Вывод: "ping не проходит" не равно "сервер лежит". Проверяй сам сервис через nc -zv host port или curl, а не пингом.

Почему traceroute показывает * * *

traceroute работает на трюке с TTL: шлёт пакеты с растущим TTL и ловит ICMP "time exceeded" от каждого hop'а. Звёздочки * * * значат, что hop не прислал этот ICMP. Причины те же:

• маршрутизатор настроен не отвечать на истёкший TTL (намеренно),
• firewall режет ICMP / UDP-пробы traceroute,
• rate-limiting на ICMP у промежуточного узла.

* * * в середине пути — норма и не означает обрыв: конечный хост при этом может отвечать. Тревожно, только если звёзды идут до самого конца.

DROP vs REJECT — читаем по симптому

Как firewall отбрасывает пакет, видно по поведению клиента:

• DROP — пакет молча выкидывается. Клиент ждёт и получает timeout. "Подключение висит и отваливается по таймауту" — почерк DROP (или пакет вообще не дошёл).
• REJECT — firewall отвечает "закрыто". По умолчанию для TCP это ICMP port-unreachable; чтобы вернуть именно TCP RST, нужен --reject-with tcp-reset. Клиент сразу получает Connection refused.

Отсюда диагностика из прошлого урока обретает смысл: timeout в nc означает DROP или потерю по пути, а refused говорит, что до хоста долетели, но порт закрыт (нет сервиса или REJECT).

Порядок диагностики "снаружи недоступно"

1. ip route: есть default gateway? Маршрут до цели верный?
2. ss -tulnp на сервере: сервис вообще слушает, и на 0.0.0.0, а не на 127.0.0.1?
3. nft list ruleset, iptables -L -n, ufw status или firewall-cmd --list-all: локальный firewall не режет порт? Смотри именно nft list ruleset, потому что правила, положенные через nft, в iptables -L не видны.
4. Облачная security group: порт открыт во внешнем firewall?
5. nc -zv снаружи: timeout (DROP/маршрут) или refused (нет сервиса/REJECT)?

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

ip route показывает таблицу маршрутов; нет default gateway — нет выхода наружу.

netfilter рулит фильтрацией; управляют им через iptables/nftables, а ufw и firewalld — обёртки поверх. Цепочки INPUT/OUTPUT/FORWARD, действия ACCEPT/DROP/REJECT.

На современных дистрибутивах iptables это фронтенд к nftables. Полную картину даёт nft list ruleset, iptables -L показывает только свою часть.

В облаке есть второй firewall (security groups) снаружи ОС. Проверяй оба слоя.

ping использует ICMP, его часто режут: молчит ping не значит, что сервис лёг. Проверяй порт через nc/curl.

traceroute * * * — hop не отвечает на ICMP, обычно намеренно; до конца звёзды = проблема, в середине = норма.

DROP -> timeout, REJECT -> connection refused. По симптому понятно, что происходит.

В следующем уроке — короткий квиз по сети, и трек закрыт.