Возможные источники ошибки (кратко):
- NAT traversal / двойной NAT / PAT: трансляция источника (SNAT/PAT) меняет исходный IP/порт, NAT-таблица не совпадает при возврате — потеря ответа.
- Асимметричный роутинг: пакеты идут по одному пути, ответы — по другому, где нет нужной NAT‑записи или нет маршрута.
- MTU/фрагментация и PMTUD: туннелирование (IPsec/GRE) уменьшает доступный MTU → фрагментация или «black hole» если ICMP blocked.
- ESP/GRE и NAT: ESP (IP‑proto $50$) не содержит портов — стандартный PAT его не отслеживает; для IPsec нужен NAT‑T (UDP $4500$). GRE (IP‑proto $47$) через NAT требует стат. проброс/специальная поддержка.
- Conntrack/timeouts: короткие таймауты NAT/conntrack, переполнение таблицы, отсутствие keepalive.
- Firewall / RP‑filter: reverse path filtering и ACL могут блокировать асимметричный трафик.
- Ошибки политики VPN (policy-based routing, split‑tunnel): неверные списки источников/назначений.
Пошаговая стратегия диагностики:
Шаг $1$: собрать симптомы
- Зафиксировать что видит конечная служба (видимый source IP/порт, протокол).
- Когда именно — постоянная/интерамитентная, после какого времени теряется связь.
Шаг $2$: пакетные захваты на контролируемых точках
- Сниффить на: клиенте/внутреннем фаерволе, каждом NAT‑у на входе/выходе, точке терминирования VPN, на сервере.
- Примеры: tcpdump: `tcpdump -n -i eth0 host and host `; для ESP: `tcpdump -n -i eth0 'ip proto 50'`; для GRE: `tcpdump -n -i eth0 'ip proto 47'`.
- Сравнить IP/порт до/после NAT, увидеть, инкапсулируется ли трафик в UDP (NAT‑T).
Шаг $3$: проверить NAT/conntrack
- Просмотреть NAT‑таблицы: `iptables -t nat -L -n -v` и conntrack: `conntrack -L | grep `.
- Проверить, создаётся ли mapping для ответного трафика и совпадает ли он по протоколу/порту.
Шаг $4$: проверить маршрутизацию и асимметрию
- traceroute в обе стороны: ICMP/UDP/TCP (например, `traceroute -T -p 443`) чтобы увидеть разные пути.
- На каждом роутере проверить `ip route` и policy routing (ip rule), чтобы понять, вернётся ли ответ тем же способом.
Шаг $5$: MTU и фрагментация
- Тест PMTUD: `ping -M do -s ` уменьшать размер; искать «fragmentation needed» ICMP. Пробуйте размеры около MTU туннеля: типично для Ethernet MTU $1500$ → полезная нагрузка для туннеля = $1500$ − туннель‑overhead.
- Захватить пакеты с DF‑битом и проверить, приходят ли ICMP‑unreach.
Шаг $6$: VPN/ESP/GRE‑специфика
- Убедиться, что IPsec настроен с NAT‑T если NAT по пути (использует UDP $4500$ и port $500$ для IKE).
- Для GRE проверить, поддерживает ли NAT GRE и есть ли стат. трансляция на GRE‑endpoint.
Шаг $7$: логирование и таймауты
- Смотреть логи VPN/файрвола на ошибки rekey/seq / NAT timeout.
- Проверить conntrack timeout для протокола; увеличить при необходимости.
Исправления (конкретные меры):
- Сделать путь симметричным или обеспечить обратную трансляцию:
- статические SNAT/DNAT (1:1) или статические маршруты, чтобы ответы возвращались через тот же NAT.
- если сервис должен видеть реальный клиент, используйте проброс/forwarding или прокси, либо X‑Forwarded‑For на прикладном уровне.
- Для IPsec через NAT: включить NAT‑T (UDP $4500$), разрешить UDP $500$ и UDP $4500$ и протокол ESP $50$ в ACL.
- Для GRE: организовать статическую проброску/поддержку GRE на NAT‑устройстве или инкапсулировать GRE в UDP.
- MTU/MSS:
- установить MSS clamping: `iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu`.
- или уменьшить MTU на туннельном интерфейсе (например до $1400$ или подходящего значения).
- Отключить или корректировать rp_filter:
- `sysctl -w net.ipv4.conf.all.rp_filter=0` (или настроить per‑iface), если асимметрия законна.
- Увеличить conntrack таблицу/таймауты или добавить keepalives:
- увеличить значения в `/proc/sys/net/netfilter/nf_conntrack_max` и таймауты.
- Логирование/мониторинг: включить детальное логирование NAT/conntrack, добавить регулярные captures для реконструкции проблем.
- Тестировать изменения пошагово: после каждой правки — повторный capture + проверка corr. NAT записи и return path.
Короткий чек‑лист для быстрого устранения:
1) Убедиться, что сервер видит ожидаемый source IP/port.
2) Если нет — посмотреть NAT‑mapping и сделать статичный DNAT/SNAT или прокси.
3) Если пакеты инкапсулируются (ESP/GRE) — включить/настроить NAT‑T или статический проброс.
4) Проверить асимметрию маршрутов и либо выровнять маршрутизацию, либо отключить rp_filter.
5) Исправить MTU/MSS и убедиться в прохождении ICMP "fragmentation needed".
Если пришлёте конкретные примеры capture (хедера IP, видимый src/dst/протокол на сервере и на пограничных интерфейсах), сделаю целевой разбор и дам точечные команды исправления.