Ein offener VPN-Port bringt Clients nicht ins LAN

Eine Input-Regel lässt Pakete durch, die an das Gateway selbst adressiert sind. Client-Datenverkehr zu einem anderen Host braucht Weiterleitung, Routing und einen Rückweg, die getrennt geprüft werden.

Der Tunnel kommt hoch, der Client authentifiziert sich, doch das LAN hinter dem Gateway bleibt unsichtbar. Die Regel, die das beheben sollte, erlaubt den VPN-Port und arbeitet genau wie geschrieben, weil sie Pakete an das Gateway selbst regelt. Client-Datenverkehr zu einem Host hinter dem Gateway hat ein anderes Ziel und eine andere Kette. Ein erfolgreicher Login ändert nicht, welche der beiden Ketten der Kernel prüft.

Zwei Ketten, zwei verschiedene Ziele

Über das Schicksal eines Pakets entscheidet, wohin es geht, nicht wie es ankam. Datenverkehr an eine Adresse des Gateways wird lokal zugestellt und gegen Input-Regeln bewertet. Datenverkehr, den das Gateway weiterleitet, wird gegen Forward-Regeln bewertet. Dieselbe Tunnel-Schnittstelle kann beide Paketarten erzeugen, deshalb kann eine Regel nicht beide Aufgaben abdecken.

Der ganze Mythos in einem Satz: den Listener zu erlauben sagt nichts darüber, das Netz dahinter zu erlauben. Es sind zwei getrennte Entscheidungen mit getrennten Belegen, und ein Schnittstellenname auf beiden vereint sie nicht.

Was die Listener-Regel tatsächlich zulässt

Listener-Pakete enden im VPN-Prozess, und genau das ermöglicht überhaupt den Tunnelaufbau. Die Verwaltungsseite des Gateways und eine lokale Diagnoseantwort nutzen ebenfalls den eigenen Input-Pfad des Hosts, deshalb gelingt eine Prüfung zum Gateway, während alles dahinter scheitert. Beide Ergebnisse sind richtig, und keines betrifft das LAN.

Sobald der Prozess Client-Datenverkehr für ein anderes Ziel entkapselt, tritt das Paket in den Forward-Pfad ein und braucht dort eine Erlaubnis. Die erfolgreiche Authentifizierung klärt, wer der Client ist; sie klärt nicht, wohin er darf. Die beiden Fragen haben verschiedene Eigentümer, verschiedene Logs und verschiedene Fehlermeldungen.

Vom Client testen, niemals vom Gateway

Ein auf dem Gateway erzeugter Test folgt dem eigenen Output-Pfad des Hosts und kann gelingen, während der weitergeleitete Pfad geschlossen ist. Starten Sie den Test am Client und beobachten Sie beide Enden des Flusses.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Erscheint die Anfrage auf tun0 und erreicht nichts das Ziel, wird das Paket nach der Ankunft verworfen, was auf Forward-Regeln oder die eigene Filterung des Ziels deutet. Erscheint auf tun0 gar nichts, sendet der Client sie nicht einmal in den Tunnel, und das Problem liegt im Routing am Client statt in der Richtlinie am Gateway. Vergleichen Sie das mit einer Anfrage, die korrekt hinausgeht und nichts zurückbringt, was der Rückwegfall ist.

Weiterleitung braucht drei Dinge, nicht eines

Kernel-Weiterleitung muss aktiv sein, eine Filterregel muss den Fluss akzeptieren, und das Ziel muss mit einem Weg für die Antwort erreichbar sein. Fehlt eines der drei, ist die Stille aus Sicht des Clients dieselbe.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Lesen Sie die drei Ausgaben zusammen. Eine Null in der ersten macht die anderen beiden belanglos, und eine Standard-Drop-Richtlinie in der zweiten verwirft die Pakete des Clients, während der eigene Verkehr des Gateways weiterläuft. Die dritte Ausgabe zeigt, warum die Listener-Regel nie das Problem war.

Halten Sie beide Regelsätze in der Dokumentation getrennt

Schreiben Sie die Listener-Regel und die Regel für den weitergeleiteten Dienst in getrennte Zeilen, mit getrennten Eigentümern und Begründungen. Ändert sich der VPN-Port oder wird ein neuer Dienst veröffentlicht, verhindert diese Trennung, dass eine Änderung die andere stillschweigend erweitert.

Behandeln Sie nicht jeden authentifizierten Peer als vertrauenswürdiges LAN-Mitglied, sondern nutzen Sie enge Regeln für die Client-Bereiche und Dienste, die sie brauchen. Die Hinweise zur Weiterleitung von StrongSwan beschreiben die Rückroute- und Übersetzungsseite derselben Grenze, was wieder eine dritte Entscheidung ist.

Schließlich halten Sie die Schichten gerade, wenn ein Benutzer abgelehnt wird. Erreicht die Anfrage den Host und lehnt die Anwendung das Konto ab, reparieren Sie die Anwendungsberechtigung auf dieser Schicht; eine Ausweitung der Weiterleitung kann keine Dateifreigabe-Anmeldedaten liefern und erweitert den Zugang für alle anderen, die sich erfolgreich verbinden.

Ähnliche Artikel