TCP-флаги, которые нельзя блокировать бездумно

Фильтровать TCP-флаги кажется удобным способом усилить firewall: разрешить только «нормальные» пакеты и всё остальное отбросить.
Но некоторые флаги участвуют не только в установлении соединения, и их бездумная блокировка может ломать уже работающие TCP-сессии.

⏺SYN - установка соединения

Без SYN новый TCP-сеанс просто не начнётся:

Client → SYN → Server
Client ← SYN/ACK ← Server
Client → ACK → Server

Если firewall отбрасывает входящие SYN, сервер не сможет принимать новые TCP-соединения.

⏺ACK - подтверждение данных

ACK встречается практически во всём нормальном TCP-трафике после установки соединения.
Например:

Client → PSH, ACK
Server → ACK

Правило вида:

iptables -A INPUT -p tcp ! --tcp-flags ACK ACK -j DROP

может выглядеть логично, но нельзя просто считать отсутствие ACK признаком атаки: SYN-пакет нового соединения как раз приходит без ACK.
Поэтому обычно проверяют состояние соединения через conntrack, а не только наличие флага.

⏺RST - аварийное закрытие

RST сообщает другой стороне, что TCP-соединение больше не существует.
Например, приложение не слушает порт:

Client → SYN → Server
Client ← RST ← Server

Если firewall блокирует RST без понимания контекста, клиент может вместо быстрого отказа получить долгий timeout.
RST также используется для завершения некоторых некорректных или уже несуществующих соединений.

⏺FIN - нормальное закрытие

FIN означает: «я больше не буду отправлять данные».

Client → FIN, ACK
Server → ACK
Server → FIN, ACK
Client → ACK

Блокировка FIN может превращать нормальное закрытие соединения в зависание до срабатывания timeout.

⏺Что делать вместо фильтрации отдельных флагов

Для stateful firewall обычно правильнее разрешать уже установленные соединения:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

А новые подключения контролировать отдельно:

iptables -A INPUT -p tcp --dport 22 \
    -m conntrack --ctstate NEW -j ACCEPT

То есть проверять не просто «какие TCP-флаги приехали», а в каком состоянии находится соединение.

Особенно опасны универсальные правила вроде:

-p tcp --tcp-flags ALL NONE -j DROP
-p tcp --tcp-flags ALL ALL -j DROP

Они действительно могут отсеивать часть мусорного трафика, но сами по себе не являются полноценной защитой TCP.

N.A.

Почему новые соединения идут по старому маршруту

После изменения маршрута можно увидеть странную ситуацию: ip route уже показывает новый путь, но существующее TCP-соединение продолжает работать через старый.
Это нормально.

⏺Маршрут не пересчитывается как отдельное решение для каждого TCP-сеанса
Когда приложение открывает соединение, ядро выбирает маршрут для этого потока. Дальше пакеты существующего соединения обрабатываются с учётом уже созданного состояния.
Поэтому изменение:

ip route replace default via 192.168.1.1

не означает, что все уже установленные TCP-соединения мгновенно начнут использовать новый gateway.

⏺Особенно заметен conntrack

На firewall или NAT устройство хранит состояние соединения:
conntrack -L
Там может находиться запись ESTABLISHED, по которой последующие пакеты распознаются как часть уже существующего потока.
Это особенно важно при NAT: кроме маршрута существует ещё состояние трансляции адресов и портов.
⏺Новые соединения уже могут пойти иначе
После изменения маршрута:

ip route get 8.8.8.8

может показать новый интерфейс или gateway.
Поэтому одновременно возможна ситуация, когда новые подключения используют новый путь, а старые продолжают работать по прежнему состоянию.

⏺Почему это важно при переключении каналов
При аварийном переключении WAN недостаточно просто заменить default route.
Старые TCP-сессии могут продолжать использовать прежнее состояние, а NAT/Firewall может дополнительно удерживать их до таймаута.

