Миф: 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.

VLAN Translation: когда VLAN 100 превращается в VLAN 200

Представим, что две компании подключаются через сеть оператора. У первой используется VLAN 100, а у второй - VLAN 200.

Нужно объединить их в один L2-сегмент, но менять VLAN на оборудовании клиентов никто не хочет.

Для этого существует VLAN Translation - механизм переписывания VLAN-тегов прямо на коммутаторе.

⏺Как это работает?
Коммутатор получает Ethernet-кадр с тегом VLAN 100, заменяет VLAN ID на 200 и отправляет дальше.

При обратной передаче происходит обратная замена: VLAN 200 превращается в VLAN 100.

При этом IP-адреса, MAC-адреса и содержимое полезной нагрузки не меняются. Переписывается именно VLAN ID в заголовке 802.1Q.

⏺Как это настраивается?

На некоторых платформах Cisco с поддержкой VLAN mapping используется такой синтаксис:

interface GigabitEthernet1/0/1
 switchport mode trunk
 switchport vlan mapping 100 200
 switchport vlan mapping enable

Конкретные команды и ограничения зависят от модели и версии ПО.
Проверить настройки на поддерживаемых платформах можно командой:

show interfaces vlan mapping

⏺Где применяется?

Чаще всего VLAN Translation встречается в операторских сетях, при объединении инфраструктур и подключении клиентов с пересекающимися VLAN ID.

Но важно учитывать: трансляция не создаёт изоляцию сама по себе. Если несколько клиентских VLAN отображаются в один общий VLAN, их трафик может оказаться в одном широковещательном домене.

⚡️VLAN Translation позволяет соединять L2-сети с разной нумерацией VLAN без изменения конфигурации конечных устройств. Главное - правильно определить, где именно переписываются теги и какие сегменты после этого объединяются.

N.A.

3 команды для диагностики нестабильного OSPF-соседства

OSPF-соседство периодически переходит из Full в Down, а затем восстанавливается. При этом интерфейс остаётся UP, и обычный ping может не показывать проблем.

На Cisco IOS/IOS XE причину можно искать через три команды.

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

show ip ospf neighbor detail

Смотрим состояние соседства, Dead Timer, количество переходов между состояниями и время последнего изменения.

Если счётчик переходов растёт, соседство действительно нестабильно, даже если сейчас оно снова Full.

⏺Проверяем параметры интерфейса

show ip ospf interface GigabitEthernet0/0

Здесь видны Hello и Dead Interval, тип OSPF-сети, приоритет маршрутизатора и другие параметры.

Особенно важно сравнить таймеры на обоих концах соединения. Несовпадение Hello/Dead Interval обычно не позволяет установить соседство.

⏺Ищем причину последнего сброса

show logging | include OSPF

В логах можно найти сообщения об истечении Dead Timer, изменениях состояния соседей и других событиях OSPF.
Если соседство падает по Dead Timer, стоит проверить потери Hello-пакетов, загрузку control plane и фильтрацию IP-протокола 89.

⚡️Состояние Full показывает только текущую картину. Для диагностики нестабильного OSPF важнее история переходов, параметры интерфейса и причина последнего сброса соседства.

N.A.

Маршруты правильные, но трафик идёт по кругу: как найти MPLS-ловушку

В MPLS-сети может возникнуть ситуация, когда IP-маршрутизация выглядит исправной, но пакеты с метками зацикливаются между двумя LSR.

Причина - несогласованность таблиц пересылки меток после изменения топологии.

⏺Сначала проверяем LFIB

На Cisco IOS/IOS XE:

show mpls forwarding-table

Здесь видно, какую входящую метку маршрутизатор заменяет на выходную и какому next-hop отправляет пакет.

Если два соседних LSR пересылают трафик для одного FEC обратно друг другу, возможна петля на уровне MPLS.

⏺Проверяем путь с метками

traceroute mpls ipv4 10.20.30.0/24

На платформах с поддержкой MPLS LSP Ping/Traceroute команда помогает исследовать путь конкретного FEC через MPLS-сеть.

Если трассировка показывает повторяющиеся узлы, сравниваем LFIB на каждом из них.

⏺Ищем источник расхождения

show mpls ldp bindings

Проверяем, какие метки получены от соседей и соответствуют ли они ожидаемым FEC.

При этом важно отличать ошибку LDP от временной микропетли при сходимости IGP: таблицы могут быть корректными по отдельности, но обновляться на разных маршрутизаторах не одновременно.

⚡️В MPLS недостаточно проверить show ip route. Пакеты с метками пересылаются по LFIB, поэтому проблема может находиться в label forwarding, даже когда IP-маршрут выглядит совершенно нормальным.

N.A.

TCAM переполнен: почему новая ACL не применяется

Представим, что сетевой инженер добавил несколько правил ACL на коммутатор. Конфигурация сохранилась, ошибок в синтаксисе нет, но часть трафика продолжает проходить так, будто новых правил не существует.

Одна из возможных причин - закончились ресурсы TCAM.

⏺Что такое TCAM?

Ternary Content Addressable Memory - специальная память, которую коммутаторы используют для быстрого поиска совпадений по правилам.

