pfSense OpenVPN: ein Netz hinter einem anderen Router erreichen
Der Client braucht ein gepushtes Präfix, pfSense einen erreichbaren nächsten Hop und der entfernte Router einen Weg zurück zum Pool. Drei Eigentümer, drei Routen.
Ihr Laptop erreicht das pfSense-LAN über das VPN und scheitert dennoch an einem Dienst zwei Hops weiter innen, und der Unterschied ist eine Routingentscheidung pro Eigentümer. Drei Geräte müssen übereinstimmen, bevor ein Paket seinen Hin- und Rückweg abschließt: der Client, die Firewall und der Router, dem das Zielnetz tatsächlich gehört. Fehlt einer davon, sieht das Symptom identisch aus.
Verfolgen Sie ein Paket durch diese drei Entscheidungen, bevor Sie eine Regel ändern, denn jeder Eigentümer hat eine andere Kontrolle und einen anderen Fehlermodus.
Ein Paket, drei Routingentscheidungen
Der Client entscheidet, ob das Ziel zum Tunnel gehört, und er kann nur anhand dessen entscheiden, was er weiß: eine gepushte Route, eine lokale Route oder eine Standardroute, die bereits alles abdeckt. pfSense entscheidet, wohin das Paket als Nächstes geht, was für ein Netz hinter einem anderen Router eine statische Route über ein erreichbares Gateway auf der richtigen Schnittstelle bedeutet. Der untere Router entscheidet, ob er einen Weg zurück zum VPN-Pool kennt, und wenn nicht, wird die Antwort verworfen oder an eine nutzlose Stelle geschickt. Jede Entscheidung ist von den beiden anderen unabhängig.
Der Ausfall irgendeiner davon erzeugt denselben Benutzerbericht. Deshalb ist die Reihenfolge beim Debuggen wichtiger als die Werkzeuge.
Geben Sie dem Client ein Präfix, keine Vermutung
Auf einem pfSense SSL/TLS-Server mit einem IPv4-Tunnelnetz größer als ein /30 verteilt das Feld IPv4 Local network(s) Routen an Clients, wenn sie sich verbinden. Fügen Sie dort das untere Präfix hinzu, anstatt sich darauf zu verlassen, dass der Client eines erfindet. Lesen Sie dann nach dem Verbinden die tatsächliche Tabelle des Clients, denn ein Profil mit route-nopull oder ein Routenfilter kann ignorieren, was der Server gesendet hat. Der Server kann völlig korrekt sein, während der Client nichts installiert.
Andere Servermodi und Topologien haben andere Grenzen, und eine Richtlinie pro Client oder Verbindung kann ändern, was ein bestimmter Client erhält. Prüfen Sie an dem Client, der zählt, und nicht an dem, den Sie zufällig zuerst getestet haben.
Richten Sie pfSense auf den internen Router
Eine statische Route in pfSense braucht ein definiertes und erreichbares Gateway, und die für dieses Gateway gewählte Schnittstelle muss die sein, die es tatsächlich erreicht, wie der Netgate-Leitfaden für statische Routen beschreibt. In einem illustrativen Aufbau ist die Transitstrecke 192.168.77.1 auf der Firewall und 192.168.77.2 auf dem internen Router, mit dem Dienstnetz 172.16.30.0/25 dahinter. Die Route benennt dann das Präfix und den nächsten Hop, nicht die Dienstadresse. Eine Adresse aus dem entfernten Netz als Gateway zu verwenden, ist ein häufiger Weg, eine Route zu bauen, die korrekt aussieht und nirgendwohin weiterleitet.
Einer Schnittstelle einen Namen zu geben, beschreibt nicht die Netze dahinter. Die statische Route ist diese Beschreibung.
Die Gegenseite muss den Pool kennen
Der untere Router braucht eine Rückroute für den Pool, in diesem Beispiel 10.55.0.0/24 über 192.168.77.1, es sei denn, eine Standardroute oder ein dynamisches Protokoll liefert bereits eine. Das Gateway des Diensthosts selbst muss zu diesem Router führen, was normalerweise stimmt, wenn der Router sein Standardgateway ist, und nicht stimmt, wenn der Host manuell konfiguriert wurde. Policy-Routing auf der Firewall kann die Tabelle für bestimmten Verkehr ebenfalls überschreiben, prüfen Sie also, ob eine Regel ein anderes Gateway wählt, bevor Sie schließen, dass die Route falsch ist.
Für dieses Design ist keine Übersetzung erforderlich, und die Quelladresse des Clients sichtbar zu halten, erlaubt dem unteren Netz, seine eigene Richtlinie anzuwenden.
Zur Abnahme verfolgen Sie eine neue Anfrage durch den Tunneleingang, den internen Ausgang der Firewall und die Antwort vom Ziel. Wenn stattdessen bewusst Übersetzung verwendet wird, halten Sie fest, welche Quelle das untere Netz sieht und wie die Antwort zurückkommen soll.
Speichern Sie den Plan der drei Eigentümer zusammen mit der genehmigten Anwendung, damit der nächste Administrator den Pfad rekonstruieren kann, statt ihn neu zu entdecken.