Из-за этого после failover часто наблюдается:

новые подключения → работают
старые подключения → timeout

И это не обязательно означает, что новый маршрут настроен неправильно.

Проверять нужно сразу несколько вещей:

ip route get <destination>
sudo conntrack -L
ss -nt

N.A.

Как проверить, что BGP-маршрут анонсируется, но не используется

Ситуация классическая: префикс в BGP есть, а трафик упорно идёт другим путём.

Почти всегда причина - не в самом анонсе, а в выборе best path или в том, как маршрут попал (или не попал) в RIB/FIB.

1️⃣Проверяем, что маршрут вообще пришёл по BGP

Сначала убеждаемся, что апстрим реально его отдал.

Cisco:

show ip bgp <prefix>

Важно смотреть:
• есть ли несколько путей
• какой помечен как *> (best)

Если маршрута нет, дальше можно не копать.

2️⃣Сравниваем BGP vs routing table

Маршрут может быть в BGP, но не установлен в основную таблицу.

show ip route <prefix>

Если вместо BGP стоит: static, OSPF или connected, то BGP просто проиграл по административной дистанции.

Смотрим атрибуты best path

Часто маршрут есть, но проигрывает по атрибутам.

show ip bgp <prefix>

Обращаем внимание на:
⏺Local Preference (самая частая причина)
⏺AS_PATH (длиннее — хуже)
⏺MED
⏺Weight (Cisco)

Даже разница в LocalPref 100 vs 200 полностью меняет путь.

4️⃣Проверяем policy: route-map / filter

Маршрут может быть принят, но «искажён» политикой.

show run | section route-map
show ip bgp neighbors <IP> received-routes

Иногда route-map не режет маршрут, но меняет LocalPref или MED.

5️⃣Проверяем CEF / FIB

Бывает, BGP и RIB ок, а в forwarding таблице другое.

show ip cef <prefix>

Если next-hop не тот, что ожидается — проблема на этапе установки в FIB.

N.A.

DROP и REJECT делают одно и то же?

Нет. Оба блокируют трафик, но клиент получает совершенно разный результат.

⏺DROP просто выбрасывает пакет:

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

Клиент отправляет SYN, но в ответ ничего не приходит:

client → SYN → server
client ← ... ← timeout

TCP будет повторять попытки, пока не истечёт timeout.

⏺REJECT блокирует соединение и отправляет ответ:

iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with tcp-reset

Теперь клиент получает RST и сразу понимает: соединение отвергнуто.

client → SYN → server
client ← RST ← server

Поэтому поведение приложения будет разным:
DROP → «сервер молчит»
REJECT → «сервер отказал»

Это важно и для диагностики. Если всё дропать, ошибка часто выглядит как timeout, хотя проблема на самом деле в firewall.

Для ICMP-трафика REJECT может отправить ICMP unreachable вместо TCP RST.

И ещё момент: DROP не делает систему «более защищённой» автоматически. Он просто не сообщает отправителю, что пакет был отвергнут.

N.A.

OSPF Full означает, что маршрут уже появился?

Нет.

Состояние Full говорит только о том, что два OSPF-соседа синхронизировали LSDB.

Например:

R1 ─── R2
     Full

Но это ещё не гарантирует, что конкретный prefix попадёт в routing table.

Проверяем соседство:

show ip ospf neighbor

Видим:

Neighbor   State
10.0.0.2   FULL

Теперь проверяем маршрут:

show ip route 10.10.10.0

И его может не быть.
Почему?

OSPF сначала получает информацию о топологии, а потом SPF и другие проверки решают, какие маршруты установить в RIB.

Например, prefix может быть в LSDB:

show ip ospf database

но не установиться в таблицу из-за:

⏺недоступного next-hop ⏺невалидного LSA ⏺лучшего маршрута из другого источника ⏺особенностей area / route type ⏺фильтрации или policy

Поэтому при проблеме нельзя останавливаться на:

