Скрипт массовой проверки SSL-сертификатов на пуле серверов

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

Проверка одного сертификата вручную:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate



-servername важен если на сервере несколько сертификатов через SNI, без него можешь получить не тот сертификат.

⏺Скрипт для пула серверов

#!/bin/bash
THRESHOLD_DAYS=14
BOT_TOKEN="ваш_токен"
CHAT_ID="ваш_chat_id"

while read -r host port; do
  expiry=$(echo | timeout 5 openssl s_client -connect "${host}:${port}" -servername "$host" 2>/dev/null \
    | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)

  if [ -z "$expiry" ]; then
    echo "$host:$port -> не удалось получить сертификат"
    continue
  fi

  expiry_epoch=$(date -d "$expiry" +%s)
  now_epoch=$(date +%s)
  days_left=$(( (expiry_epoch - now_epoch) / 86400 ))

  echo "$host:$port -> $days_left дней до истечения"

  if [ "$days_left" -lt "$THRESHOLD_DAYS" ]; then
    curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
      -d chat_id="${CHAT_ID}" \
      -d text="⚠️ SSL на ${host}:${port} истекает через ${days_left} дней"
  fi
done < hosts.txt



hosts.txt построчно:

example.com 443
api.example.com 443
mail.example.com 465



В cron раз в сутки:

0 9 * * * /usr/local/bin/check_ssl_pool.sh >> /var/log/ssl_check.log



⚡️timeout 5 в команде критичен. Если хост недоступен или порт фильтруется, openssl s_client может висеть бесконечно и весь скрипт встанет на первом проблемном сервере, не дойдя до остальных.

N.A

Как ECMP-хеш ломает диагностику, если не учитывать его

Запускаешь traceroute, видишь путь через линк А. Через минуту повторяешь, путь идёт через линк Б. Сеть не менялась, маршрутизация стабильная, просто ECMP распределяет пакеты по нескольким равностоимым путям, и хеш для каждого пакета может оказаться разным.

Хеш считается из набора полей: обычно src/dst IP, иногда плюс src/dst порт и протокол. Если поля совпадают, все пакеты одного потока стабильно идут одним путём. Если поля меняются, путь скачет.

Почему diagnostика ломается именно здесь

traceroute на каждом хопе увеличивает TTL и шлёт новый пакет. Каждый такой пакет, в зависимости от реализации, может менять src-порт.

Хеш каждый раз получается другой, и каждый “хоп” в выводе мог физически прийти с разного пути. Результат: рисуется путь который никогда не существовал как единый маршрут.

Проверяем влияет ли порт на хеш, фиксируя его явно:

traceroute -p 33434 host.com
traceroute -p 33434 host.com



Если оба запуска с одним и тем же src-портом дают одинаковый путь, а с разными портами разный, ECMP-хеш по портам подтверждён.

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

mtr --report -P icmp host.com



Как диагностировать честно при наличии ECMP

Используем dublin-traceroute или paris-traceroute, которые специально держат хеш-поля константными чтобы видеть один реальный путь, а не случайную выборку из нескольких:

paris-traceroute host.com



Запускаем несколько traceroute с разными зафиксированными портами, чтобы явно увидеть все альтернативные пути, а не один случайный:

for port in 33434 33450 33470; do
  traceroute -p $port host.com
done



⚡️ Если в выводе обычного traceroute путь выглядит нелогично или хопы “скачут”, не спеши искать проблему в сети. Сначала проверь не ECMP ли это просто рисует разные срезы параллельных путей как один маршрут.

N.A

Аудит мёртвых VLAN, которые никто не использует, но они висят в конфиге

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

Никто не решается удалить, потому что непонятно используется ли он где-то ещё. Со временем конфиг коммутатора превращается в архив никому не нужных записей.

Смотрим что вообще создано

show vlan brief



Список всех VLAN с именами и портами которые к ним привязаны.

Ищем VLAN без активных портов

Если у VLAN нет ни одного порта в статусе up, скорее всего он мёртвый:

show interfaces status | include connected
show vlan brief | exclude Gi



Вторая команда покажет VLAN у которых вообще нет привязанных интерфейсов.

Проверяем реальный трафик, не только наличие порта

Порт может быть подключён физически, но трафика годами нет:

show interfaces Gi0/5 | include packets



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