В отличие от обычной памяти, TCAM умеет сопоставлять биты со значениями 0, 1 и «неважно». Благодаря этому оборудование может проверять ACL на скорости линии, не передавая каждый пакет процессору.

⏺Почему она заканчивается?

Одно правило ACL не обязательно занимает одну запись TCAM.

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

Кроме того, TCAM используется не только для ACL. В зависимости от платформы её ресурсы могут распределяться между маршрутизацией, QoS и другими функциями.

⏺Как проверить?
На поддерживаемых Cisco Catalyst можно посмотреть использование аппаратных ресурсов:

show platform hardware fed switch active fwd-asic resource tcam utilization

Команда зависит от модели и версии IOS XE. На других платформах используются собственные средства диагностики.

Также стоит проверить системные сообщения об ошибках программирования ACL в аппаратную таблицу.

⚡️Успешное сохранение ACL в конфигурации ещё не гарантирует, что все правила установлены в forwarding plane. При нехватке TCAM поведение зависит от платформы: она может отклонить изменение, сообщить об ошибке или применить ограничения. Поэтому после изменения крупных ACL важно проверять не только конфигурацию, но и аппаратные ресурсы.

N.A.

Как узнать, что изменилось в сети перед аварией

В 14:30 перестал работать один из VLAN. Интерфейсы UP, оборудование доступно, а в логах нет очевидных ошибок.

Через полчаса выясняется, что незадолго до сбоя кто-то изменил конфигурацию trunk-порта.

Чтобы не искать такие изменения вручную, используют Configuration Drift Detection.

⏺Сохраняем историю конфигураций

Для этого подходит Oxidized - инструмент, который регулярно подключается к сетевому оборудованию, забирает конфигурации и сохраняет их версии, например в Git.

Если на коммутаторе изменили allowed VLAN, в истории появится разница:

- switchport trunk allowed vlan 10,20,30
+ switchport trunk allowed vlan 10,20

Сразу видно, что VLAN 30 исчез из разрешённого списка.

⏺Проверяем, когда произошло изменение

На Cisco IOS/IOS XE при заранее включённом архивировании конфигураций можно использовать:

show archive log config all

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

⏺Сопоставляем события

Теперь сравниваем время изменения конфигурации с syslog, SNMP traps и событиями мониторинга.

Например, в 14:27 изменили trunk, а в 14:30 мониторинг зафиксировал недоступность устройств VLAN 30.

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

⚡️Configuration drift - это отклонение текущей конфигурации от сохранённой или эталонной. Если хранить историю изменений и сопоставлять её с событиями сети, расследование аварий становится значительно быстрее.

N.A.

DNS over HTTPS vs DNS over TLS: что меняется для корпоративной сети

Раньше администратор мог анализировать DNS-запросы сотрудников на UDP/53, блокировать нежелательные домены и выявлять подозрительную активность.

Но с появлением шифрованного DNS привычная схема перестала быть такой надёжной.

⏺DNS over TLS (DoT)

DNS-запросы передаются через отдельное TLS-соединение, обычно на TCP-порту 853.

Это удобно для сетевого контроля: администратор может обнаружить или ограничить такой трафик по порту. Но содержимое запросов без расшифровки уже не видно.

⏺DNS over HTTPS (DoH)

Здесь DNS-запросы передаются внутри HTTPS, обычно через порт 443.

Для сетевого оборудования такой трафик может выглядеть как обычное HTTPS-соединение. Простая блокировка UDP/53 или TCP/853 уже не гарантирует, что устройства используют корпоративный DNS.

Например, браузер может обращаться к внешнему DoH-резолверу, обходя локальную DNS-фильтрацию.

⏺Как контролировать DNS в корпоративной сети?

Обычно используют несколько подходов:

• Централизованно задают разрешённые DNS-резолверы через политики устройств и браузеров.
• Ограничивают обращения к неразрешённым DNS-сервисам.
• Анализируют DNS-логи корпоративного резолвера и контролируют настройки клиентов.

Проверить доступность конкретного DoH-сервера можно через:

curl -I https://dns.google/dns-query

Но такой запрос проверяет HTTPS-доступность endpoint, а не выполнение DNS-запроса через DoH.

⚡️DoT проще идентифицировать по отдельному порту, а DoH сложнее отличить от обычного HTTPS. Поэтому корпоративная DNS-безопасность всё больше зависит от управления конечными устройствами, а не только от правил на межсетевом экране.

N.A.

Incast: когда сотни серверов перегружают один порт

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

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

⏺Как возникает Incast?

Допустим, приложение запрашивает данные сразу у 100 серверов. Каждый отправляет ответ размером 256 КБ.

В сумме это 25 МБ данных, которые почти одновременно направляются к одному получателю.

Даже если каждый сервер подключён через 10 или 25 Гбит/с, выходной порт коммутатора в сторону получателя имеет ограниченную пропускную способность.

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

⏺Почему это опасно?

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

В некоторых случаях восстановление требует ожидания RTO, что резко увеличивает время выполнения всего запроса.

Особенно неприятно, когда приложение ждёт ответы от всех серверов: задержка одного соединения тормозит всю операцию.

⏺Как с этим бороться?

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

На уровне приложения помогает ограничение числа одновременных ответов или распределение их во времени.

N.A.