OSPF = FULL

Нужно проверить всю цепочку:

Neighbor → LSDB → SPF → RIB

N.A.

ARP vs NDP: почему IPv6 не использует broadcast

IPv4 и IPv6 должны узнать MAC-адрес соседа. Кажется, что механизм должен быть одинаковым.

Но в IPv4:

ARP Request → broadcast → ff:ff:ff:ff:ff:ff

В IPv6 ARP вообще нет.
Для этого используется NDP поверх ICMPv6.

Когда узлу нужен MAC соседа, он отправляет Neighbor Solicitation на специальный multicast-адрес, связанный с IPv6-адресом назначения:

ip -6 neigh

Можно увидеть:

fe80::20c:29ff:fe12:3456 dev eth0 lladdr 00:0c:29:12:34:56 REACHABLE

Главное отличие:

ARP  → broadcast
NDP  → multicast

Поэтому IPv6 не должен будить весь L2-сегмент ради поиска одного соседа.

И это не просто замена ARP на другой пакет. NDP также используется для:

⏺обнаружения соседей ⏺проверки доступности ⏺определения router’ов ⏺автоматической настройки адресов

N.A.

Почему jumbo frames включили, а производительность не выросла

Jumbo frames это MTU 9000 вместо стандартных 1500. Меньше заголовков на байт данных, меньше прерываний CPU. В теории быстрее, на практике часто никакого эффекта.

⏺Самая частая причина: один интерфейс или коммутатор на пути со стандартным MTU.

Пакеты фрагментируются или дропаются, выигрыша нет. Jumbo frames работают только если все устройства end-to-end настроены одинаково.

Проверяем что путь реально поддерживает 9000:

ping -M do -s 8972 <IP>

8972 это 9000 минус 28 байт заголовков. Если пакет прошёл, путь чистый.

⏺Вторая причина: приложение шлёт маленькими чанками. Jumbo frames помогают только когда есть что класть в большой пакет. Мелкие запросы останутся мелкими пакетами независимо от MTU.

⏺Третья: узкое место вообще не в сетевом стеке. Jumbo frames снижают CPU overhead от обработки пакетов, но если bottleneck в диске или логике приложения, результата не будет.

mpstat -I ALL 1
ethtool -S eth0 | grep rx_packets

⚡️Реально помогает в узких сценариях: iSCSI, NFS, HPC, высоконагруженные линки между серверами в одном датацентре. В смешанном трафике через разные устройства эффект минимальный.

N.A

BGP Zombie Routes: маршруты, которые не хотят исчезать

BGP withdrawal сообщает соседям, что маршрут больше недоступен. Но это не значит, что он сразу исчезнет из всех таблиц маршрутизации.

Cloudflare исследовала случаи, когда отозванные маршруты продолжали существовать в других сетях. Их называют BGP Zombies.

⏺Допустим, префикс 203.0.113.0/24 доступен через провайдера A. Провайдер отзывает маршрут, но часть AS ещё использует старую информацию.

Начинается path hunting. Маршрутизаторы перебирают альтернативные BGP-пути, некоторые из которых тоже уже недоступны. Из-за этого сходимость затягивается, а трафик может уходить в blackhole или петлю.

Проверяем маршруты на своём роутере:

show bgp ipv4 unicast 203.0.113.0/24
show ip route 203.0.113.0

Первая команда показывает известные BGP-пути, вторая - какой маршрут установлен в RIB. Но локальной таблицы мало. Через RIPE RIS или RouteViews можно посмотреть, продолжают ли другие AS видеть старый путь.

При плановой смене провайдера лучше сначала анонсировать префикс через нового, дождаться распространения маршрута и только потом отзывать старый.

Withdrawal означает, что маршрут отозван. Но не гарантирует, что весь интернет уже перестал его использовать.

N.A

ARP Flux: почему Linux отвечает не с того интерфейса