Смотрим MAC-таблицу по VLAN

Если в VLAN не учится ни один MAC за продолжительное время, там никого нет:

show mac address-table vlan 50



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

Сверяем с тем что реально проходит на trunk-портах

show interfaces trunk



Покажет какие VLAN разрешены на транке и какие из них активны (Vlans allowed and active in management domain). Если VLAN разрешён, но не активен, на этом сегменте трафика нет.

Перед удалением

Переводим в shutdown а не удаляем сразу, чтобы был путь назад если что-то всплывёт:

interface vlan 50
 shutdown



Через несколько недель без жалоб удаляем окончательно:

no vlan 50



⚡️Удалять VLAN из running-config без снятия его с интерфейсов сначала может привести к тому что порты останутся привязаны к несуществующему VLAN и перестанут передавать трафик вообще. Сначала убираем из интерфейсов, потом удаляем сам VLAN.

N.A

Proxy Protocol в проде: почему он ломает часть legacy цепочек

Proxy Protocol часто включают “для удобства” - чтобы backend видел реальный IP клиента за балансером.

На новых сервисах это работает прозрачно. На старых - начинает ломать соединения без явных ошибок.
Проблема в том, что legacy-сервисы ожидают, что TCP stream начинается сразу с прикладного протокола.

Проверяем, что реально приходит на backend:

tcpdump -A -s 0 port 443



И вместо TLS ClientHello или HTTP запроса можно увидеть:

PROXY TCP4 10.0.0.1 10.0.0.2 52344 443



Для современного стека это “метаданные”. Для старого TLS/HTTP парсера - это просто мусор в начале потока.
Смотрим где включён Proxy Protocol в балансировщиках:

nginx -T | grep proxy_protocol
cat /etc/haproxy/haproxy.cfg | grep send-proxy

Классическая ошибка в проде - несогласованность цепочки:

• LB1 добавляет PROXY header
• LB2 не настроен на его чтение
• backend ожидает чистый TLS/HTTP поток

В итоге соединение выглядит как random reset или silent drop без логики.
Проверяем TLS отдельно, чтобы исключить “ложную сеть”:

openssl s_client -connect backend:443



Если handshake не начинается или обрывается на старте - почти всегда причина не в TLS, а в лишних байтах перед ClientHello.

⚡️В реальности ломается не TCP и не TLS. Ломается предположение, что первый байт соединения принадлежит приложению.
Proxy Protocol добавляет слой “вне протокола”, и старые системы просто не умеют его игнорировать.

N.A

Почему “сеть живая”, но TLS handshake нестабилен

MTU + congestion + firewall inspection

TLS handshake часто выглядит как проблема сети, хотя линк и ICMP полностью стабильны.

Пинги идут, маршруты есть, TCP соединения иногда устанавливаются, но HTTPS периодически зависает на этапе ClientHello или ServerHello.

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

Handshake не про throughput, а про стабильную доставку небольших, но критичных пакетов в строгом порядке.

Проверяем базовую доступность TCP:

ss -ant dst :443



Если соединения есть, но handshake “плавает” - смотрим дальше.

Проверяем MTU путь, потому что TLS handshake часто выходит за MSS после добавления заголовков:

ping -M do -s 1472 1.1.1.1



Если требуется сильно уменьшать payload до стабильного ответа - есть фрагментация или blackhole MTU в пути (часто GRE/IPsec/VPN).
Смотрим реальный MSS на соединении:

ss -ti | grep -i mss



Если MSS выше реального MTU пути - TCP начинает дробить handshake, и любые потери превращаются в задержки вместо явных ошибок.
Далее фактор congestion и очередей. Если сеть не теряет пакеты, но перегружена по очередям:

cat /proc/net/softnet_stat



Рост dropped или time_squeeze означает, что handshake пакеты могут задерживаться внутри kernel, не доходя до NIC вовремя.
Отдельный слой - firewall inspection (stateful или DPI). Он может:

⏺задерживать первый SYN/SYN-ACK
⏺буферизовать TLS ClientHello
⏺делать reassembly потоков

Проверяем netfilter counters:

nft list ruleset
iptables -L -v -n

⚡️В реальности нестабильный TLS почти никогда не про “сломанный TLS”.
Это комбинация трёх эффектов:

