Standortvernetzung oder Fernzugriff per VPN: Was die beiden verbinden

Beide Designs heißen VPN und lösen unterschiedliche Probleme. Ein Site-to-Site-Tunnel verbindet zwei Gateways, sodass jeder Host dahinter erlaubte Adressen auf der anderen Seite erreichen kann, ohne etwas zu installieren. Ein Remote-Access-Tunnel verbindet einzelne Geräte mit einem Netzwerk, jeweils einen Client. Der Vergleich ist wichtig, weil die meisten Bereitstellungsfehler daraus entstehen, dass man das eine Design konfiguriert und das Verhalten des anderen erwartet, und das Symptom ist meist ein Timeout bei einem Dienst, den der Tunnel tatsächlich erreicht hat.

Zwei Designs, zwei Grenzen

Keines der beiden Designs erweitert eine LAN-Broadcast-Domäne. Geräte auf der anderen Seite erscheinen nicht in einer lokalen Erkennungsliste, und das zu erwarten ist die erste Annahme, die man fallen lassen sollte. Private DNS-Namen, die Sie bewusst veröffentlichen, sind vorhersehbarer als jedes Erkennungsprotokoll und überstehen einen Anbieterwechsel.

Nehmen Sie 10.10.0.0/24 am einen Standort und 10.20.0.0/24 am anderen. Gateway A braucht eine Route oder einen Traffic-Selektor, der das Präfix 10.20.0.0/24 in den Tunnel schickt, und Gateway B braucht das Spiegelbild. Hosts auf beiden Seiten nutzen dann gewöhnliche IP-Konnektivität und erfahren nie, dass ein Tunnel existiert. Diese Unsichtbarkeit ist die Funktion, und sie ist auch der Grund, warum Fehler wie gewöhnliche Netzwerkfehler aussehen und nicht wie Tunnelfehler.

Richtlinienbasiert und routenbasiert sind nicht derselbe Tunnel

In einer richtlinienbasierten IPsec-Bereitstellung legen die ausgehandelten Traffic-Selektoren genau fest, welche Quell-/Zielpaare geschützt sind. Taucht hinter einem Gateway ein neues Subnetz auf und kein Selektor deckt es ab, bleibt der Tunnel bestehen, und das neue Subnetz wird einfach nicht übertragen. In einem routenbasierten Design empfängt eine Schnittstelle den Verkehr, und die Routing-Tabelle entscheidet, was das Hinzufügen eines Präfixes zu einer Routing-Änderung statt zu einer erneuten Tunnel-Aushandlung macht.

StrongSwan zeigt beide Sichten direkt, und beide zusammen zu lesen ist der Weg herauszufinden, welches Modell Sie tatsächlich bereitgestellt haben.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Eine Selektorliste, die das Präfix auslässt, das Ihnen wichtig ist, erklärt den Fehler ohne jeden Paketmitschnitt, und eine Route auf die falsche Schnittstelle erklärt den Spiegelbild-Fehler auf dem Rückweg. Lesen Sie beides, bevor Sie irgendetwas neu aushandeln, denn eine Schlüsselerneuerung fügt keinen Selektor hinzu, den Sie nie konfiguriert haben.

Planen Sie die Adressierung vor dem Tunnel

Überlappende Bereiche sind der Designfehler, der sich nicht durch Konfiguration beheben lässt. Wenn beide Standorte 192.168.1.0/24 verwenden, hat ein Host, der 192.168.1.50 braucht, zwei Kandidaten und keine Möglichkeit zu wählen. Der Tunnel authentifiziert sich, die Sicherheitsassoziationen werden aufgebaut, und die Routing-Entscheidung ist trotzdem falsch oder mehrdeutig.

Wählen Sie eine von drei ehrlichen Möglichkeiten: einen Standort umnummerieren, den überlappenden Bereich am Gateway übersetzen, sodass jede Seite ein eigenes Präfix sieht, oder für diese Hosts auf direktes Routing verzichten und den Dienst anders veröffentlichen. Jede hat einen Preis, und die erste ist über einen Zweijahreshorizont meist die günstigste. Entscheiden Sie, bevor der Tunnel existiert, denn danach berührt die Änderung jedes Gerät mit der alten Adresse.

Klären Sie auch die MTU-Frage früh. Ein Tunnel reduziert die nutzbare Nutzlast, und ein Design, das auf Fragmentierung setzt, verhält sich anders als eines, das die MSS an den Gateways begrenzt.

Weiterleitung und Policy liegen außerhalb des Tunnels

Das Gateway muss bereit sein, Pakete zwischen der Tunnel-Schnittstelle und der LAN-Schnittstelle weiterzuleiten, und beide Richtungen brauchen eine Policy, die den Dienst erlaubt. Unter Linux sind das zwei getrennte Einstellungen, dazu die Firewall-Regeln, die entscheiden, ob der weitergeleitete Fluss überhaupt erlaubt ist.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

Der empfangende Host fügt eine dritte Ebene hinzu: Seine eigene Firewall muss immer noch einen Client aus dem entfernten Subnetz akzeptieren. Ein Dateiserver, der nur sein lokales /24 zulässt, weist weitergeleiteten Verkehr von 10.20.0.7 ab, so gesund der Tunnel auch aussieht, und diese Ablehnung lässt sich leicht als Routing-Fehler lesen.

Testen Sie von einem Host, nicht vom Gateway

Ein Ping, der vom Gateway selbst ausgeht, kann einer anderen Quelladresse und einer anderen Policy folgen als weitergeleiteter Benutzerverkehr. Das macht ihn zu einem schwachen Test und gelegentlich zu einem irreführenden: Er gelingt, während die Anwendung scheitert, oder scheitert, während die Anwendung funktioniert.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Verwenden Sie einen echten Host, eine echte Quelladresse und das echte Protokoll, das die Anwendung nutzt. Lesen Sie dann den Rückweg getrennt, denn eine funktionierende Vorwärtsrichtung ohne Rückroute erzeugt ein Timeout, das identisch zu einem blockierten Dienst aussieht.

Wählen Sie das Design nach der Frage, die Sie beantworten: Verbinden Sie Netzwerke oder nehmen Sie Geräte auf? Alles andere, auch welchen Anbieter Sie konfigurieren, folgt aus dieser Antwort.