На сервере два интерфейса в одной подсети. У каждого свой IP, но при ARP-запросе к 192.168.1.10 сосед неожиданно получает MAC второго интерфейса.

Это ARP Flux. Linux по умолчанию рассматривает IP-адреса как принадлежащие всему хосту, а не строго конкретному интерфейсу.

⏺Как это происходит

Допустим, eth0 имеет адрес 192.168.1.10, а eth1 - 192.168.1.20.

Сосед спрашивает, кому принадлежит 192.168.1.10. Запрос приходит на eth1, и Linux может ответить MAC-адресом eth1, хотя нужный IP назначен на eth0.

В результате ARP-таблица соседа может неожиданно меняться, а трафик начинает приходить не на тот интерфейс.

⏺Проверяем настройки

sysctl net.ipv4.conf.all.arp_ignore
sysctl net.ipv4.conf.all.arp_announce

При arp_ignore=0 Linux может отвечать на ARP-запросы за локальные IP независимо от интерфейса, на который пришёл запрос.

⏺Ограничиваем ARP-ответы

sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2

arp_ignore=1 разрешает отвечать только за адреса, назначенные входящему интерфейсу.
arp_announce=2 помогает избежать объявления неподходящего исходного IP в исходящих ARP-запросах.

N.A

Один VLAN не совпал, и DHCP перестал выдавать адреса

Клиент подключается к сети, линк поднят, но IP-адрес не получает. DHCP-сервер работает, свободные адреса есть, а Discover до него не доходит.

Проблема может быть в одном неверном PVID или настройке tagged/untagged на порту коммутатора.

⏺Где теряется DHCP Discover

Клиент отправляет DHCP Discover широковещательно, обычно без VLAN-тега.
Коммутатор принимает кадр и относит его к VLAN, заданному через PVID. Если вместо VLAN 20 на порту стоит VLAN 10, Discover попадёт не в тот широковещательный домен.

DHCP-сервер в VLAN 20 его просто не увидит.

⏺Проверяем VLAN на порту

На Linux bridge с включённой VLAN-фильтрацией:

bridge vlan show

Например:

eth1  10 PVID Egress Untagged
eth2  20

Здесь нетегированные кадры с eth1 попадут в VLAN 10, а не в VLAN 20.
Если клиент должен находиться в VLAN 20, проверяем и исправляем конфигурацию порта.

⏺Ищем Discover

tcpdump -eni eth1 'udp port 67 or 68'

Ключ -e показывает Ethernet-заголовок. На trunk-порту можно дополнительно проверить, с каким VLAN-тегом проходит DHCP-трафик.
Если Discover виден на клиентском порту, но отсутствует в нужном VLAN на uplink, проблема может быть в PVID, VLAN membership или правилах тегирования.

⚡️DHCP Discover не знает, в какой VLAN ему нужно попасть. Для нетегированного кадра это решает коммутатор. Один неверный PVID может отправить весь DHCP-трафик в чужую сеть.

N.A

RSS vs RPS vs RFS: кто распределяет сетевой трафик между CPU

На сервере 32 ядра, но при высокой сетевой нагрузке несколько ядер забиты под 100%, а остальные почти простаивают.

Проблема может быть в том, как входящие пакеты распределяются между CPU. В Linux для этого есть три механизма: RSS, RPS и RFS.

⏺RSS - распределение на уровне сетевой карты

NIC вычисляет хеш по заголовкам пакета и выбирает RX-очередь. Каждая очередь обычно обслуживается своим CPU через IRQ/NAPI.

Проверяем количество очередей:

ethtool -l eth0

Если у карты одна RX-очередь, аппаратное распределение трафика ограничено.

⏺RPS - распределение средствами ядра

Receive Packet Steering позволяет перенаправлять обработку пакетов на другие CPU уже после приёма через RX-очередь.
Смотрим маску разрешённых CPU:

cat /sys/class/net/eth0/queues/rx-0/rps_cpus

