Коротко и по делу — что проверить, как диагностировать и какие настройки менять (учитывая NAT и мультикаст/mDNS/IPv6).
Диагностика — последовательность шагов
1. Воспроизведите проблему и изолируйте:
- подтвердите, что ICMP (ping) проходит, а приложения/сервисы — нет.
- проверьте, доступны ли сервисы локально (не через VPN).
2. Traceroute / path checks:
- IPv4: `traceroute -I ` (ICMP) или `traceroute -T ` (TCP).
- IPv6: `traceroute -6 ` или `traceroute6`.
- Сравните трассы через VPN и без — найдите место, где пакеты «теряются» или меняют тип обработки (NAT/GW/VPN).
3. Захват трафика (tcpdump/tshark) — что и где смотреть:
- на клиенте: `tcpdump -i udp port $5353$ -n -vv` (mDNS), `tcpdump -i host ` для проблемных TCP/UDP соединений.
- на VPN-сервере и на границе NAT: те же фильтры, плюс `tcpdump -i esp or udp port $4500$ or udp port $500$` чтобы видеть IKE/ESP/NAT‑T.
- для IPv6 mDNS: `tcpdump -i udp and port $5353$ and ip6` или `ip6[40] == 0` (обычно достаточно `udp port $5353$`).
- ищите: запрос mDNS/Multicast у клиента, приходят ли ответы с сервера, меняются ли адреса/порт/TTL, фрагментация, ICMP (fragmentation needed).
4. Проверка мультикаста и mDNS-особенностей:
- mDNS — link‑local multicast: IPv4 $\mathrm{224.0.0.251}$, IPv6 $ff02::fb$, UDP порт $5353$. Эти адреса/пакеты обычно не маршрутизируются.
- проверьте, проходят ли пакеты на уровне L2 через VPN (bridged/tap) или только L3 (tun). Если tun (L3) — mDNS по умолчанию не будет проходить.
- tcpdump должен показать локальные mDNS-пакеты; если их нет на удалённой стороне — нужен репликатор/рефлектор или L2 мост.
5. MTU / фрагментация:
- VPN добавляет оверхед. Пример: Ethernet MTU $1500$. IPsec/UDP encapsulation может снять ~$50\text{–}70$ байт.
- формула: $$MT{U}_{vpn}=MT{U}_{path}-overhead$$ - проверьте Path MTU: запустите ping с флагом «не фрагментировать»: `ping -M do -s ` (IPv4) и подбирайте. Для IPv6 аналогично с `-s`.
- убедитесь, что ICMP «fragmentation needed» / ICMPv6 Path MTU не блокируется на пути.
- в большинстве случаев решают через MSS-clamping: iptables mangle `--clamp-mss-to-pmtu` либо настройку MSS в VPN-демоне.
6. NAT / NAT‑Traversal:
- проверьте, не блокирует ли NAT/файрвол ESP (IP protocol $50$) и IKE (UDP port $500$) — при наличии NAT требуется NAT‑T (UDP port $4500$).
- если используется IPsec, смотрите, есть ли корректная NAT‑T инкапсуляция (ESP over UDP $4500$).
- для TCP/UDP приложений проверьте, нет ли симметричного NAT, который ломает обратные соединения.
Что проверять в конфигурациях и логах
- VPN: режим (L2 vs L3), поддержка мультикаста, MSS/MTU параметры, NAT‑T включён, логи IKE/IPsec.
- Firewall/NAT: разрешённые протоколы/порты — UDP $5353$, multicast адреса $\mathrm{224.0.0.251}$ и $ff02::fb$ (хотя маршрутизироваться не будут), UDP $500$, UDP $4500$, ESP (IP $50$).
- Router: ICMP/ICMPv6 «fragmentation needed» не блокируется.
- Серверы mDNS/Avahi: включён ли reflector/relay (например `enable-reflector=yes` в avahi) или настроен ли mdns-repeater.
- Клиенты: используют ли IPv6-only сервис (требует передачи IPv6 через VPN) — проверьте маршруты IPv6 через туннель.
Возможные решения (в порядке предпочтения)
1. Сделать L2‑мост через VPN (bridged, OpenVPN tap / L2TP over IPsec / GRE+IPsec) — самый прямой путь для mDNS, но тяжелее в управлении.
2. Развернуть mDNS-рефлектор/репитер:
- на VPN‑сервере/маршрутизаторе включить avahi‑reflector или mdns‑repeater, чтобы ретранслировать mDNS между интерфейсами.
- учесть безопасность (репликация всех сервисов).
3. Использовать DNS‑SD через унифицированный DNS (унифицировать сервисы в центральной DNS) — если возможно, стабильное решение для кросс‑подсетей.
4. Включить multicast routing (PIM) — если сеть поддерживает и нужно масштабируемое маршрутизирование multicast.
5. Исправить MTU/MSS:
- настроить MSS clamp: iptables mangle POSTROUTING для TCP: `-j TCPMSS --clamp-mss-to-pmtu`.
- уменьшить MTU интерфейса VPN или клиента (например на $1400$ или в соответствии с фактическим overhead).
- убедиться, что ICMP/ICMPv6 не фильтруются.
6. NAT/TCP‑traversal:
- убедиться в поддержке NAT‑T (IKE/IPsec) — открыть UDP $4500$.
- при проблемах со статическим NAT/симметричным NAT — рассмотреть TURN/STUN/relay для клиентских приложений или перейти на VPN, который корректно работает через NAT (OpenVPN over UDP/TCP, WireGuard с публичным endpoint и корректными маршрутами).
Что смотреть в tcpdump/логах (конкретно)
- на клиенте: `tcpdump -i udp port $5353$ or host `
- видны ли запросы mDNS?
- на VPN‑сервере/удалённой сети: тот же фильтр — приходят ли запросы/ответы?
- на пограничном NAT: есть ли ESP или UDP $4500$/$500$ пакеты?
- для MTU: запуск `ping -M do -s `; в логах смотрите ICMP type $3$ code $4$ (fragmentation needed) или ICMPv6 Packet Too Big.
Краткие практические проверки командыми (примерно)
- traceroute IPv4: `traceroute -I `
- traceroute IPv6: `traceroute -6 `
- tcpdump mDNS: `tcpdump -i any udp port $5353$ -n -vv`
- tcpdump ESP/IK E: `tcpdump -i any proto 50 or udp port $500$ or udp port $4500$`
- MSS/MTU тест: `ping -M do -s $1472$ ` (для MTU $1500$: payload $1472$ + ip header $20$ + icmp $8$ = $1500$)
Итог — вероятные причины и быстрые фиксы
- Причина: mDNS — link‑local multicast, не проходит через L3 VPN/NAT. Фикс: avahi reflector/mdns-repeater или L2‑bridge или перенести сервисы в DNS.
- Причина: MTU/фрагментация из‑за VPN‑оverhead. Фикс: MSS-clamp / уменьшение MTU на туннеле / разрешение ICMP Fragmentation Needed.
- Причина: NAT/ESP блокируется или нет NAT‑T. Фикс: открыть UDP $500$/$4500$ и ESP (если возможно) или использовать VPN, который туннелирует через UDP/TCP.
- Причина: IPv6 не проброшен/фильтруется (ICMPv6, MLD). Фикс: проброс IPv6 через VPN, открыть ICMPv6 и MLD.
Если нужно, могу составить конкретный набор tcpdump/iptables/avahi команд под вашу конкретную реализацию VPN (OpenVPN/WireGuard/StrongSwan) и примерные значения MTU/overhead.