Warum die DNS-Antwort an einer zustandslosen VPN-Edge-Firewall scheitert

Der Tunnel steht, Clients erreichen den VPN-Host, und der Host kann nichts auflösen. Seine eigenen ausgehenden Anfragen verlassen die Schnittstelle sauber, also liegt der Fehler auf dem Rückweg: an einer vorgelagerten Edge, die eingehenden Verkehr filtert, ohne sich zu merken, was der Host gerade gesendet hat. Den Tunnelport zuzulassen beschreibt diesen Austausch überhaupt nicht. Die Antwort auf eine DNS-Anfrage ist ein eigener Flow, und wenn die Edge zustandslos ist, hat nichts sie zur Rückkehr berechtigt.

Die beiden Austausche sind nicht derselbe Austausch

Schreiben Sie die Tupel auf, und der Fehler wird offensichtlich. Der Zielport der Anfrage wird zum Quellport der Antwort, also das Gegenteil dessen, was die meisten erwarten, wenn sie eine eingehende Regel für Port 53 hinzufügen:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Eine eingehende Regel, die Zielport 53 verlangt, beschreibt Verkehr an einen DNS-Listener, der auf dem Host läuft, und das ist ein völlig anderer Dienst. Diese Adressen sind Dokumentationsbeispiele, und der Quellport wird vom Client pro Anfrage gewählt, also ist er kein Wert, den man in eine Regel kopieren und weiter funktionieren erwarten kann.

Zustandslose Edge versus zustandsbehaftete Host-Firewall

Ein zustandsloser Edge-Filter bewertet jedes eingehende Paket gegen seine Regelliste, ohne dass eine Verbindungstabelle dahintersteht. Eine ausgehende Anfrage, die erfolgreich hinausging, erzeugt keine Erlaubnis für ihre eingehende Antwort, weil das Gerät keinen Vermerk hat, dass je eine Anfrage stattfand. Eine zustandsbehaftete Host-Firewall ist das Gegenteil: Ihre Verbindungsverfolgung erkennt den Rückverkehr eines erlaubten Austauschs und lässt ihn ohne Regel für die Antwort passieren. Beide Grenzen existieren in einem typischen Pfad, und beide müssen das beabsichtigte Paket zulassen.

Der Vergleich ist wichtig, weil die beiden Geräte unterschiedlich scheitern. Eine zustandsbehaftete Firewall, die die Antwort verweigert, protokolliert einen Drop; eine zustandslose Edge verweigert sie still, weshalb der Host einfach in einen Timeout läuft.

Bauen Sie die Erlaubnis um das Protokoll, nicht um eine Portnummer

Grenzen Sie die Regel auf die tatsächlichen Resolver-Adressen, den Zielhost und die Empfangsport-Richtlinie ein, die das Produkt unterstützt. Denken Sie auch an den TCP-Pfad von DNS, denn eine große Antwort oder ein Rückfall wegen Kürzung verlagert den Austausch auf TCP, und eine reine UDP-Regel deckt ihn nicht ab. Unterstützt die Edge zustandsbehaftete Inspektion für einen definierten Flow, ziehen Sie diese einer handgeschriebenen Antwortregel vor, denn der zustandsbehaftete Pfad folgt den vom Client gewählten Ports automatisch.

Bestätigen Sie dann, welches Produkt im Pfad den Verkehr tatsächlich filtert. Ein dokumentierter IPv4-Edge-Bereich begründet keine IPv6-Richtlinie, und anbieterinterner Verkehr durchläuft diesen Filter möglicherweise nie.

Warum das Zulassen eines beliebigen Quellports 53 keine Lösung ist

Eine Regel, die alles akzeptiert, was Quellport 53 behauptet, ist eine Regel, die akzeptiert, was ein Absender in ein Headerfeld schreibt. Die Portnummer authentifiziert den Absender nicht und beweist nicht, dass die Nutzlast eine gültige Antwort ist, also vergrößert die Regel die Angriffsfläche des Hosts, ohne die Auflösung zuverlässiger zu machen. Behalten Sie Quellbeschränkungen und die eigenen Antwortprüfungen des Clients, einschließlich der Quellport-Randomisierung, bei, statt sie abzuschalten, um eine Zugriffsliste zu vereinfachen.

Ist der Resolver ein Dienst, den Sie kontrollieren, genügt die Beschränkung auf seine Adressen. Ist er ein öffentlicher Resolver, beschränken Sie auf die Adressen, die Sie freigegeben haben, und vermerken Sie sie im Kommentar der Regel.

Prüfen Sie an der richtigen Grenze, in der richtigen Richtung

Zeichnen Sie an Host und Edge dieselbe Anfrage auf und vergleichen Sie die Tupel statt der Paketzahlen. Eine Anfrage, die auf beiden Seiten sichtbar ist, ohne dass auf der Hostseite eine Antwort sichtbar ist, deutet auf den eingehenden Filter hin; eine nur auf der Hostseite sichtbare Anfrage deutet auf Routing oder den Resolver selbst hin. Wiederholen Sie das mit einer TCP-Anfrage, wenn Sie nur eine UDP-Erlaubnis haben, denn genau das ist die Lücke, die der erste Test nicht sehen kann.

Das zu beheben vervollständigt einen DNS-Austausch, den der Host wirklich braucht. Es macht den Host nicht zu einem öffentlichen Resolver, genehmigt keine weitergeleiteten VPN-Flows und beweist nicht, dass DNS die Ursache eines irgendwie unabhängigen Tunnelproblems war.