Warum das Blockieren von sämtlichem ICMP einen funktionierenden VPN-Pfad zerstört
Größenrückmeldungen sind keine Ping-Antworten. Wenn sie nie ankommen, gelingen kleine Pakete, große verschwinden, und der Tunnel wirkt wie flatternd.
Ein Tunnel, der sich authentifiziert, einen Ping überträgt und dann beim ersten großen Transfer hängt, ist das klassische Zeichen einer fehlenden ICMP-Nachricht und nicht eines defekten VPN. Der Absender erfährt nie, dass ein Paket zu groß war, wiederholt dieselbe Größe, und die Anwendung wartet. Das zu beheben ist eine Entscheidung über die Firewall-Richtlinie, keine Neuinstallation des Clients. Die Reihenfolge zählt: messen, wo die Größengrenze liegt, dann die Regel einengen, die den Bericht verschluckt hat.
Was ICMP auf diesem Pfad tatsächlich transportiert
IPv4-Pfad-MTU-Erkennung beruht darauf, dass ein Router meldet, ein Paket mit gesetztem don't-fragment-Bit habe nicht weitergeleitet werden können. Diese Meldung ist eine ICMP-Fragmentation-Needed-Nachricht, und ohne sie hat der Absender keinen Grund, seine Segmentgröße zu verringern. IPv6 ist strenger: Router fragmentieren nicht im Transit, daher ist eine ICMPv6-Packet-Too-Big-Nachricht das einzige Signal, das den Absender schrumpfen lässt.
Beide Nachrichten sind Rückmeldungen der Steuerungsebene, und keine von ihnen ist ein diagnostisches Echo. Eine Richtlinie, die Ping blockiert, und eine, die sämtliches ICMP blockiert, sehen in einer Regelliste ähnlich aus und verhalten sich im Netz sehr unterschiedlich. Die zweite kann einen korrekt dimensionierten Tunnel in einen Einbahnpfad für alles verwandeln, was größer ist als das kleinste Glied der Kette.
Manche Transporte implementieren ihre eigene Erkennung mit Sondierungspaketen, wie RFC 4821 beschreibt, und sind von dieser Rückmeldung weniger abhängig. Das spricht dafür zu prüfen, welchen Transport man betreibt, nicht dafür anzunehmen, jeder Tunnel sei immun.
| Nachricht | Zweck auf dem Pfad | Wenn blockiert |
|---|---|---|
| ICMPv4 Typ 3 Code 4 | Das Paket war zu groß für die nächste Strecke | Der Absender wiederholt und bleibt hängen |
| ICMPv6 Typ 2 | Packet Too Big, das IPv6-Äquivalent | Derselbe Stillstand, ohne Fragmentierungsrückfall |
| ICMP Typ 11 | Zeit überschritten, von traceroute genutzt | Diagnose verliert Hops, der Verkehr fließt weiter |
| ICMP-Echoanfrage und -antwort | Erreichbarkeitstest | Ping schlägt fehl, der Pfad kann in Ordnung sein |
Der Fehler hängt von der Größe ab
Fragen Sie, ob der Fehler mit der Paketgröße korreliert. Eine Anmeldeseite, eine DNS-Abfrage und ein kurzer API-Aufruf gelingen, während ein Dateiupload, eine große Antwort oder ein Bilddownload hängen. Dieses Muster deutet auf eine Größengrenze irgendwo zwischen den beiden Enden hin, nicht auf Authentifizierung oder Routing. Ein erfolgreicher kleiner Ping sagt fast nichts darüber aus, wo diese Grenze liegt.
Innerhalb eines Tunnels sind zwei Schichten zu bedenken: das Nutzlastpaket und das äußere gekapselte Paket. Der innere Absender kann sich korrekt verhalten, während der äußere Pfad kleiner ist, als der Tunnel annimmt; deshalb zählen sowohl die eigene MTU-Einstellung des Tunnels als auch die physische Strecke darunter.
Messen, bevor Regeln bearbeitet werden
Sondieren Sie mit dem don't-fragment-Bit und einer selbst gewählten Nutzlastgröße, vom fehlerhaften Client in Richtung einer geschützten Adresse:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7Eine Nutzlast von 1472 Byte plus 28 Byte Kopfzeilen ergibt ein Paket von 1500 Byte. Scheitert die große Sondierung mit einem Fragmentierungsfehler und gelingt die kleinere, haben Sie die Grenze gefunden; rechnen Sie den Tunnel-Overhead ein und wiederholen Sie, bis die funktionierende Größe stabil ist.
Bestätigen Sie dann, dass die Lücke der Bericht selbst ist. Scheitert die Sondierung still, ohne Fehler und ohne Antwort, wird die Nachricht wahrscheinlich verworfen statt zugestellt, und die Regel ist verdächtig.
Regel einengen, dann die Aufgabe erneut testen
Die Korrektur sollte die konkreten Steuernachrichten erlauben, nicht das ganze Protokoll. Auf einem iptables-Host ist die Form eine typspezifische Freigabe; passen Sie die Syntax an das an, was die Firewall auf Ihrer Plattform verwaltet:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTLassen Sie Echo-Antworten blockiert, wenn das die lokale Richtlinie ist, denn der Pfad braucht sie nicht. Testen Sie dann den ursprünglich fehlgeschlagenen Transfer aus einer neuen Verbindung erneut und bestätigen Sie, dass die Regelzähler die ankommenden Nachrichten zeigen.
Hängt der große Transfer auch nach der Freigabe der Nachrichten weiter, liegt die verbleibende Grenze anderswo: eine zu hoch gesetzte Tunnel-MTU, ein Proxy, der Pakete umschreibt, oder eine Middlebox, die verwirft statt zu melden. Die ICMP-Regel war notwendig, nicht ausreichend.