Ping durch ein VPN: Warum Regeln für Echo-Antworten den Rückweg verfehlen

Pingen Sie einen Host über ein VPN, und die Anfrage geht als ein ICMP-Typ hinaus und kommt als ein anderer zurück, was ausreicht, um jede in Ports formulierte Regel zu verwirren. In einem Echoaustausch gibt es keinen Ziel-Dienstport, der in die Rückregel kopiert werden könnte, und ein Filter, der Symmetrie erwartet, verwirft die Antwort, während die Anfrage ungehindert passiert. Die Korrektur beginnt damit, das Paket so zu lesen, wie es tatsächlich ist, und dann zu entscheiden, welche Grenze auf dem Weg die Entscheidung trifft. Meist arbeiten zwei Schichten, während die dritte die Antwort still verwirft. Die folgenden Abschnitte trennen sie in der Reihenfolge, in der ein Paket ihnen begegnet.

Das Paket wechselt den Typ, nicht den Port

Eine Echoanfrage ist ICMP-Typ 8, Code 0, und trägt eine Kennung und eine Sequenznummer. Die Antwort ist Typ 0, Code 0, mit derselben Kennung und Sequenz, wobei die IP-Endpunkte vertauscht sind. RFC 792 definiert diese Felder, und die Kennung ist es, die einen Absender Antworten seinen eigenen Anfragen zuordnen lässt.

Was fehlt, ist ebenso wichtig: Es gibt keinen TCP- oder UDP-Header, also keinen Port, der erlaubt werden müsste. Eine Regel, die einen Port für eine Echo-Antwort nennt, beschreibt ein Paket, das nie existieren wird. Das ist der häufigste Fehler in VPN-Ping-Tickets. Die Regel wirkt spezifisch, gilt für nichts und lässt den Fehler genau dort, wo er war.

Drei Kontexte entscheiden über das Paket

Wenn der Ping einen Host im fernen LAN anspricht, muss das Gateway die Anfrage weiterleiten. Wenn er eine Adresse anspricht, die zum Gateway selbst gehört, endet sie stattdessen im lokalen Eingabepfad. Wenn das Gateway den Ping selbst auslöst, beginnt das Paket in seinem eigenen Ausgabepfad und durchläuft die Weiterleitungsentscheidung überhaupt nicht.

Diese drei Kontexte haben unterschiedliche Regelketten und unterschiedliche Zähler, und sie als einen zu behandeln ist der Grund, warum „die Firewall erlaubt ICMP“ dennoch einen fehlgeschlagenen Ping ergeben kann. Der äußere Tunnel ist ein vierter Kontext: Den VPN-Listener zu erlauben erlaubt nicht automatisch die entkapselte innere Anfrage, und eine innere Erlaubnis sagt nichts darüber, ob der äußere Tunnel steht.

Zustandsbehaftete und zustandslose Filter behandeln die Antwort unterschiedlich

Eine zustandsbehaftete Firewall, die die Anfrage hat hinausgehen sehen, kann die Antwort diesem Fluss zuordnen und sie ohne zweite Regel durchlassen. Ein zustandsloser Filter hat kein solches Gedächtnis, deshalb braucht die Rückrichtung ihre eigene ausdrückliche Erlaubnis, mit vertauschter Quelle und vertauschtem Ziel.

Prüfen Sie, welches Modell das Produkt tatsächlich umsetzt, bevor Sie etwas schreiben. Eine Regel für Echoanfragen deckt nicht zwangsläufig Echo-Antworten ab, und ein Produkt, das ICMP-Abfragen verfolgt, kann auf Antworten, die auf einer anderen Schnittstelle eintreffen, dennoch eine andere Richtlinie anwenden.

Begrenzen Sie, was Sie erlauben. Jede Echo-Antwort von überall zu erlauben ist nicht dasselbe wie das Abschließen einer zustandsbehafteten Zuordnung, und eine Typnummer authentifiziert den Absender nicht.

Die Übersetzung ändert auch die Kennung

Wenn die Quellübersetzung beabsichtigt ist, passt das Tupel am fernen Ende nicht zu dem, das der Client gesendet hat. Ein NAT kann die Kennung der ICMP-Abfrage zusammen mit den Adressen übersetzen, sodass das Beharren auf derselben Nummer auf beiden Seiten eine falsche Abweichung erzeugt.

Korrelieren Sie stattdessen die Zuordnung, die der Übersetzer meldet. Ein Übersetzer, der die Kennung umschreibt, wird die Nummer, die Ihr Client protokolliert hat, nicht bewahren, also behandeln Sie die Zuordnung als Identität und nicht die Nummer. Verfolgen Sie dann eine identifizierbare Anfrage durch den Pfad: Bestätigen Sie, dass sie das Ziel mit der erwarteten Quelle erreicht, bestätigen Sie, dass das Ziel eine Antwort ausgesendet hat, verfolgen Sie die Route dieser Antwort zurück, und bestätigen Sie, dass der Client sie empfangen hat, statt nur zuzusehen, wie ein Gateway-Zähler steigt.

Falten Sie ICMP-Fehler nicht in die Echorichtlinie

Die Meldung „Fragmentierung erforderlich“, die die Pfad-MTU-Erkennung nutzt, ist keine Echo-Antwort, und ihre Nutzlast zitiert das Paket, das sie ausgelöst hat. Eine reine Echo-Erlaubnis, die diese Fehler still verwirft, verwandelt ein Größenproblem in eine hängende Verbindung, was das Gegenteil von hilfreich ist.

Dieselbe Vorsicht gilt für Adressfamilien. ICMPv6 verwendet andere Nachrichtentypen und trägt wesentliche Funktionen, die IPv4 nicht hat, sodass das Kopieren dieser Nummern in eine IPv6-Regel schlicht falsch ist.

Wenn der Echoaustausch funktioniert, testen Sie die eigentliche Anwendung separat. Ein erfolgreicher Ping beweist den Rundlauf eines Protokolls bei einer Größe zu einem Ziel, und er ist keine Lizenz anzunehmen, HTTPS, SMB oder jeder andere Fluss sei erlaubt.