Warum Access-Server-Clients aus dem LAN nicht erreichbar sind

Der Laptop verbindet sich, der Tunnel steht, und Anfragen an einen internen Dienst bleiben beim Verbindungsaufbau hängen. Am Dienst selbst kommt die Anfrage von einer Adresse wie 10.90.0.25, die Antwort verlässt ihn Richtung Standard-Gateway, und nichts kommt zurück, weil dieses Gateway nicht weiß, wo 10.90.0.25 liegt. Von der anderen Seite sieht derselbe Fehler aus wie ein interner Host, der einen verbundenen Client nicht anpingen kann. Beides ist ein fehlendes Objekt: eine Rückroute zum VPN-Client-Pool, die nur das private Netzwerk hinzufügen kann.

Lesen Sie die Quelladresse, die der Dienst sieht

Dieses eine Feld entscheidet alles Weitere. Sieht der interne Dienst die Pool-Adresse, routet der Access Server, statt Client-Verkehr zu verstecken, und jede Antwort muss zurück in den Pool geroutet werden. Sieht er stattdessen die eigene private Adresse des Servers, maskiert der Server, und der Antwortpfad funktioniert bereits – um den Preis, dass jede Identität pro Client in den Logs und Zugriffsregeln des Dienstes verloren geht.

Vergleichen Sie beide Enden, bevor Sie etwas ändern. Listen Sie auf dem Server die Tunnel-Interfaces und ihre Adressen auf; bestätigen Sie beim Client, welche dieser Adressen er tatsächlich hat; sehen Sie sich auf dem internen Host eine aktive Verbindung an.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

Der letzte Befehl ist der, der im kaputten Fall scheitert: Er meldet entweder das Tunnel-Präfix als nicht erreichbar oder, schlimmer, gibt Ihr Standard-Gateway zurück, und so landen Antworten im Internet.

Nehmen Sie nicht nur einen Pool an. Ein Server kann einen dynamischen Bereich plus statische Zuordnungen pro Benutzer haben, und die statische Adresse kann völlig außerhalb des dynamischen Präfixes liegen. Wenn Sie nur den Bereich routen, an den Sie sich erinnern, bleiben Benutzer mit festen Adressen kaputt, und alle anderen melden das Problem als gelöst.

Legen Sie die Route dort an, wo die Antwort entschieden wird

Die Route gehört auf das Gateway, das der interne Dienst bereits nutzt, nicht auf den Dienst, es sei denn, dieser routet seinen eigenen Verkehr. Richten Sie sie auf die erreichbare private Adresse des Access Servers, die sich von der Tunnel-Adresse eines Clients unterscheidet.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

In einem Cloud-Netzwerk wird dieselbe Aussage zu einem Routentabellen-Eintrag, dessen Ziel die Instanz oder das Netzwerk-Interface ist, auf dem der Server läuft, mit deaktivierter Quell- und Zielprüfung auf diesem Interface. Beachten Sie, was dieser Eintrag nicht tut: Eine Route ist keine Zugriffsgewährung, also müssen Sicherheitsgruppen, Netzwerk-ACLs und die Host-Firewall den Verkehr weiterhin erlauben.

Machen Sie sie persistent und halten Sie die Poolgrößen ehrlich. Zwei nicht zusammenhängende Pools brauchen zwei Routen, und ein Pool, der über sein konfiguriertes Präfix hinauswächst, erzeugt stillschweigend Clients, deren Antworten nirgendwohin gehen. Wenn Sie die Pool-Bereiche kontrollieren, wählen Sie eine Zusammenfassung, die Sie einmal routen und dann in Ruhe lassen.

Weiterleitung und Filter müssen zur Route passen