• MTU ломает целостность handshake пакетов
• congestion вызывает задержки внутри kernel
• firewall inspection добавляет непредсказуемую буферизацию

И на уровне симптомов это выглядит как случайные зависания HTTPS при полностью “живой сети”.

N.A

Сегментация L2-сети с Private VLAN

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

Как работает Private VLAN

Private VLAN (PVLAN) — это расширение обычного VLAN, которое позволяет разделять трафик на уровне канального слоя:

⏺Promiscuous port — порт, который может общаться со всеми. Обычно это шлюз или маршрутизатор.
⏺Isolated port — порт, который может общаться только с promiscuous портом, но не с другими isolated портами.
⏺Community port — порты внутри одной группы могут общаться друг с другом и с promiscuous портом, но не с портами другой community.

Так можно изолировать клиентов, оставляя при этом доступ к общим ресурсам.

Практикуемся на Linux с bridge и VLAN

Создадим bridge с PVLAN-подобной логикой:

# Создаём главный bridge
ip link add name br0 type bridge
ip link set br0 up

# Создаём VLAN-подсети
ip link add link br0 name br0.10 type vlan id 10
ip link add link br0 name br0.20 type vlan id 20
ip link set br0.10 up
ip link set br0.20 up

# Настраиваем iptables, чтобы isolated VLAN не видел друг друга
iptables -I FORWARD -i br0.10 -o br0.10 -j DROP
iptables -I FORWARD -i br0.20 -o br0.20 -j DROP

# Разрешаем доступ к шлюзу (eth0)
iptables -A FORWARD -i br0.10 -o eth0 -j ACCEPT
iptables -A FORWARD -i br0.20 -o eth0 -j ACCEPT

Теперь устройства внутри VLAN 10 и VLAN 20 изолированы друг от друга, но могут использовать интернет через общий шлюз.

N.A

📂Как правильно документировать сеть, чтобы не потерять конфиги

Документирование сети кажется рутинной задачей, но на практике - это ключ к быстрому восстановлению, анализу и масштабированию. Вот как делать это по шагам.

1️⃣Сбор данных
Фиксируем все устройства, IP, VLAN, интерфейсы и протоколы маршрутизации.
Команды:

ip addr show          # список интерфейсов
ip route show         # таблица маршрутов
vtysh -c "show running-config"  # конфиги роутеров
show vlan brief       # VLAN на коммутаторах

2️⃣Структурирование: Систематизируем данные: топология, IP-план, протоколы, ACL/Firewall.
Пример таблицы IP:

Устройство | Интерфейс | IP           | VLAN | Примечание
-----------|-----------|--------------|------|------------
r1         | eth0      | 10.0.1.1/24  | 10   | WAN
sw1        | vlan10    | 10.0.1.2/24  | 10   | серверная зона
sw2        | vlan20    | 10.0.2.1/24  | 20   | офисная зона
server1    | eth1      | 10.0.1.10/24 | 10   | база данных
server2    | eth1      | 10.0.1.11/24 | 10   | веб-сервер

3️⃣Version control: Сохраняем конфиги в Git. Каждый коммит с комментарием: что и зачем изменилось.

git init
git add configs/
git commit -m "Добавлен новый VLAN 20 на sw2"

4️⃣Визуализация топологии: Diagram-as-code (Mermaid/Graphviz) или инструменты типа NetBox/Draw.io.
Пример Mermaid:

graph TD
    R1 --> SW1
    SW1 --> Server1
    SW1 --> Server2

5️⃣Автоматизация и backup: Скрипты для снятия конфигов и их сохранения в репозиторий или на NAS. Проверка актуальности backup. ✅

Полезные команды для контроля

git log --oneline --graph   # история изменений
diff old_config new_config  # что изменилось
ping 10.0.1.2              # проверить доступность после изменений

N.A.

Почему UDP checksum опционален в IPv4, но обязателен в IPv6

В IPv4 у UDP-заголовка есть поле checksum, но стандарт позволяет выставить его в ноль, что означает “checksum не вычислен”.

Принимающая сторона видит нули и просто не проверяет целостность. Исторически это делалось ради производительности: железо 80-х не справлялось с вычислением контрольных сумм на лету без потери скорости.

В IPv6 от этого отказались. Checksum в UDP обязателен, нулевое значение считается ошибкой и пакет дропается.

