Коротко — системная методика: собрать логичную цепочку «где пакеты доходят / где перестают / что происходит с ответом», используя tcpdump на всех ключевых точках (интернет-край, маршрутизатор филиала, сервер), traceroute/tracepath, проверку ARP/MAC и таблиц маршрутизации/NAT/conntrack/ACL, затем локализовать причину (NAT, MTU, ACL/фаервол, асимметрия маршрутов и т.п.) и исправить конфигурацию (стат. NAT/Policy‑NAT, MSS‑clamp, правки ACL/маршрутов или VPN). Ниже — подробная пошаговая методика, типичные причины и способы устранения.

1) Подготовка и общая стратегия

Нужны захваты пакетов на трех логических точках:
1) На краевом маршрутизаторе филиала (ingress снаружи и egress к серверу).
2) На внутреннем интерфейсе коммутатора / порту сервера или на самом сервере.
3) По возможности — на удалённой стороне (или пуш-логах от провайдера).Сравнить временные метки и последовательности TCP (SYN/SYN‑ACK/ACK), ARP, ICMP сообщений.Проводить тесты с небольшим количеством сессий (SYN на конкретный порт) и повторять изменения по одному.

2) Сбор трафика и базовые проверки (команды и что смотреть)
a) tcpdump / packet capture

На маршрутизаторе филиала (ingress/egress):
tcpdump -n -s 0 -w /tmp/rtr-in.pcap host and host Уточняющие фильтры для TCP‑handshake:
tcpdump -n 'host and host and tcp[tcpflags] & tcp-syn != 0' (SYN)
tcpdump -n 'host and host and tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)' (SYN‑ACK)На сервере: tcpdump -n -i host and tcp
Что смотреть:
Доходит ли SYN до маршрутизатора? Доходит ли до сервера? Приходит ли SYN‑ACK обратно?Если SYN есть на внешнем интерфейсе Rtr, но нет на внутреннем — NAT/DNAT или ACL запрещают форвард.Если SYN до сервера, сервер отвечает, но SYN‑ACK не возвращается до remote — проблема на обратном пути/NAT/маршрутизация.

b) Traceroute / tracepath

traceroute -n (или traceroute -T -p для TCP)Сравнить путь туда и обратно (traceroute с сервера к remote и с remote к серверу).
Что искать:
Асимметрия маршрутов: ответ идёт по другому каналу (резервный линк/VPN) и NAT/состояние на краю не совпадает.Хоп, на котором пакет «исчезает».

c) ARP / MAC / L2

На маршрутизаторе: show ip arp | arp -aНа коммутаторе/сервере: arp -a, ip neigh
Что искать:
Правильное соответствие IP→MAC на интерфейсе сервера; нет ли конфликта MAC/duplicated IP.Если маршрутизатор не может ARP’нуть сервер — возможно VLAN/порт/кабель/серверная сетевая конфигурация.

d) Таблицы маршрутизации и политики

Cisco/Juniper: show ip route; show route; show ip route vrf ...Linux: ip route show
Что искать:
Маршрут к remote с правильным next‑hop; не переключается ли трафик на резервный интерфейс.Наличие policy‑routing / PBR, VRF, ECMP (многопутевой возврат).

e) NAT/conntrack/ACL/Firewall

NAT: show ip nat translations / show nat translations / iptables -t nat -L -nconntrack: conntrack -L | grep (или netstat -tnp)ACLs: show access-lists / iptables -L -n -vVPN: show crypto ipsec sa / show vpn status / ipsec status
Что искать:
Существует ли запись NAT/conntrack для сессии? Если SYN проходит, но нет NAT entry — DNAT не сработал.ACL на маршрутизаторе/файрволе блокирует форвард.На VPN — правила/transform set/interesting traffic ограничивают потоки.

f) MTU и фрагментация

tracepath или ping с DF:
ping -M do -s Что искать:
Блокируется ли ICMP Fragmentation Needed, что останавливает TCP handshake/передачи больших пакетов.Рекомендуется тестировать с маленьким MSS/MTU.

3) Как интерпретировать частые сценарии (типичные причины и индикаторы)
a) NAT‑симметрия / асимметричный NAT (возврат идёт не через тот NAT)

Индикатор: SYN доходит до маршрутизатора филиала и, возможно, до сервера; сервер отвечает, но ответ проходит другим путем/через другой NAT и не попадает в запись conntrack на исходном маршрутизаторе. В tcpdump: SYN виден на внешнем интерфейсе, ответ SYN‑ACK виден на другом интерфейсе или не виден вообще.Причина: балансировка между VPN и резервным каналом, динамические маршруты; NAT­table на одном устройстве не содержит записи о входящей сессии, поэтому ответ игнорируется.Устранение:
Обеспечить симметричность пути: настроить политику маршрутизации (PBR), static route для конкретного source/destination, чтобы и вход и выход шли через один интерфейс.Использовать policy‑NAT или создать статическую проброску (DNAT/SNAT) для проблемных сервисов.На провайдере/point‑of‑presence согласовать маршруты.

