Gateway-Benutzer in Access Server: das Filial-LAN eines Clients routen

Sie können die Tunneladresse eines OpenVPN-Clients anpingen und trotzdem keinen Host im dahinterliegenden LAN erreichen. Access Server weist dem Client eine Adresse aus dem VPN-Pool zu, und die Pool-Adresse ist alles, was der Server als sein Eigentum kennt. Das Filialpräfix ist eine separate Tatsache, die deklariert werden muss, und selbst dann braucht die Filiale einen Weiterleiter und die Zentrale einen Rückweg. Eine an der falschen Stelle eingetragene Route sieht wie eine Lösung aus und ändert nichts.

Zwei Adressen, zwei verschiedene Eigentumsansprüche

Bei der Verbindung weist Access Server dem Client eine Adresse aus dem konfigurierten VPN-Pool zu, etwa 10.90.0.0/24. Diese Zuweisung ist ein Lease für einen Host. Nichts in der Verbindung sagt, dass derselbe Client auch vor 10.60.0.0/24 steht, und der Server rät nicht: Ein LAN-Präfix ist über einen bestimmten Client nur erreichbar, wenn ein Administrator es deklariert.

Deshalb hilft eine statische Route auf einer anderen Maschine nicht. Die Route sagt Sende 10.60.0.0/24 an diese Adresse, aber gehört die Adresse einem Client, der nie als Gateway markiert wurde, hat der Server keinen Grund, die Pakete dorthin zu liefern, und der Stack des Clients kann sie verwerfen. Deklaration und Route sind zwei Hälften eines Mechanismus.

Was die Gateway-Einstellung tatsächlich installiert

In der Admin Web UI ist die Deklaration eine Benutzereigenschaft: Aktivieren Sie Configure VPN gateway beim Connector-Benutzer und tragen Sie das echte Filialpräfix in Network on the VPN client side ein. Dieser Benutzer authentifiziert sich wie jeder andere, braucht also eine Credential-Policy für ein unbeaufsichtigtes Gerät, und sein Auto-Login-Profil ist ein Geheimnis, keine Komfortdatei.

Hinter dem Kontrollkästchen behandelt der Server das Präfix als über die Pool-Adresse dieses Clients erreichbar, und die Routing-Konfiguration unter Access Controls entscheidet, was anderen Clients mitgeteilt wird: die an normale Clients gepushten Routen und die Zugriffsregeln, die Verkehr aus den Netzen der Zentrale zu Client-Adressen und Client-Subnetzen erlauben. Aktivieren Sie Routing für die Netze, die die Filiale erreichen sollen, und halten Sie die erlaubte Liste kurz.

Eine Community-Direktive, die in eine generierte Datei kopiert wird, nimmt an diesem Modell nicht teil. Das Produkt besitzt die Routing-Tabelle, die es pusht; eine handbearbeitete Zeile wird bei der nächsten Generierung überschrieben oder ignoriert.

Beide Rückwege der Netze vervollständigen

Ein konkretes Beispiel: Zentrale 10.40.0.0/24, Filiale 10.60.0.0/24, VPN-Pool 10.90.0.0/24, und Access Server über eine private Adresse auf der Seite der Zentrale erreichbar. Der Router der Zentrale braucht Routen für das Filialpräfix und für den Pool, beide zu Access Server. Ohne sie trägt der Tunnel die Anfrage, und die Antwort verlässt über den Standard-Gateway, was die klassische halboffene Verbindung erzeugt.

In der Filiale muss der Connector Pakete weiterleiten, die nicht an ihn adressiert sind: IP-Forwarding im Betriebssystem plus eine Weiterleitungserlaubnis, begrenzt auf Tunnel- und LAN-Schnittstelle; unter Linux ist das net.ipv4.ip_forward=1 zusammen mit den Regeln der Forward-Kette, unter Windows Routing und Remotezugriff. Danach brauchen die Hosts der Filiale einen Rückweg: Entweder ist der Connector ihr Standard-Gateway, oder der vorhandene Gateway trägt gezielte Routen für die Präfixe von Zentrale und Pool.

Die eigene Routing-Tabelle des Connectors konfiguriert nicht jeden Host im Filial-LAN um. Zeigen die Hosts auf einen anderen Router, gehören die Rückwege dorthin, und dieser Router muss akzeptieren, dass die Quelladresse, die er sieht, kein Nachbar im lokalen Subnetz ist.

Einen Fehler als Weg lesen, nicht als Berechtigung

Testen Sie in fester Reihenfolge. Zuerst ein erlaubter Dienst von Access Server zu einem Host der Filiale, dann derselbe Dienst von einem normalen Host der Zentrale, dann die Gegenrichtung, wenn die Policy es zulässt. Geht der erste Test durch und der zweite nicht, sind die gepushten Routen oder die Zugriffsregeln das Problem. Gehen beide durch und kommen keine Antworten, prüfen Sie das Forwarding in der Filiale und den Rückweg in der Zentrale.

Die Host-Firewall ist der nächste Verdacht, denn bei geroutetem Zugriff sieht das Ziel eine Adresse der Zentrale oder des Pools als Quelle. Eine für das lokale Subnetz geschriebene Regel passt nicht, und das Paket wird verworfen, nachdem das Routing einwandfrei funktioniert hat.

Zwei Entwürfe brauchen mehr als dieses Muster. Überlappende Präfixe zwischen Standorten machen das Ziel mehrdeutig und erfordern Umnummerierung oder Übersetzung, und ein geclusterter Access Server braucht von jedem Knoten einen funktionierenden Weg zum Filial-Connector, nicht einen Knoten, der die Route hält. Änderungen über den normalen Speicher- und Aktualisierungspfad anwenden, den Connector neu verbinden und von beiden Enden erneut prüfen; ein vollständiger Neustart jeder Maschine gehört nicht zum Verfahren.

Das Site-to-Site-Tutorial von Access Server listet dieselben Einstellungen in Produktreihenfolge; es lohnt sich, es einmal zu befolgen, bevor Sie den Entwurf an Ihre eigenen Präfixe anpassen.