Masquerade oder Policy-Routing: LAN-Verkehr über ein VPN-Gateway

Ein ganzes LAN hinter einen VPN-Tunnel zu legen ist der leichte Teil; zu entscheiden, wie die Gegenseite diese Clients sieht, nicht. Masquerade schreibt jede LAN-Quelle auf die Tunneladresse des Gateways um, sodass die Gegenseite einem Peer antwortet. Policy-Routing behält die ursprünglichen Adressen und verlangt, dass die Gegenseite weiß, wie sie sie erreicht. Keines von beiden ist Standard; die Wahl folgt daraus, wem die Gegenseite gehört und ob Identität pro Gerät zählt.

Die beiden Entwürfe versprechen Unterschiedliches

Masquerade reduziert das LAN auf einen einzigen sichtbaren Host: das Gateway. Das entfernte Netz antwortet auf diese eine Adresse, und das Gateway übersetzt die Antworten zurück zu dem Client, der den Fluss gestartet hat. Auf der Gegenseite ist keine Route zu deinen privaten Präfixen nötig, weshalb dieser Entwurf einen Anbieter übersteht, der sich weigert, sie zu tragen. Das Gateway wird außerdem zur Quelle jeder Verbindung, sodass die Gegenseite zwei Clients nicht unterscheiden kann.

Policy-Routing hält jede Clientadresse intakt. Das entfernte Netz sieht die tatsächliche Quelle und kann sie protokollieren, eine Regel pro Host anwenden oder die Antwort direkt an diese Adresse schicken. Diese Sichtbarkeit ist der ganze Punkt, und sie bringt eine Pflicht mit: Die Gegenseite braucht eine Route für das LAN-Präfix, die durch den Tunnel zurückzeigt. Plane diese Route, bevor du die Regel aktivierst, denn der Tunnel kommt so oder so hoch, und fehlen werden nur die Antworten.

Die Fehlerbilder unterscheiden sich so sehr wie die Versprechen. Eine fehlende Masquerade-Regel erzeugt Pakete, die mit privaten Quellen hinausgehen und nie zurückkehren. Eine fehlende Rückroute erzeugt beim Policy-Routing dasselbe Symptom, aber die Korrektur gehört auf den entfernten Router und nicht auf das Gateway.

Masquerade: ein Peer auf der Gegenseite

Der Masquerade-Weg hat eine Reihenfolge, auf die es ankommt. Weiterleitung muss aktiviert sein, bevor eine NAT-Regel nützt, die Filtertabelle muss den Durchgang in beide Richtungen erlauben, und erst dann greift die Übersetzung auf der Tunnel-Schnittstelle.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Clients brauchen weiterhin einen Weg zum Gateway. Entweder ist das Gateway ihr Standardrouter, oder sie tragen eine spezifische Route für das entfernte Präfix; bleibt ein separater Router der Standard, braucht dieser Router eine statische Route für die Tunnelziele, sonst geht das Paket an den falschen Hop, bevor das Gateway es sieht.

DNS ist eine eigene Entscheidung. Ein Resolver auf der Gegenseite antwortet nur, wenn seine Antwort zum Client zurückreisen kann. Unter Masquerade scheint die Anfrage vom Gateway zu kommen, also ist der Rückweg des Resolvers bereits erfüllt; unter Policy-Routing braucht der Resolver denselben Rückweg wie jeder andere entfernte Dienst.

Policy-Routing: Quelle behalten, Rückweg hinzufügen

Policy-Routing beginnt mit einer Tabelle und einer Regel, die sie auswählt. Verkehr, der von der LAN-Schnittstelle hereinkommt, wird in eine eigene Tabelle geschickt, und diese Tabelle trägt eine Standardroute durch den Tunnel. Die Haupttabelle bleibt unberührt, sodass Verkehr, der vom Gateway selbst stammt, einen anderen Weg nehmen kann.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

Die Gegenseite muss dann das LAN-Präfix durch den Tunnel zurückrouten. Das ist eine Konfiguration auf dem entfernten Router, nicht auf diesem Gateway. Das Gateway muss außerdem Antworten annehmen, die auf einer anderen Schnittstelle ankommen, als die Haupttabelle vorhersagen würde; lose Rückwegfilterung (rp_filter auf 2 gesetzt) ist die übliche Anpassung, wenn der strikte Modus diese Pakete verwirft.

Wenn zwei Tunnel aktiv sind, markiere jeden Fluss beim Eintritt und lass die Markierung die Tabelle wählen. Eine Regel, die nur auf die Eingangsschnittstelle schaut, schickt den Verkehr beider Tunnel in dieselbe Tabelle, sodass der zweite Tunnel dem ersten Flüsse stiehlt. Teste diese Markierung mit einer Verbindung, die ein Wiederverbinden überlebt, denn dann zeigt sich eine gemischte Politik.

Entscheide nach Eigentum und danach, was die Gegenseite protokolliert

Endet der Tunnel bei einem Anbieter, nimm Masquerade. Dieser Betreiber wird deine privaten LAN-Bereiche nicht routen, und er hat keinen Grund, einzelne Clients hinter deinem Gateway zu unterscheiden. Ein sichtbarer Peer ist das einzige Modell, das seine Politik stützt, also gib ihm das und halte die Übersetzung an deiner Kante. Der Anbieter sieht einen Peer, genau was seine Politik erwartet, und deine Clients erben diese eine Identität.

Sind beide Enden deine und handeln die entfernten Dienste nach Quelladressen, verdient Policy-Routing seine zusätzliche Route. Firewall-Regeln, Zugriff pro Benutzer und Audit-Logs können dann Clients unterscheiden. Braucht die Gegenseite nur Erreichbarkeit, ist Masquerade einfacher und beseitigt eine Klasse von Rückroute-Fehlern.

Hybride Entwürfe sind normal: Policy-Routing im eigenen Netz, Masquerade am Anbieterrand. Wichtig ist, aufzuschreiben, welcher Hop übersetzt und welcher Hop routet, denn eine versehentlich für einen Client hinzugefügte NAT-Regel verbirgt die Quelle für jeden Client in derselben Kette.

Prüfe von einem Client, dann von einem zweiten Client

Führe den Test dort aus, wo der Verkehr beginnt. Prüfe die Route, die der Host verwendet, beobachte, wie das Paket auf der Tunnel-Schnittstelle erscheint, und sieh conntrack für die Übersetzung an. Diese Reihenfolge beweist, dass das Paket den beabsichtigten Weg genommen hat, statt nur irgendwo anzukommen.

Wiederhole den Test nach einem Wiederverbinden. Eine Masquerade-Regel, die die Schnittstelle nennt, überlebt eine neue Tunneladresse; eine Regel, die die alte Adresse nennt, nicht. Dann teste einen zweiten LAN-Host, denn ein Entwurf, der auf einer Maschine funktioniert, hängt oft von deren eigener Route ab und nicht von der Gateway-Politik.

Schreibe das gewählte Modell, die übersetzte oder erhaltene Quelle und den Eigentümer der Rückroute in die Gateway-Notizen. Sonst rät die nächste Person, die einen Client oder einen Tunnel hinzufügt, und ein Raten ist der Weg, auf dem aus einem funktionierenden LAN-zu-VPN-Aufbau ein teilweiser wird.