RPS полезен, когда аппаратных RX-очередей мало, но добавляет межъядерную обработку.

⏺RFS - распределение с учётом приложения

Receive Flow Steering идёт дальше. Он старается обрабатывать пакеты потока на том CPU, где выполняется приложение, которое их читает.

Это помогает уменьшить потери производительности из-за миграции данных между CPU-кешами.

Проверяем настройку:

cat /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

⚡️RSS выбирает аппаратную RX-очередь, RPS распределяет обработку по CPU, а RFS учитывает расположение приложения.

Но больше распределения не всегда означает выше производительность. На многоканальных NIC дополнительный RPS может только увеличить overhead.

N.A

PBR vs VRF: два способа управлять маршрутизацией

Обе технологии позволяют отправлять трафик не по обычной таблице маршрутизации. Но решают разные задачи.

⏺PBR (Policy-Based Routing) выбирает маршрут по заданным условиям. Например, весь трафик из подсети 192.168.10.0/24 должен идти через второго провайдера, даже если default route указывает на первого.

На Linux это можно сделать через ip rule:

ip rule add from 192.168.10.0/24 table 100
ip route add default via 10.0.0.1 dev eth1 table 100

Теперь пакеты из этой подсети используют таблицу 100. Остальной трафик продолжает маршрутизироваться по обычным правилам.

⏺VRF (Virtual Routing and Forwarding) создаёт отдельный routing domain со своей таблицей маршрутизации.

Например, на одном сервере работают две изолированные сети. У каждой свой default gateway, а адресные пространства могут даже пересекаться.

Создаём VRF:

ip link add vrf-blue type vrf table 100
ip link set vrf-blue up
ip link set eth1 master vrf-blue

Теперь eth1 принадлежит VRF, а маршруты подключённых к нему сетей находятся в таблице 100. Для отдельного default route его нужно настроить дополнительно.

Посмотреть маршруты:

ip route show vrf vrf-blue

Главная разница в том, что PBR выбирает таблицу или маршрут по условиям, а VRF привязывает интерфейсы и трафик к отдельному домену маршрутизации.

N.A

Один IP, два MAC: как ARP-конфликт ломает сеть

Два устройства случайно получили одинаковый IP-адрес. Оба доступны на L2, оба отвечают на ARP-запросы, но MAC-адреса у них разные.

Для соседних хостов начинается путаница. Один ARP-ответ связывает 192.168.1.50 с первым MAC, следующий может заменить запись на MAC второго устройства.

В результате соединения периодически обрываются, SSH зависает, а ping то проходит, то нет.

⏺Смотрим neighbor table

ip neigh show 192.168.1.50

Запись может меняться между двумя MAC-адресами. Но это не обязательно происходит после каждого ARP-ответа: Linux учитывает состояние записи и правила её обновления.

⏺Ловим конфликт

tcpdump -eni eth0 arp

Если два устройства отвечают за один IP, в захвате можно увидеть ARP Reply с одинаковым sender IP, но разными sender MAC.

Дополнительно проверяем адрес через arping:

arping -I eth0 -c 5 192.168.1.50

Несколько ответов с разными MAC - сильный признак конфликта.

⏺Что происходит с соединениями

Когда сосед начинает отправлять кадры на другой MAC, пакеты попадают не на тот сервер. Старое TCP-соединение при этом не переносится на новое устройство.

N.A

Миф: Port Security защищает от всех атак на L2

Port Security ограничивает количество MAC-адресов на порту коммутатора. Например, разрешаем один MAC, и если появляется второй, порт блокируется или начинает отбрасывать нарушающий трафик в зависимости от режима.

Кажется, что этого достаточно для защиты от посторонних устройств. Но Port Security контролирует MAC-адреса, а не поведение самого устройства.

⏺Rogue DHCP Server

Атакующий подключает устройство с разрешённым MAC и начинает раздавать клиентам неправильный шлюз или DNS. Port Security не анализирует DHCP-ответы.

