Например, у вас есть сервер в локальной сети с внутренним IP 192.168.1.100, и у него проброшен внешний IP (скажем, 203.0.113.10) через NAT на роутере.

Если вы с другого устройства в той же локальной сети попытаетесь подключиться к 203.0.113.10 (например, к веб-серверу на порту 80), то без настройки hairpinning это, как правило, не сработает — трафик не “заходит обратно” в локальную сеть.

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

Роутер смотрит на пакеты, которые пришли с локального интерфейса, направленные на его же внешний IP, и перенаправляет их обратно во внутреннюю сеть, применяя DNAT к локальному IP сервера.

Пример настройки iptables для NAT Hairpinning

Предположим:
⏺Внешний IP роутера: 203.0.113.10
⏺Локальный сервер: 192.168.1.100
⏺Сервис на порту 80 (HTTP)

Выполните такие правила (от имени root):

# Проброс порта с внешнего IP на локальный сервер

iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.100:80



# Разрешаем возвратный трафик

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.1.100 -p tcp --dport 80 -j MASQUERADE

• Правило в PREROUTING меняет адрес назначения с внешнего IP на внутренний.
• Правило в POSTROUTING маскирует исходящий трафик, чтобы сервер видел запросы как от роутера, и мог отправить ответ обратно корректно.

N.A. ℹ️ Help

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

1️⃣Разные настройки на портах

Разные speed/duplex или MTU ломают агрегацию. Разное VLAN-назначение (trunk/access) приводит к непредсказуемым сбоям.

Пример ошибки:

switchport mode trunk

switchport trunk allowed vlan 10,20

…на одном порту, а на другом 10,30.

2️⃣ Смешивание режимов LACP/PAgP

LACP (active/passive) и PAgP (desirable/auto) несовместимы. Если на одном конце LACP, а на другом PAgP — бандл не поднимется.

3️⃣ Использование “on” без протокола

Режим on игнорирует LACP/PAgP и форсит агрегацию. Если на другом конце LACP — возникнет misconfiguration.

4️⃣ Разные load-balancing алгоритмы

На разных устройствах балансировка (src-mac, src-dst-ip и т.д.) может распределять трафик неравномерно. Результат тут — недозагрузка линков.

5️⃣ Игнорирование диагностики

Многие настраивают, но не проверяют. Результат — «висячие» линков в состоянии standby.

Быстрая диагностика

show etherchannel summary       ! Статус каналов

show running-config interface   ! Проверить одинаковость настроек

show lacp neighbor              ! Состояние LACP

ℹ️ Help

Во многих инфраструктурах ICMP считают «ненужным» и отрубaют его на периметре — мол, безопасность, чтобы никто не пинговал.

В результате получаем баги, которые тяжело отлаживать: от медленного SSH до обрыва TLS.

Path MTU Discovery (PMTUD) в TCP/IP полагается на ICMP Type 3 Code 4 (Fragmentation Needed).

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

Признаки в продакшене:
• SSH или HTTPS зависает сразу после подключения
• TLS соединение срывается без ошибки
• ping до узла работает, но curl или scp — нет
• MTU выше по цепочке (например, GRE или IPsec) не согласуется

Как диагностировать
⏺Проверка MTU:

ip link | grep mtu  

ip route get 

ping -M do -s 1472   # для MTU 1500 с учетом IP+ICMP

⏺Анализ через tcpdump:

tcpdump -i eth0 icmp or tcp port 443

Если нет ICMP Fragmentation Needed — значит, он кем-то фильтруется.

⏺Проверка firewall’ов:
Убедитесь, что правила (например, в iptables или cloud security group) не блокируют ICMP Type 3.

Как лечить
Пропустить ICMP Type 3 на периметре (или хотя бы Code 4):

iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT

Уменьшить MSS вручную на туннелях или при NAT:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \

  -j TCPMSS --clamp-mss-to-pmtu

Проверить, не отключен ли PMTU discovery в системе:

sysctl net.ipv4.ip_no_pmtu_disc

ℹ️ Help