Один 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

NAT44 vs NAT64: как IPv6-клиент подключается к IPv4-серверу

Обычный NAT44 меняет IPv4-адреса, но сам протокол остаётся прежним. NAT64 работает иначе: позволяет клиенту из IPv6-only сети обращаться к серверу, у которого есть только IPv4.

⏺NAT44 чаще всего встречается на домашних маршрутизаторах. Несколько устройств с приватными IPv4-адресами выходят в интернет через один публичный адрес.

Например, 192.168.1.10:50000 превращается в 203.0.113.5:40001. Маршрутизатор запоминает соответствие и возвращает ответы нужному клиенту.

⏺NAT64 переводит пакеты между IPv6 и IPv4. Но сначала клиенту нужно получить IPv6-адрес назначения.

Для этого часто используется DNS64. Если у сервера есть только A-запись, DNS64 может синтезировать AAAA-запись с IPv4-адресом внутри специального IPv6-префикса.

Например, для IPv4 192.0.2.10 при использовании префикса 64:ff9b::/96 получится:

64:ff9b::192.0.2.10

Клиент отправляет IPv6-пакет на этот адрес. NAT64-шлюз извлекает IPv4-адрес назначения, преобразует пакет и пересылает его серверу уже по IPv4.

Проверить DNS-ответ можно командой:

dig AAAA ipv4only.arpa

В сети с DNS64 такой запрос помогает обнаружить используемый NAT64-префикс.

⏺Главное ограничение: DNS64 не поможет приложению, которое обращается напрямую к IPv4-литералу и не умеет работать с IPv6. Для таких случаев могут потребоваться дополнительные механизмы, например CLAT в составе 464XLAT.

N.A.

Как проверить PoE-потребление без доступа к устройству

IP-камера периодически перезагружается, хотя сетевой линк работает нормально. Причина может быть не в сети, а в питании через PoE.

Чтобы это проверить, необязательно идти к камере с тестером. Управляемый PoE-коммутатор часто показывает параметры питания прямо через CLI.

⏺Смотрим общий бюджет PoE

На Cisco Catalyst:

show power inline

Команда показывает доступную мощность, сколько уже выделено подключённым устройствам и сколько осталось.

Важно не путать allocated power и фактическое потребление. Коммутатор может зарезервировать для камеры 15,4 Вт, хотя сейчас она использует значительно меньше.

⏺Проверяем конкретный порт

show power inline Gi1/0/10 detail

В зависимости от модели и версии ПО можно увидеть класс PoE, выделенную мощность, состояние питания и измеренное потребление.

Например, камера днём потребляет 6 Вт, а ночью включает ИК-подсветку и нагреватель. Потребление растёт, и если мощности недостаточно, устройство может перезагрузиться.

⏺Ищем события питания

show logging | include ILPOWER

На поддерживаемых Cisco Catalyst так можно найти сообщения об отказе в питании, превышении лимита или отключении PoE на порту.

Если коммутатор не показывает фактические ватты, ориентируемся на выделенную мощность, класс устройства и события контроллера PoE. Не все модели умеют измерять потребление в реальном времени.

N.A.

4 команды для диагностики оптического линка в Linux

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

⏺Проверить параметры SFP-модуля

ethtool -m eth0

Если модуль и драйвер поддерживают диагностику, увидим температуру, напряжение, мощность передатчика (Tx) и принимаемого сигнала (Rx).

Особенно интересен Rx Power. Слишком слабый сигнал может указывать на загрязнённые коннекторы, затухание или проблемы с оптикой. Сравнивать значение нужно с допустимым диапазоном конкретного модуля.

⏺Посмотреть ошибки интерфейса

ethtool -S eth0

Ищем счётчики CRC/FCS, symbol errors и другие ошибки приёма. Названия зависят от драйвера.
Важно смотреть не только абсолютные значения, но и растут ли они со временем.

⏺Проверить FEC

ethtool —show-fec eth0

На поддерживаемых интерфейсах команда покажет настроенный и активный режим Forward Error Correction.

Если доступны счётчики исправленных и неисправимых ошибок FEC, они помогут заметить ухудшение линии ещё до массовых потерь пакетов.

⏺Проверить согласованную скорость

ethtool eth0

Смотрим Speed, Duplex и Link detected. Так можно обнаружить, что интерфейс поднялся не в ожидаемом режиме.

N.A.

Как Ethernet временно останавливает передачу

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

Но Ethernet умеет не только отбрасывать кадры. В некоторых сетях он может попросить соседнее устройство временно прекратить передачу.

⏺Как это работает?

В стандарте IEEE 802.3x предусмотрены специальные PAUSE-кадры. Если включён Flow Control, перегруженный приёмник может отправить такой кадр соседу.

Внутри указывается время паузы в единицах по 512 битовых интервалов. 

Получив кадр, сосед временно приостанавливает обычную передачу данных по линку.

При этом PAUSE действует на весь линк, а не на отдельное TCP-соединение.

⏺Как проверить в Linux?

Посмотрим настройки сетевой карты:

ethtool -a eth0

В выводе интересуют RX и TX: разрешён ли приём PAUSE-кадров и может ли интерфейс отправлять их сам.

Статистику можно поискать через:

ethtool -S eth0 | grep -i pause

Названия счётчиков и их доступность зависят от драйвера.

⏺В чём подвох?

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

Из-за этого Flow Control не всегда улучшает производительность. Иногда он просто переносит перегрузку на соседнее устройство.

N.A.

Почему два коммутатора могут одновременно считать себя главным шлюзом

В сети используется MLAG: два физических коммутатора объединены в логическую пару, а серверы подключены сразу к обоим через LACP.

Всё работает нормально, пока между коммутаторами не пропадает служебное соединение — peer-link.

⏺Что происходит при разрыве?

Через peer-link устройства обмениваются служебной информацией и синхронизируют часть состояния.

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

Особенно опасна ситуация, когда одновременно нарушается и дополнительный канал проверки доступности — keepalive.

Тогда возникает риск split-brain: оба коммутатора считают, что могут самостоятельно обслуживать общие подключения.

⏺Чем это грозит?

В зависимости от реализации MLAG возможны дублирование кадров, MAC flapping, нарушения пересылки и потери трафика.

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

⏺Как защищаются от split-brain?

Обычно используют отдельный peer-keepalive, который проходит независимо от peer-link.

Кроме того, многие реализации MLAG при потере peer-link автоматически отключают определённые порты на вторичном коммутаторе, чтобы не допустить одновременной независимой работы пары.

Конкретное поведение зависит от производителя и настроек.

N.A.