Для этого нужен DHCP Snooping, который запрещает ответы DHCP-сервера с недоверенных портов.

⏺ARP Spoofing

Устройство с разрешённым MAC отправляет поддельные ARP-ответы, связывая IP шлюза со своим MAC.
Port Security не проверяет соответствие IP и MAC внутри ARP. Этим занимается Dynamic ARP Inspection, используя доверенные привязки, например из DHCP Snooping.

⏺Подмена разрешённого MAC

Если атакующий узнает допустимый MAC и использует его вместо своего, Port Security не сможет определить личность устройства только по этому адресу.
Для аутентификации применяют 802.1X, хотя и он требует правильной настройки.

На Cisco проверяем состояние защиты:

show port-security interface Gi0/1
show ip dhcp snooping
show ip arp inspection

⚡️Port Security ограничивает MAC-адреса на порту. DHCP Snooping контролирует DHCP-серверы, DAI проверяет ARP, а 802.1X аутентифицирует подключение.
Один механизм не заменяет остальные.

N.A

Как проверить, куда исчезают пакеты в nftables

Порт открыт, маршрут есть, но соединение не устанавливается.

Проверять десятки правил firewall вручную неудобно, особенно когда пакеты проходят через несколько цепочек.

В nftables есть трассировка, которая показывает путь пакета через правила.

⏺Сначала включаем трассировку для нужного трафика. Например, для TCP-подключений к порту 443:

nft add table inet debug
nft 'add chain inet debug trace_in { type filter hook prerouting priority -301; policy accept; }'
nft add rule inet debug trace_in tcp dport 443 meta nftrace set 1

Теперь запускаем мониторинг:

nft monitor trace

Пробуем подключиться к серверу с другого устройства.

⏺В выводе появятся цепочки и правила, через которые проходит пакет. Например:

trace ... rule tcp dport 443 drop
trace ... verdict drop

Так можно увидеть не просто факт блокировки, а конкретное правило, которое приняло решение.
Если пакет вообще не появляется в трассировке, стоит проверить, доходит ли он до выбранного hook и соответствует ли условию трассировки.

⏺После диагностики удаляем временную таблицу:

nft delete table inet debug

⚡️tcpdump показывает, что пакет пришёл на интерфейс. nft monitor trace помогает выяснить, что с ним произошло внутри nftables.

N.A

3 ошибки при настройке BGP prefix-list

Prefix-list кажется простой вещью: указал сеть, разрешил или запретил маршрут. Но одна неточная маска может изменить фильтрацию сразу для сотен префиксов.

⏺Забыли про le и ge

Например, на Cisco:

ip prefix-list FILTER permit 10.0.0.0/8

Это правило разрешает только точный префикс /8. Маршрут 10.10.0.0/16 под него не попадёт.

Чтобы разрешить более специфичные сети:

ip prefix-list FILTER permit 10.0.0.0/8 le 24

Теперь подходят префиксы от /8 до /24 внутри указанной сети.

⏺Случайно разрешили слишком много

ip prefix-list FILTER permit 0.0.0.0/0 le 32

Это не разрешение только default route. Такое правило подходит под любой IPv4-префикс.

Если нужен исключительно маршрут по умолчанию:

ip prefix-list FILTER permit 0.0.0.0/0

⏺Забыли про implicit deny

В конце prefix-list действует неявный запрет. Если маршрут не совпал ни с одним разрешающим правилом, он будет отклонён при применении списка как фильтра.
Проверяем:

show ip prefix-list FILTER
show ip bgp neighbors 192.0.2.1 advertised-routes

Последняя команда помогает увидеть, что реально анонсируется соседу. Синтаксис зависит от платформы.

⚡️В prefix-list важно не только указать сеть, но и правильно задать допустимую длину префикса. Разница между /8 и /8 le 24 может решить, какие маршруты вообще попадут к соседу.

N.A