pfSense als VPN-Server und -Client: zwei Wege, ein Router

Ein Gerät kann gleichzeitig in zwei Richtungen blicken: Roaming-Nutzer wählen sich ein, und dieselbe Box wählt sich zu einem Ausgangsanbieter aus, damit ausgewählter Verkehr über ein anderes Netz verlässt. Beide Dienste zu aktivieren dauert Minuten; sie koexistieren zu lassen erfordert ein Design, denn die zweite Rolle schreibt die Routing-Tabelle um, auf der die erste beruht. Drei Bedingungen entscheiden, ob die Anordnung funktioniert, nämlich ob der eingehende Dienst seinen eigenen Rückweg behält, ob der ausgehende Tunnel seinen Peer noch erreicht und ob der Verkehr, den Sie weiterleiten wollten, für den Ausgang ausgewählt wird. Eines falsch gemacht, und Sie erhalten zwei Tunnel, die beide Verbindung melden, während nichts Nützliches zwischen ihnen übertritt. Die Prüfungen unten stellen jede Bedingung in der Reihenfolge fest, in der die Fehler gewöhnlich auftreten.

Benennen Sie die beiden Rollen, bevor Sie eine Einstellung anfassen

Notieren Sie vier Fakten pro Instanz: ihren entfernten Peer, ihr Authentifizierungsmaterial, den Adresspool, den sie ausgibt, und die Netze dahinter. Die beiden Instanzen sind getrennte Objekte auf dem Gerät und sollten es auch in Ihren Notizen bleiben. Fast jedes verwirrende Symptom später entsteht aus der Vermischung ihrer Werte, und zwei Instanzen, die sich einen Satz Notizen teilen, sind der Weg, auf dem der falsche Pool im falschen Feld landet.

Der eingehende Dienst braucht ein Tunnelnetz, das sich weder mit den Adressen des ausgehenden Tunnels noch mit einem privaten Netz überschneidet, das das Gerät routet. Überschneidung ist der eine Fehler, der Symptome in beiden Rollen gleichzeitig erzeugt, und auf dem Papier ist er weit billiger zu fangen. Vergleichen Sie beide Pools und jedes geroutete private Netz an einer Stelle, bevor Sie einen der Dienste konfigurieren.

Gemeinsame Hardware bedeutet nicht gemeinsame Anmeldedaten, und ein Client-Zertifikat aus dem Fernzugriffspool sollte nicht gegen den Ausgangsanbieter verwendbar sein. Getrenntes Material macht auch den Widerruf zu einer lokalen Entscheidung statt zu einem Ereignis für die gesamte Flotte.

Halten Sie die Antworten des Servers auf dem WAN-Pfad

Antworten, die das Gerät selbst erzeugt, sind das erste Opfer einer nachlässigen Standardroute. Wenn das gekapselte Paket eines Roaming-Nutzers ankommt, ist die Antwort lokal entstandener Verkehr, und sie muss über die Schnittstelle verlassen, über die dieser Nutzer hereinkam. Hat der Ausgangsclient eine Standardroute installiert, die sie abfängt, gerät die Antwort in den falschen Tunnel, und die Sitzung stockt, während der Dienst noch gesund aussieht.

Es gibt kein einzelnes Kontrollkästchen, das das klärt, denn die Entscheidung betrifft, welchen Verkehr der Ausgangsclient abfangen darf. Entweder ziehen Sie keine Routen und lenken nur, was Sie auswählen, oder Sie ziehen Routen und ergänzen die Ausnahmen, die die eigenen Dienste des Geräts am Laufen halten. Schreiben Sie die Wahl neben die Instanz, sonst wird die nächste Person die andere annehmen.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Lesen Sie die Routing-Tabelle nach der längsten Übereinstimmung, nicht nach der Reihenfolge, in der Sie etwas konfiguriert haben. Die Frage ist, welcher Eintrag für die Adresse des Ausgangs-Peers gewinnt und welcher Eintrag für die Antwort des eingehenden Dienstes gewinnt, und diese beiden Antworten können sich unterscheiden.

Lassen Sie den Ausgangstunnel nicht seinen eigenen Endpunkt fressen

Der Ausgangsclient muss die öffentliche Adresse seines Peers erreichen, um den Tunnel überhaupt aufzubauen. Ist diese Adresse selbst in den Tunnel geroutet, jagt der Client seinem eigenen Schwanz nach: Der Transport kommt nie hoch, oder er kommt hoch und fällt in dem Moment, in dem die Route installiert wird. Das Protokoll sieht wie ein Authentifizierungs-Timeout aus und nicht wie ein Routing-Fehler, weshalb die Route zuerst geprüft gehört.