⏺Причина: IPv6 убрал checksum из собственного заголовка (в IPv4 он был), значит если UDP тоже не считает контрольную сумму, целостность данных вообще никем не проверяется на сетевом уровне.

Проверяем, как это выглядит в трафике:

tcpdump -i eth0 -v udp



В выводе увидим UDP checksum и флаг correct или incorrect. На некоторых интерфейсах с offload-ом checksum вычисляется на уровне NIC, а не ядра, и tcpdump может показывать incorrect на исходящих пакетах, хотя реально всё нормально.

Смотрим включён ли UDP checksum offload на интерфейсе:

ethtool -k eth0 | grep checksum



Где это реально создаёт проблемы

Туннели. VXLAN и некоторые GRE-реализации инкапсулируют пакеты с нулевым UDP checksum внутри IPv4. При переходе в IPv6-транспорт это невалидно и требует пересчёта или явного включения checksum на туннельном интерфейсе:

ip link set vxlan0 type vxlan udpcsum



N.A.

Как найти петлю в L2 без доступа к коммутаторам

Петля в L2 без STP это широковещательный шторм: broadcast-фреймы начинают множиться, загружают все порты, сеть деградирует до полной недоступности за секунды.

Диагностировать нужно быстро, и часто без доступа к коммутаторам.
Первый признак: резкий рост broadcast-трафика на интерфейсе.

Смотрим счётчики прямо сейчас:

watch -n 1 'ip -s link show eth0 | grep -A2 RX'



Если счётчик пакетов растёт на тысячи в секунду при минимальной нагрузке, петля активна.
Ловим broadcast-шторм живым трафиком:

tcpdump -i eth0 -n broadcast



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

Смотрим источник шторма по MAC:

tcpdump -i eth0 -n -e broadcast | awk '{print $2}' | sort | uniq -c | sort -rn | head -10



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

tcpdump -i eth0 -w /tmp/capture.pcap
tcpdump -r /tmp/capture.pcap -n | awk '{print $NF}' | sort | uniq -c | sort -rn | head



Локализация физически

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

watch -n 1 'ip -s link show eth0 | grep -A1 RX'



⚡️Если STP включён но петля всё равно есть, скорее всего где-то BPDU Guard сработал и порт ушёл в err-disabled, но петля успела образоваться через другой путь. Проверяй err-disabled порты если есть хоть какой-то доступ к одному коммутатору: show interfaces status err-disabled.

N.A.

Коммутатор начал флапать порты: где искать

Флап это когда порт циклически уходит в down и возвращается в up. Для STP каждый флап это topology change, пересчёт, временная потеря связности.

На загруженной сети даже один флапающий порт создаёт заметные проблемы.

Смотрим счётчики переходов состояния на всех портах:

show interfaces | include line protocol|changes
show interfaces counters errors



Порт с аномально высоким Link-state change count это он.

На Linux если коммутатор не Cisco:

ip monitor link
journalctl -k | grep "NIC Link"



ip monitor link показывает события в реальном времени, journalctl покажет историю флапов с таймстампами.

Физические причины

Самые частые: плохой кабель, разболтанный коннектор, неисправный SFP. Проверяем уровень сигнала на оптике:

show interfaces Gi0/1 transceiver
ethtool -m eth0



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

Программные причины

Если физика чистая, смотрим на STP и BPDU:

show spanning-tree detail | include changes
debug spanning-tree events



Частые topology change от конкретного порта могут быть вызваны устройством которое периодически уходит в сон, например IP-телефон или ноутбук.
Проверяем autonegotiation, несогласованный duplex тоже вызывает флапы:

show interfaces Gi0/1 | include duplex,speed



⚡️Если флап идёт строго по расписанию, например каждые несколько часов, смотри на spanning-tree hello timer и max-age. Иногда это не физика, а STP решает что сосед умер из-за потери BPDU на перегруженном канале.

N.A.

TCP Nagle algorithm: когда включён мешает и когда отключение ломает

Nagle придумали в 1984 чтобы не засорять сеть мелкими пакетами. Алгоритм простой: не отправляй новый пакет пока предыдущий не подтверждён, если данных меньше чем MSS. Мелкие записи буферизуются и отправляются одним куском.

На медленных линках 80-х это спасало. На современных сетях чаще мешает.

