Blockiert der ISP UDP, oder ist es die App im Tunnel?

Jemand meldet, das VPN „blockiere UDP“, und dieser Satz verbirgt zwei völlig verschiedene Behauptungen. Die eine betrifft den Transport, den das Zugangsnetz sehen kann, die andere die Pakete einer Anwendung, nachdem sie im Tunnel entschlüsselt wurden. Ein verschlüsselter Tunnel lässt sich von außen ohne jeden Schlüssel filtern, und eine innere UDP-Anwendung kann aus Gründen scheitern, die nichts mit Filterung zu tun haben. Entscheiden Sie, welche Behauptung Sie prüfen, bevor Sie Belege sammeln.

Zwei Header, ein Wort

In einer IPsec-Bereitstellung mit NAT-Traversal ist das äußere Paket UDP, adressiert zwischen den beiden VPN-Endpunkten, typischerweise auf Port 4500. Darin trägt die verschlüsselte Nutzlast alles, was der Tunnel weiterleitet, und das kann selbst TCP oder UDP sein. Das Wort UDP erscheint also zweimal, mit unterschiedlicher Bedeutung und unterschiedlicher Sichtbarkeit.

Ein Zwischennetz sieht den äußeren Header und nichts vom inneren. Es kann den äußeren Fluss zulassen, formen oder verwerfen, und es muss dafür nichts entschlüsseln. Diese Asymmetrie ist der ganze Grund, warum die beiden Behauptungen verwechselt werden: Dasselbe Wort beschreibt, was das Netz filtert, und was die Anwendung sendet. Schreiben Sie die Schicht neben das Wort, wann immer Sie einen Befund festhalten, und die Verwechslung verschwindet weitgehend.

Der innere Header wird erst am empfangenden Endpunkt sichtbar, nach der Entschlüsselung. Ab diesem Punkt wird das Paket wie jedes andere weitergeleitet, abhängig von Routen, Richtlinien und der eigenen Filterung des Endpunkts. Das sind getrennte Entscheidungen, die verschiedene Geräte treffen.

Was das Netz noch sehen kann

Verschlüsselung verbirgt Nutzlast und inneren Transport-Header, nicht die Tatsache, dass ein Fluss existiert. Endpunktadressen, Ports, Paketgrößen und Zeitverhalten bleiben sichtbar, und das genügt, um Verkehr heuristisch zu klassifizieren oder ein bestimmtes Ziel zu blockieren.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

Die erste Aufzeichnung zeigt den äußeren Fluss auf der physischen Schnittstelle, die zweite den inneren Fluss auf der Tunnel-Schnittstelle. Beide gleichzeitig laufen zu lassen beantwortet die Frage direkt: Existiert der äußere Fluss und der innere nicht, hat die Anwendung nie etwas in den Tunnel geschickt. Existieren beide und kommt nichts zurück, liegt das Problem jenseits des Tunnels, am Ziel oder auf dem Rückweg.

RFC 3948 definiert die äußere UDP-Kapselung, und die ESP-Spezifikation definiert das geschützte Layout darin. Keines der beiden Dokumente verspricht, dass ein Zugangsnetz den äußeren Fluss durchlässt, weshalb ein Erreichbarkeitstest auf dem äußeren Tupel sinnvoll ist, bevor man eine Theorie über das innere hat. Ein blockiertes äußeres Tupel erzeugt einen Tunnel, der nie zustande kommt, nicht einen Tunnel, der zustande kommt und dann eine Anwendung verliert.

Warum eine UDP-App in einem funktionierenden Tunnel scheitert

Ein Tunnel, der eine Webanwendung, aber keine UDP-Anwendung transportiert, hat mehrere plausible Erklärungen, und die Filterung des inneren Protokolls durch den ISP ist nicht die erste. Am häufigsten ist die Abdeckung: Die beiden Anwendungen gelangen nicht beide in denselben Tunnel, weil die Route zum UDP-Ziel fehlt oder die Split-Tunnel-Regeln des Clients es ausschließen.

Die zweite ist der Endpunkt. Ein VPN-Server, der eine Protokollliste erlaubt, eine Firewall am Ziel oder ein Dienst, der nie auf dem erwarteten Port lauscht, erzeugen alle ein Zeitlimit, das wie eine Netzblocksperre aussieht.

Die dritte ist die Paketgröße. UDP-Anwendungen senden oft größere Datagramme als eine Webanfrage, und die Kapselung verringert die nutzbare MTU, sodass auf einen funktionierenden Handshake Stille bei der ersten voll großen Nutzlast folgen kann. Dieses Muster wird leicht als Sperre missdeutet, weil die kleinen Pakete durchkommen und die großen verschwinden. Eine kurze MTU-Prüfung klärt es in unter einer Minute, und die Antwort ist meist eine kleinere Nutzlast oder ein korrigierter MSS statt eines Netzfilters.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

Der erste Befehl prüft, ob ein großes Paket den Pfad mit deaktivierter Fragmentierung übersteht, was ein MTU-Problem schnell aufdeckt. Der zweite sendet einen kleinen, begrenzten UDP-Strom und meldet Verlust und Jitter. Ein Strom, der beginnt und dann stockt, deutet auf die Größe hin, nicht auf eine Sperre.

Melden Sie die Schicht, nicht das Protokoll

Schreiben Sie den Befund in einer von drei Formen: äußere Zustellung fehlgeschlagen, innere Weiterleitung fehlgeschlagen oder die Anwendung fehlgeschlagen. Jede hat einen anderen Verantwortlichen, und ihre Vermischung schickt das Ticket an das falsche Team.

Einen lokalen Port zu ändern kann am fernen Ende keinen passenden Listener erzeugen, daher ist ein clientseitiger Workaround, der zu helfen scheint, meist ein Beleg dafür, dass das ursprüngliche Ziel falsch war. Ebenso beweist ein geliefertes Alternativprofil etwas über die Erreichbarkeit und nichts darüber, ob die Anwendung korrekt konfiguriert ist.

Halten Sie Schlussfolgerung und Beobachtung ebenfalls getrennt. Verkehrsanalyse kann andeuten, was ein Fluss ist, ohne ihn zu entschlüsseln, und das ist ein nützlicher Befund, aber es ist nicht dieselbe Behauptung wie das Lesen des inneren Headers. Sagen Sie, welche der beiden Sie tatsächlich haben.