Prüfen Sie die Route vor den Anmeldedaten und erneut, nachdem der Tunnel steht, denn ein Eintrag kann beim Start korrekt und eine Minute später falsch sein. Die Adresse des Peers muss auf den gewöhnlichen WAN-Pfad zeigen, niemals auf das Tunnelgerät. Sobald der Transport stabil ist, wandert die interessante Frage zum weitergeleiteten Verkehr, und das ist die nächste Entscheidung.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Wählen Sie, welche Nutzer den Ausgang bekommen

Quellrichtlinie gehört an den Eingang, an dem Verkehr in das Gerät eintritt, also wählen Sie den Fernzugriffspool oder engere Identitäten darin. Bewahren Sie die privaten Ziele und Verwaltungsausnahmen, die niemals an den Ausgang gehen dürfen, und setzen Sie diese Regeln vor die breite. Der Ausgangspfad braucht dann seine eigene Übersetzung oder eine geroutete Rückregelung, was für die meisten Designs ausgehendes NAT auf der Ausgangsschnittstelle bedeutet, das den Pool abdeckt. Übersetzung wählt keinen Ausgang; sie schreibt nur um, was bereits verlassen hat, daher ändert eine NAT-Regel auf einem unbeteiligten WAN nichts an der Auswahl.

Bestätigen Sie, dass die Gegenseite weitergeleiteten Verkehr aus diesem Design zulässt, denn manche Anbieter tun es und manche nicht. Der Unterschied zeigt sich als Tunnel, der sich verbindet und nichts trägt, was leicht als lokaler Fehler gelesen wird. Testen Sie die drei Ströme getrennt, denn sie scheitern unabhängig, und zwei von drei ist ein halbfertiges Design.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Der erste Befehl ist die äußere Verbindung des Roaming-Nutzers, und er funktioniert, wenn der Client die Initialisierungssequenz als abgeschlossen meldet. Der zweite, von diesem verbundenen Laptop ausgeführt, sollte die Adresse des Ausgangsanbieters melden statt Ihre WAN-Adresse. Der dritte läuft auf dem Gerät gebunden an eine Pool-Adresse, und er prüft die Quellrichtlinie für weitergeleiteten Verkehr, ohne überhaupt einen entfernten Nutzer einzubeziehen. Antwortet er stattdessen aus dem WAN, hat die Richtlinie nicht gegriffen, und keine NAT-Bearbeitung behebt ein Auswahlproblem.

Entscheiden Sie, was passiert, wenn der Ausgang ausfällt

Schreiben Sie das Fehlerverhalten auf, bevor es eintritt: Wenn der Ausgangstunnel ausfällt, fallen Nutzer dann auf das gewöhnliche WAN zurück, oder sind sie blockiert, bis der Ausgang zurückkehrt? Beide Antworten sind vertretbar, und das Gerät wird nicht für Sie wählen. Eine entfernte Route oder eine Richtlinie, die auf ein totes Gateway zeigt, erzeugt nicht automatisch ein vollständig blockiertes Ergebnis. Wollen Sie Blockierung, muss die Richtlinie das ausdrücklich sagen, und sie muss getestet werden, indem man den Ausgang wegnimmt, statt darüber nachzudenken. Wollen Sie Rückfall, veröffentlichen Sie das für Nutzer, denn Verkehr, der still den gewöhnlichen Weg nimmt, ist genau der Verkehr, von dem jemand glaubte, er sei abgedeckt.

Deaktivieren Sie die Client-Instanz, beobachten Sie, was ein verbundener Nutzer noch erreicht, und starten Sie sie dann wieder. Eine Anfrage, die in einen Timeout läuft, ist das vollständig blockierte Ergebnis, um das Sie gebeten haben; eine, die mit der WAN-Adresse antwortet, ist der Rückfall, den Sie nicht dokumentiert haben. Wiederholen Sie die Prüfung für IPv6 und für DNS, denn eine für IPv4 geschriebene Richtlinie sagt nichts über AAAA-Verkehr, und ein Resolver, den einer der Tunnel durchschiebt, antwortet von dort, wo die Abfrage tatsächlich hinausgeht.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Netgates Rezept für geroutetes OpenVPN zeigt, wie Quellrichtlinie, Schnittstellenzuweisung und ausgehende Übersetzung zusammenpassen, und sein Standort-zu-Standort-Umfang ist der Teil, den man nicht als Ganzes kopieren sollte. Was es Ihnen nicht sagen wird, ist, welche der drei Bedingungen oben Ihr eigenes Design bereits gebrochen hat.