UFW verwirft den DNS-Server der VPN, sobald der Tunnel steht

Namen lassen sich in dem Moment nicht mehr auflösen, in dem sich die VPN verbindet, während ein Ping an eine öffentliche Adresse weiter antwortet und der Firewall-Status nichts Falsches zeigt. An der Richtlinie hat sich nichts geändert; geändert hat sich, dass eine neue Schnittstelle aufgetaucht ist, und die Standard-Verweigerung deckt sie vom ersten Paket an ab. UFW entscheidet nach Richtung und Schnittstelle, deshalb sagt eine Regel für die WLAN-Strecke nichts über Verkehr aus, der den Tunnel verlässt. Die Reparatur ist eine Handvoll enger Regeln, in einer bestimmten Reihenfolge angewendet.

Das Symptom zeigt sich erst, wenn der Tunnel steht

Eine Standard-Verweigerungsrichtlinie tut genau, was ihr gesagt wurde: Alles ohne passende Regel wird abgelehnt, auf jeder Schnittstelle, die existiert. Der Tunnel existierte nicht, als die Regeln geschrieben wurden, also kann keine von ihnen ihn erfassen, und die Verweigerung, die immer da war, gilt nun für die Namensauflösung. Direkter Verkehr zu einer wörtlichen Adresse kann noch funktionieren, wenn eine breitere Erlaubnis ihn abdeckt, und deshalb gelingt ein Ping an einen öffentlichen Resolver, während die Namenssuche scheitert. Die Lücke ist eine Regel für eine Schnittstelle, die die Richtlinie noch nie gesehen hat.

Das erklärt auch, warum sich der Fehler sauber umkehrt: Tunnel abbauen, und Namen lösen wieder auf, weil die Abfrage zu einer Schnittstelle zurückkehrt, die Regeln hat. Eine Richtlinie, die nur bei stehendem Tunnel scheitert, ist kein DNS-Problem, und am Resolver selbst zu drehen kostet hier die meiste Zeit. Lies die Schnittstellenliste, bevor du die Resolver-Konfiguration liest.

Drei Richtungen, drei verschiedene Regelsätze

Eine einzelne Sitzung berührt Regeln in mehr als einer Richtung, und ein Tunnel fügt fast jeder davon eine zweite Schnittstelle hinzu. Wenn du den Verkehr zuerst nach Richtung und Schnittstelle sortierst, wird der Rest mechanisch, denn jede Zeile unten braucht ihre eigene Regel an ihrem eigenen Ort. Die Beispiele verwenden tun0 und einen Pool von 10.8.0.0/24, also ersetze die Namen und Bereiche durch die aus der eigenen Ausgabe des Clients.

Zwei Zeilen werden oft verwechselt, weil beide den Tunnel erwähnen. Eine Regel für den Resolver lässt Verkehr zu, den der Client in den Tunnel schickt, während eine Regel für SSH Verkehr zulässt, den der Server daraus empfängt; sie leben auf verschiedenen Maschinen und scheitern unabhängig. Die Zeile, die am häufigsten vergessen wird, ist die zweite, denn der Client kann den Tunnel überhaupt nicht aufbauen, bis sein Verkehr zur öffentlichen Adresse des Servers erlaubt ist. Arbeite von oben nach unten, und jeder Fehler hat eine mögliche Ursache.

Ein geschobener Resolver braucht eine eigene Regel

Ob der Tunnel DNS trägt, hängt davon ab, was der Server sendet. Ein Server, der eine Resolver-Option schiebt, installiert eine private Adresse in der Konfiguration des Clients, und diese Adresse ist nur über den Tunnel routbar. Schiebt der Server nichts, behält der Client den Resolver, den er schon hatte, und die Regeln unten haben nichts zuzulassen. Prüfe den geschobenen Zustand und das aktuelle Abfrageergebnis, bevor du etwas schreibst:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Die Statusausgabe nennt den verwendeten Resolver und die Strecke, an die er gebunden ist, und die Routensuche dahinter zeigt, welche Schnittstelle eine Abfrage an diese Adresse tragen würde. Sitzt der Resolver auf einer anderen Strecke, liegt das Problem früher als die Firewall, und keine Regel hilft. Wenn beide sich auf den Tunnel einigen, sind zwei Regeln nötig, weil UDP die meisten Abfragen trägt und TCP übernimmt, wenn eine Antwort abgeschnitten wird. Notiere beide Werte, denn sie sind es, die die Regeln nennen werden:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

Öffne den äußeren Weg vor dem inneren

Der Client muss die öffentliche Adresse des Servers erreichen, bevor ein Tunnel existiert, also sitzt die Regel dafür auf der physischen Strecke und muss zuerst vorhanden sein. Eine Richtlinie, die den Resolver zulässt, aber den Server vergisst, lässt den Client den Tunnel gar nicht erst aufbauen, und dieses Symptom wird meist einem Kill Switch angelastet. Lass dann die Dienste zu, die du wirklich durch den Tunnel wolltest, eine enge Regel nach der anderen, statt die Schnittstelle pauschal zu öffnen. Die engen Regeln sind der Grund, warum die Verweigerung bestehen bleiben kann.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

Die Reihenfolge zählt beim Testen, denn die erste Regel ist es, die den Tunnel überhaupt hochkommen lässt. Füge sie hinzu, verbinde, und bestätige, dass der Tunnel steht, bevor du die Dienstregel hinzufügst, denn beides auf einmal zu tun bedeutet, dass ein Fehler dir nichts darüber sagt, welche Hälfte falsch ist. Ersetze die Dokumentationsadresse oben durch den Endpunkt, für den der Client konfiguriert ist.

Schließe die Client-Seite ab, indem du absichtlich trennst. Die Verweigerung sollte den Verkehr, den du bewusst ausgeschlossen hast, weiterhin ablehnen, denn ein Resolver, der bei stehendem Tunnel antwortet, deckt nur die Hälfte einer Richtlinie ab, die im Zweifel verweigert.

Ein Client, der sich verbindet, ist noch nicht zugelassen

Der Server hat seine eigene Richtung zu bedenken, und ein Client, der den Handshake abschließt, erreicht noch nichts, was auf dem Server läuft, bis der Server ihn zulässt. Die Regel für den öffentlichen Listener lässt den Tunnel nur existieren; sie lässt den Verkehr des Tunnels nicht herein. Auf dem Server sind das zwei Regeln plus eine Prüfung, dass der Dienst tatsächlich lauscht:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

Der Pool in der Regel muss dem Bereich entsprechen, den der Server vergibt, und die Tunnelnummer muss zu der passen, die der Server angelegt hat, denn eine Regel für eine andere Schnittstelle ist von keiner Regel nicht zu unterscheiden. limit ist für einen administrativen Port beabsichtigt, denn es drosselt wiederholte Verbindungen, statt sie unbegrenzt zuzulassen. Die Listener-Prüfung trennt einen geschlossenen Port von einem verworfenen Paket, die vom Client aus identisch aussehen. Nummerierte Regeln sind auch nicht das ganze Bild: UFWs Before-Regeln und alle handgeschriebenen nftables-Zeilen greifen früher und können ein Paket noch ablehnen, das die Liste zuzulassen scheint.