⏺Где Nagle создаёт проблемы

Интерактивные протоколы где важна задержка каждого пакета. SSH, Telnet, remote desktop, любой протокол запрос-ответ где клиент шлёт маленький запрос и ждёт ответа. Nagle держит пакет в буфере ожидая подтверждения предыдущего, задержка растёт.

Классический симптом: команды в SSH ощутимо залипают особенно на каналах с высоким RTT.

Проверяем включён ли Nagle на сокете через ss:

ss -tin dst <IP> | grep -i nagle



Отключается через TCP_NODELAY на уровне приложения:

int flag = 1;
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));



Или глобально через sysctl хотя это грубо:

sysctl -w net.ipv4.tcp_low_latency=1



⏺Когда отключение ломает

Высокопроизводительные системы где приложение шлёт много мелких write().

Без Nagle каждый write() становится отдельным пакетом, количество пакетов растёт в разы, нагрузка на сеть и CPU увеличивается. Базы данных и файловые серверы обычно держат Nagle включённым именно поэтому.

⏺Взаимодействие с delayed ACK

Самая неприятная комбинация: Nagle на отправителе плюс delayed ACK на получателе. Отправитель ждёт ACK перед отправкой следующего пакета, получатель откладывает ACK до 200мс надеясь что будет что пигибэкнуть. Оба ждут друг друга, задержка 200мс гарантирована.

tcpdump -i eth0 -nn host <IP> | grep -E "ACK|PSH"

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

⚡️ Правильное решение не отключать Nagle глобально, а делать это точечно на конкретных сокетах где важна латентность. Глобальное отключение на сервере с mixed workload ухудшит производительность для одних приложений пока улучшает для других.

N.A.

Как устроен транзитный BGP и чем отличается от пиринга

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

Транзит

Платишь провайдеру за то что он несёт твой трафик куда угодно в интернете. Провайдер анонсирует тебе full routing table, десятки тысяч префиксов, ты через него достигаешь любой AS. Он в свою очередь анонсирует твои префиксы своим апстримам и пирам.

Отношение клиент-провайдер в BGP community обозначается как customer cone. Провайдер принимает маршруты от тебя и распространяет их дальше, ты платишь за каждый мегабит.

router bgp 65001
 neighbor 198.51.100.1 remote-as 1299
 neighbor 198.51.100.1 description Telia-Transit
 neighbor 198.51.100.1 route-map TRANSIT-IN in
 neighbor 198.51.100.1 route-map TRANSIT-OUT out



Пиринг

Два оператора договариваются обмениваться трафиком бесплатно, но только своим собственным трафиком и трафиком своих клиентов.

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

Крупные CDN и контент-провайдеры пирятся агрессивно именно поэтому: им выгодно отдавать трафик напрямую, минуя транзит.

neighbor 203.0.113.1 route-map PEER-IN in
neighbor 203.0.113.1 route-map PEER-OUT out

route-map PEER-OUT permit 10
 match ip address prefix-list OWN-PREFIXES



PEER-OUT анонсирует только собственные префиксы, не транзитные маршруты клиентов или других пиров.

Технически чем отличается

У транзитного провайдера LOCAL_PREF на маршруты от клиентов обычно выше чем от пиров, выше чем от апстримов.

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

route-map TRANSIT-IN permit 10
 set local-preference 100

route-map PEER-IN permit 10
 set local-preference 150

route-map CUSTOMER-IN permit 10
 set local-preference 200



⚡️ Пиринг не всегда бесплатный. Paid peering это когда один из участников платит другому за обмен трафиком, обычно когда трафик сильно асимметричный. Netflix платит за пиринг с крупными ISP именно потому что трафик идёт почти только в одну сторону.

N.A.

Как IGMP snooping решает проблему multicast-флуда и где ломается

Без IGMP snooping коммутатор не знает кто хочет получать multicast-трафик. Multicast MAC не изучается через обычный ARP, поэтому коммутатор обращается с ним как с broadcast: флудит на все порты.

В сети с видеостримингом или IPTV это убивает полосу на портах где этот трафик никому не нужен.

IGMP snooping решает это пассивно: коммутатор подслушивает IGMP-сообщения между хостами и роутером и строит таблицу кто на какую группу подписан. Multicast уходит только на порты где есть реальные получатели.

Смотрим таблицу IGMP snooping на Cisco:

show ip igmp snooping groups
show ip igmp snooping



Где ломается

⏺Первая проблема: querier. IGMP snooping требует чтобы кто-то периодически спрашивал хосты “вы ещё в группе?”. Обычно это роутер. Если роутера нет в сегменте или он не шлёт IGMP queries, коммутатор не получает ответов, записи в таблице устаревают и трафик снова начинает флудить.

Включаем IGMP querier на коммутаторе если роутера нет:

ip igmp snooping querier
ip igmp snooping querier address 192.168.1.1



⏺Вторая проблема: неизвестный multicast. Если группа не в таблице snooping, коммутатор флудит её на все порты по умолчанию. На коммутаторах где это поведение нежелательно:

no ip igmp snooping flood-unknown-multicast

⏺Третья проблема: статические записи против динамических. Если хост не шлёт IGMP join (некоторые приложения не умеют), запись в таблице не появится и трафик не дойдёт. Добавляем вручную:

ip igmp snooping vlan 10 static 239.1.1.1 interface Gi0/5



N.A.

Проверка VLAN-тегов в сети

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

⏺порт настроен как access, а мы отправляем трафик с тегами;
⏺тег VLAN не совпадает с конфигурацией на другом конце;
⏺свич отбрасывает кадры из «неразрешённого» VLAN.

Смотрим теги через tcpdump

sudo tcpdump -i eth0 -nn -e vlan

• -e — выводит Ethernet-заголовок;
• vlan — фильтрует кадры с тегами 802.1Q.

Пример:

12:30:45.123456 ethertype 802.1Q (0x8100), VLAN 100, IP 192.168.10.2 > 192.168.10.1: ICMP echo request

Здесь видно, что кадр принадлежит VLAN 100.

Проверка конкретного VLAN

sudo tcpdump -i eth0 vlan 200

Покажет только кадры из VLAN 200. Полезно, чтобы убедиться, что нужный VLAN действительно идёт по линку.

Тест с arping

Можно проверить связность внутри VLAN:

sudo arping -I eth0.100 192.168.100.1

Здесь eth0.100 — подинтерфейс, созданный для VLAN 100. Если ответ есть, значит VLAN на этом пути работает.

Создание VLAN-интерфейса в Linux

sudo ip link add link eth0 name eth0.100 type vlan id 100
sudo ip addr add 192.168.100.10/24 dev eth0.100
sudo ip link set eth0.100 up

Теперь можно тестировать трафик напрямую по этому VLAN.

N.A.

Что такое RPF check и почему он дропает валидный трафик

RPF (Reverse Path Forwarding) check это механизм защиты от spoofed-источников в multicast и unicast uRPF. Роутер получает пакет и проверяет: если бы я отправлял пакет обратно к источнику, ушёл бы он через тот же интерфейс на котором пришёл? Если нет, пакет дропается.

Логика простая: легитимный трафик приходит с той стороны откуда роутер знает маршрут до источника. Если пакет пришёл с “неправильного” интерфейса, скорее всего адрес подделан.

Где ломается на валидном трафике

Асимметричный роутинг. Пакет от источника 10.0.0.1 пришёл на интерфейс eth1, но маршрут до 10.0.0.1 в таблице указывает через eth0. RPF check проваливается, пакет дропается, хотя трафик абсолютно легитимный.

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

Проверяем включён ли uRPF на интерфейсе:

show ip interface Gi0/0 | include verify



Смотрим счётчики дропов от RPF:

show ip traffic | include unicast RPF
show cef interface Gi0/0 | include RPF



На Linux:

cat /proc/net/stat/rt_cache | grep rpf



Два режима uRPF

⏺Strict mode: маршрут до источника должен указывать именно на интерфейс где пришёл пакет. Ломается при асимметричном роутинге.

⏺Loose mode: маршрут до источника должен просто существовать в таблице, через любой интерфейс. Защищает от пакетов с несуществующими источниками, но пропускает асимметричный трафик.

На Cisco переключаем в loose:

interface Gi0/0
 ip verify unicast source reachable-via any

Strict mode:

interface Gi0/0
 ip verify unicast source reachable-via rx



На Linux:

sysctl -w net.ipv4.conf.eth0.rp_filter=1



1 это strict, 2 это loose, 0 отключён.

N.A.