VPN verbunden, Firewall blockiert trotzdem: So erkennen Sie, welche Seite

Der Tunnel steht und ein Port scheitert weiterhin. Lesen Sie den Pfad, dann die Richtlinie auf jeder Ebene, und ändern Sie die engste Regel, statt eine der beiden Kontrollen abzuschalten.

Der Client meldet verbunden, die Ressource verweigert weiterhin, und der übliche nächste Schritt ist, etwas abzuschalten. Beide Kontrollen in diesem Satz tun Unterschiedliches: Das VPN baut einen Pfad für den abgedeckten Verkehr, und eine Firewall entscheidet pro Verbindung, ob der Verkehr passieren darf. Ein funktionierender Tunnel mit verweigernder Richtlinie sieht vom Stuhl des Nutzers genau wie ein defekter Tunnel aus, also besteht die Aufgabe darin, herauszufinden, welche Ebene antwortet. Hier ist die Reihenfolge, die ich abarbeite, mit der Lesart, die Ihnen sagt, wann Sie aufhören sollen.

Trennen Sie den Pfad von der Richtlinie

Beginnen Sie mit der Form des Fehlers, denn das ist kostenlose Information. Ein verworfenes Paket erzeugt einen Timeout: Der Client versucht es erneut, nichts kommt zurück, und der Befehl hängt, bis er aufgibt. Eine Ablehnung erzeugt eine Verweigerung oder ein Reset: Etwas hat geantwortet und nein gesagt. Ein Dienst, der nicht lauscht, verweigert auf dem Host selbst, ganz ohne Firewall.

Diese drei Ausgänge zeigen auf verschiedene Ebenen. Timeout bedeutet, dass irgendwo eine Richtlinie still verwirft, oder dass die Route die Maschine nie verlässt. Verweigert bedeutet, dass Sie den Host erreicht haben und sein Stack oder seine Host-Firewall abgelehnt hat. Völlige Stille, bei aktiver Tunnel-Schnittstelle und ohne Route zum Ziel, bedeutet, dass der Pfad falsch ist und keine Firewall-Regel das repariert.

Lesen Sie den Pfad in einem Durchgang

Bestätigen Sie, dass der Tunnel das Ziel abdeckt, bevor Sie eine einzige Regel ansehen. Ein Split-Tunnel, der nur das Büro-Subnetz trägt, wird eine Anfrage nicht in einen anderen Bereich routen, und der Fehler sieht dann wie ein Firewall-Block aus, der keiner ist:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Die Routenausgabe nennt die Schnittstelle, über die das Paket die Maschine verlässt, und die Quelladresse, die es trägt. Ist diese Schnittstelle Ihre physische NIC und nicht der Tunnel, liegt das Problem im Routing oder in den erlaubten Bereichen des Tunnels, und es gehört zur VPN-Konfiguration und nicht zur Firewall.

Eine VPN-spezifische Falle verdient eine eigene Prüfung. In WireGuard ist AllowedIPs eines Peers zugleich Route und kryptografischer Filter: Ein Paket, dessen Quelladresse nicht zum erlaubten Satz des Peers passt, wird verworfen, bevor irgendeine Firewall-Regel befragt wird. Eine völlig korrekte Host-Firewall kann also hinter einem stillen Verwerfen stehen, das wie eine Richtlinie aussieht, und die Korrektur ist eine Konfigurationszeile für den Schlüssel, keine Regel.

Lesen Sie die Richtlinie auf der Ebene, die antwortet

Wenn der Pfad stimmt, gehen Sie die Richtlinie vom Host nach außen durch und achten auf die eine Ebene, deren Zähler sich bewegen:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Der lauschende Socket beantwortet eine andere Frage als die Regeln. Lauscht nichts auf dem Port, wird die Verbindung vom Kernel verweigert, und keine eingehende Regel ist relevant. Existiert der Socket und läuft die Verbindung von einem entfernten Client in einen Timeout, findet irgendwo auf dem Pfad ein Verwerfen statt, und die Regelzähler sagen Ihnen, ob es hier geschieht.

Schalten Sie die Protokollierung für das Profil oder die Kette ein, die Sie vermuten, statt von außen zu raten. Ein einzelnes protokolliertes Verwerfen, das Quelle, Ziel und Port nennt, identifiziert Ebene und Regel, und es beweist außerdem, dass das Paket ankam, was keine clientseitige Prüfung feststellen kann.

Lesen Sie die Gateway-Entscheidung, wenn der Tunnel dort endet

An einem Site-to-Site- oder Fernzugriffs-Gateway authentifiziert das VPN einen Nutzer, und die Richtlinie autorisiert eine Ressource, und das sind getrennte Gewährungen. Wer in den Tunnel darf, darf nicht automatisch auf jeden internen Host, und die Verweigerung kommt oft von einer Weiterleitungsregel, während der Tunnel selbst gesund ist. Dieselbe Trennung gibt es in IPsec, wo sich die Sicherheitsrichtlinie, die Verkehr auswählt, vom Filter unterscheidet, der ihn zulässt, und deshalb sind beide in RFC 4301.

Prüfen Sie den Rückweg so sorgfältig wie den Hinweg. Stateful Filtering muss die Antwort sehen, also erzeugt asymmetrisches Routing durch den Tunnel in einer Richtung und um ihn herum in der anderen Verwerfungen, die zufällig wirken und sich nur bei manchen Clients reproduzieren. Erreicht der Verkehr das Gateway und stoppt, lesen Sie Weiterleitungsregel und Rückweg zusammen, bevor Sie irgendetwas erweitern.

Das Gateway ist auch der Ort, an dem eine NAT- oder Masquerade-Regel die echte Quelle verbergen kann. Sehen interne Hosts die Gateway-Adresse statt des Clients, werden ihre Host-Firewall-Regeln, die auf den Client-Pool passen sollen, nie passen, und die Korrektur gehört auf das Gateway und nicht auf jeden Server.

Ändern Sie die engste Ebene, dann prüfen Sie

Widerstehen Sie der breiten Reparatur. Die Host-Firewall abschalten, eine Alles-erlauben-Regel hinzufügen oder jede Schnittstelle in ein vertrauenswürdiges Profil zwingen entfernt jeweils die Kontrolle, die ihre Aufgabe tat, und die Änderung überlebt den Vorfall. Eine Regel, die auf den Quellbereich und den betroffenen Port begrenzt ist, lässt sich leichter prüfen, leichter entfernen und lässt den Rest der Richtlinie der Maschine unangetastet.

Prüfen Sie mit demselben Test, der fehlschlug, vom selben Client, und dann noch einmal nach einer erneuten Verbindung, denn eine Regel, die vor der Neuverhandlung des Tunnels passte, kann danach nicht mehr passen:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Bevor Sie es abschließen:

  • Die Route zum Ziel verlässt die Maschine über die Tunnel-Schnittstelle, und die Quelladresse entspricht dem, was die Richtlinie erwartet.
  • Auf dem Port lauscht etwas, und die Verweigerung oder der Timeout wird einer benannten Regel zugeschrieben statt angenommen.
  • Das Gateway leitet in beide Richtungen weiter, und das Ziel sieht die Quelle, für die Ihre Regeln geschrieben wurden.
  • Keine Kontrolle wurde abgeschaltet, damit der Test besteht, und die Änderung, die Sie gemacht haben, nennt einen Quellbereich und einen Port.

Ähnliche Artikel