b) MTU / Path MTU/фрагментация

Индикатор: соединение устанавливается, но при передаче больших данных зависает; или SYN доходит, но пакеты с большими сегментами теряются; tracepath показывает уменьшение MTU или ICMP «Fragmentation needed» отбрасывается.Причина: где‑то по пути меньший MTU (например, GRE/IPSec тоннель), но блокируется ICMP Fragmentation Needed → TCP жутко медлит.Устранение:
Разрешить ICMP Type 3 Code 4 (Fragmentation Needed) на всех межсетевых экранах.Включить MSS clamping на краевом роутере / iptables: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuЛибо снизить MTU на интерфейсе сервера/endpoint/интерфейсе туннеля.

c) Правила фаервола / ACL блокируют трафик

Индикатор: tcpdump показывает пакет на внешнем интерфейсе роутера, но на внутреннем он отсутствует; логи ACL/файрвола показывают deny; нет записи conntrack.Устранение:
Просмотреть и скорректировать ACL: разрешить нужные порты/подсети и состояния (established).В правилах stateful firewall — разрешать RELATED,ESTABLISHED и корректно настроить DNAT+filtering последовательность (порядок правил).

d) VPN конфигурация / crypto ACLs

Индикатор: пакеты до маршрутизатора и не попадают в tunnel; show crypto ipsec sa показывает no matching SA или ACL не тот.Устранение:
Проверить crypto ACL/interesting traffic, настроить маршруты через туннель (route‑based vs policy‑based).Убедиться, что NAT не выполняется до/после того места, где ожидается (NAT‑Т с IPsec требует внимания).При использовании резервного канала — гарантировать, что tunnel остаётся стабильным или настроить failover без асимметрии сессий.

e) Серверный фаервол / локальная сетевая ошибка

Индикатор: tcpdump на маршрутизаторе показывает SYN до сервера, но tcpdump на сервере не видит пакет → либо L2 проблема, либо порт отключён, либо VLAN/маппинг неправильный. Если сервер видит SYN и отвечает, но ответ уходит в неверный шлюз — сервер имеет неправильный маршрут/default gateway.Устранение:
Проверить интерфейс сервера, VLAN, MAC, bridge, ip addr, default gateway.На сервере iptables/ufw/restrictive firewalld — разрешить входящие соединения, проверить route.

4) Практические команды/приёмы (образцы)

На Linux роутере/файрволе:
tcpdump -n -i eth0 host and host -s 0 -w /tmp/out.pcapip route showip rule show; ip route show table conntrack -L | grep iptables -t nat -L -n -vtracepath ping -M do -s 1472 (проверка MTU)На Cisco:
show ip nat translationsshow ip nat statisticsdebug ip nat (в тестовой среде)show access-listsshow ip routeshow ip arpshow crypto ipsec satraceroute ip (или traceroute tcp )

5) Рекомендации по устранению и превентивные меры

Для NAT/асимметрии:
Сделать маршруты симметричными: policy routing, закрепление исходящих сессий в один интерфейс.Настроить static NAT/портфорвардинг для критичных сервисов.Увеличить время жизни NAT-сессий при необходимости.Для MTU:
Включить MSS clamping на краевом устройстве.Разрешить ICMP «Fragmentation Needed».При необходимости уменьшить MTU на туннелях.Для ACL/фаервола:
Ввести логирование deny‑записей и просмотреть логи при тестах.Переставить/поправить порядок правил (DNAT до фильтрации).Для VPN/резервного канала:
Гарантировать, что VPN‑сессии «видят» тот же исходный/конечный IP и что NAT не ломает IPSec (NAT‑Traversal настроен).Рассмотреть route‑based VPN (tunnel интерфейс) для предсказуемой маршрутизации.На failover: сохранить stateful связки или использовать sticky routes для сессий.Мониторинг:
Включить capture при инцидентах, хранить pcap с временными метками.Настроить SNMP/NetFlow/sFlow для обнаружения асимметричных потоков.

6) Пример короткого сценария диагностики (шаги один за другим)

На маршрутизаторе: tcpdump на внешнем и внутреннем интерфейсе при попытке подключения извне. Зафиксировать есть ли SYN на внешнем и на внутреннем. Если SYN есть на внешнем, но нет на внутреннем — проверить NAT/DNAT/ACL. Просмотреть show ip nat translations и access‑lists. Если SYN есть на внутреннем, сервер не видит — проверить ARP/MAC/порт коммутатора; на сервере tcpdump. Если сервер отвечает, но remote не получает — сделать capture на внешнем интерфейсе и поискать SYN‑ACK; проверить таблицу маршрутизации и conntrack. Если пути разные (traceroute), скорректировать маршруты/политику так, чтобы ответ возвращался через тот же NAT.

Если нужно, могу:

составить список конкретных команд для вашей платформы (Cisco IOS/ASA, Juniper, Linux) по шагам;помочь проанализировать конкретный tcpdump/pcap (выложите вывод или снапшоты);предложить конфигурационные сниппеты (MSS clamp, policy‑NAT, статические DNAT).