Routing ist nur die Hälfte des Weges. Der Server muss zwischen Tunnel und privatem Interface weiterleiten dürfen, was unter Linux net.ipv4.ip_forward plus eine Forward-Kette bedeutet, die das Interface-Paar erlaubt, und auf einem gehärteten Host meist eine explizite Regel pro Richtung.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Stateful-Filterung erklärt ein Symptom, das Leute auf die falsche Fährte schickt. Eine Antwort innerhalb eines etablierten Flows braucht keine neue eingehende Regel, also wird eine Verbindung, die nach dem SYN-ACK hängt, nicht durch eine fehlende Accept-Regel blockiert; sie wird verworfen oder falsch geroutet. Halten Sie diese Unterscheidung fest, denn sie trennt eine Routing-Änderung von einer Firewall-Änderung.

Asymmetrische Rückwege sind die leisere Version desselben Problems. Wenn zwei Routen den Pool erreichen und die Antwort diejenige nimmt, die über ein anderes Interface verlässt als das, auf dem die Anfrage ankam, verwirft strikte Reverse-Path-Filterung sie, und der Flow scheitert nur für manche Clients.

Geroutet oder maskiert: bewusst wählen

Der geroutete Modus bewahrt die Pool-Adresse des Clients am Dienst, was Logging und Policy pro Client ermöglicht, und im Gegenzug braucht jedes interne Netzwerk, das einem Client antworten muss, die Pool-Route. Der maskierte Modus beseitigt diese Anforderung, weil Antworten zum Server zurückkehren, aber der Dienst kann einen Client nicht mehr von einem anderen unterscheiden und nichts zu einem bestimmten Client hin initiieren.

Diese Verhaltensänderung auf einem laufenden Server trennt bestehende Sitzungen, testen Sie also zuerst mit einem Client und einem Flow. Wenn der Wechsel die richtige Antwort ist, ist es eine Konfigurationsentscheidung auf dem Server und nichts, das man durch zusätzliche Routen umgeht, die dann überflüssig werden.

Ein Subnetz hinter dem Client ist eine eigene Aufgabe

Ein Gerät im eigenen LAN des Laptops erreichen ist nicht dasselbe wie das Erreichen der Tunnel-Adresse des Laptops. Es verlangt, dass der Client als Subnetz-Gateway fungiert: ein deklariertes clientseitiges Netzwerk, aktivierte Weiterleitung im Betriebssystem des Clients und eine Route in diesem LAN zurück zum Client. Eine Privatnetz-Route für den Heimbereich des Laptops hinzuzufügen leistet das nicht und erzeugt Konflikte, wenn zwei Benutzer denselben Heimbereich haben.

Die Richtung ist ebenfalls eine Policy-Frage. Die Erlaubnis für einen Client, eine Verbindung zu einem internen Dienst zu öffnen, erlaubt einem internen Host nicht automatisch, eine Verbindung zu diesem Client zu öffnen. Prüfen Sie die Zugriffsrichtlinie des Servers und die Host-Firewall des Clients, bevor Sie schließen, dass der Pfad kaputt ist.

Mit einem Flow und einem Mitschnitt verifizieren

Beweisen Sie den Pfad mit einer einzigen Verbindung statt mit einem allgemeinen Erreichbarkeitstest. Beobachten Sie denselben Flow an beiden Enden: die Anfrage, die am Dienst ankommt, und die Antwort, die ihn verlässt.

tcpdump -ni any host 10.90.0.25 and port 443

Vor der Korrektur zeigt der Mitschnitt die Antwort auf dem Weg zu einem Gateway, das sie nicht routen wird. Nach der Korrektur verlässt die Antwort den Host Richtung Server, und der Flow wird fertig. Bestätigen Sie dann die Route, die das Gateway für eine zweite Client-Adresse verwenden würde, damit ein nicht abgedeckter Pool jetzt auffällt und nicht erst in einer Woche.

Schließen Sie mit den vier Prüfungen ab, die das erledigen: Die Quelladresse am Dienst entspricht dem beabsichtigten Modus, das Gateway hat eine Route zu jedem verwendeten Pool, Weiterleitung und Filter erlauben beide Richtungen, und ein echter Flow läuft Ende zu Ende durch. Die FAQ zum Routing des Access Servers nennt dasselbe Prinzip für die installierte Version, deren unterstützte Konfigurationsschnittstelle von älteren Anleitungen abweichen kann.