LAN per NAT durch tun0 auf einem OpenBSD-VPN-Gateway

Zwei Ingenieure mit demselben OpenBSD-Gateway werden Ihnen oft zwei verschiedene Regelsätze für den Zugang zu einem entfernten Netz geben, und beide lassen sich verteidigen. Die Wahl zwischen Quellübersetzung und Rückroute ist überhaupt keine Syntaxfrage. Sie hängt davon ab, was die Gegenseite bereits über 192.168.88.0/24 weiß und was Sie in Ihren Protokollen behalten müssen. Machen Sie das falsch, sieht die nat-to-Zeile vollkommen korrekt aus, während Antworten im entfernten Standardgateway verschwinden.

Routing und Umschreiben beantworten verschiedene Fragen

Die Routing-Tabelle entscheidet, dass 172.20.0.0/16 über tun0 erreichbar ist, und diese Entscheidung fällt, bevor irgendeine pf-Übersetzung befragt wird. Die Quellübersetzung ändert dann den Paketkopf, sodass das entfernte Ende die Tunneladresse des Gateways statt eines LAN-Hosts sieht. Keiner der Mechanismen ersetzt den anderen: Eine nat-Regel kann keine Route herbeizaubern, und eine Route kann einen entfernten Router nicht überzeugen, der noch nie von Ihrem privaten Subnetz gehört hat. Fehlt der Gegenseite ein Rückweg, werden Antworten verworfen oder an ihr Standardgateway weitergeleitet, und keine Regelabstimmung behebt das.

Einfach gesagt: Weiterleitung beantwortet, wohin Verkehr geht, und Übersetzung beantwortet, von wem er zu kommen scheint. Halten Sie beides in getrennten gedanklichen Schubladen, während Sie den Regelsatz entwerfen.

Drei Bedingungen, die es entscheiden

Stellen Sie drei Fragen der Reihe nach, und das Design wählt sich meist selbst. Hat das entfernte Netz eine statische Route, die auf die Tunneladresse für 192.168.88.0/24 zeigt, oder kontrolliert dessen Administrator die Router auf diesem Weg? Wenn ja, lassen Sie die LAN-Adressen unverändert passieren und überspringen Sie die Übersetzung ganz. Brauchen Sie auf der Gegenseite Sichtbarkeit pro Client, sei es für die Zugriffsrichtlinie oder für einen Prüfpfad? Wenn ja, ist die Bewahrung der Quelle die Routing-Arbeit wert. Ist die Tunneladresse stabil genug, um sie in eine entfernte Route zu schreiben, oder ändert sie sich zwischen Wiederverbindungen?

Ist eine Antwort nein oder unbekannt, ist nat-to die pragmatische Option, und sie ist auch die umkehrbare. Eine Übersetzungsregel fällt in einer einzigen Zeile weg, sobald die Gegenseite eine ordentliche Route hinzufügt. Eine Rückroute, die nie installiert wurde, kostet Sie einen Support-Thread jedes Mal, wenn jemand fragt, warum der Tunnel nur in eine Richtung funktioniert.

Das Fragment so platzieren, dass pf es wirklich auswertet

Das folgende Fragment setzt voraus, dass das LAN 192.168.88.0/24 ist, das entfernte Netz 172.20.0.0/16 und die Tunnelschnittstelle tun0. Nichts darin wählt einen nächsten Hop. Es schreibt nur die Quelle auf Paketen um, die den Tunnel bereits verlassen.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Zwei Details in dieser ersten Zeile tragen den größten Teil des Gewichts. Die Klammern um tun0 weisen pf an, die Schnittstellenadresse bei jedem Aufbau eines Zustandseintrags zu lesen, was zählt, wenn der Tunnel nach einer Wiederverbindung neu nummeriert wird. Das Wort match bedeutet, dass die Regel umschreibt und dann durchfällt, sodass eine separate pass-Regel den Fluss weiterhin zulassen muss. Die in der match-Zeile genannte Schnittstelle muss auch die sein, die die Routing-Tabelle auswählt, sonst wertet pf die Regel auf einem anderen ausgehenden Pfad aus, als das Paket tatsächlich nimmt.

Vergessen Sie die Kernelseite nicht. IPv4-Weiterleitung muss aktiviert sein, und die zustandsbehafteten pass-Regeln für Tunnel und LAN müssen existieren, bevor irgendetwas davon Sinn ergibt. Der PF-NAT-Abschnitt der OpenBSD-FAQ ist die richtige Referenz für die Schlüsselwortreihenfolge hier.

Den Regelsatz prüfen, bevor Sie dem Verkehr trauen

Prüfen Sie die Syntax zuerst mit pfctl -nf /etc/pf.conf, das die Datei parst, ohne sie zu laden. Laden Sie dann die Richtlinie und lesen Sie zurück, was der Kernel tatsächlich hält, denn eine sauber geparste Regel kann trotzdem verdeckt oder an die falsche Schnittstelle gehängt sein. pfctl -sn gibt Übersetzungsregeln in ihrer geladenen Form aus, und pfctl -sr gibt Filterregeln in Auswertungsreihenfolge aus.

Beobachten Sie als Nächstes die Leitung. Auf dem Gateway zeigt tcpdump -ni tun0 'host 172.20.0.10', ob die Quelladresse, die den Tunnel verlässt, die Tunneladresse oder der LAN-Host ist. Ein schnelles netstat -rn -f inet bestätigt, auf welche Schnittstelle das Ziel aufgelöst wird. Sobald Verkehr fließt, listet pfctl -ss Zustandseinträge auf; hat ein Fluss keinen Zustand erzeugt, hat das Paket nie eine Regel getroffen, die einen anlegt.

Wenn die Tunnelseite richtig aussieht und Antworten trotzdem nie ankommen, hören Sie auf, pf zu bearbeiten. Der verbleibende Fehler sitzt auf dem entfernten Router, wo die Antwort an eine private Adresse geschickt wird, die jene Seite nicht erreichen kann.

Wenn Übersetzung mehr kostet, als sie spart

Übersetzung verbirgt Clients, und manchmal ist das genau der falsche Handel. Überlappende Subnetze sind ein Fall: Nutzt die Gegenseite intern ebenfalls 192.168.88.0/24, verschlimmert es die Kollision, LAN-Hosts als Gateway darzustellen, statt sie zu verbessern. IPsec-Richtlinien, die Verkehr nach Adresspaar auswählen, sind ein anderer, weil die Sicherheitsrichtlinien-Datenbank vor der Übersetzung abgeglichen wird und Ihr umgeschriebenes Paket nie sieht. Jede Bereitstellung, die pro Benutzer abrechnet, drosselt oder prüft, verliert außerdem die Identität, die sie braucht, sobald die Quelle auf eine Adresse zusammenfällt.

Portable pf-Derivate sind eine eigene Falle. Produkte, die ihre eigenen Regelsätze erzeugen, erwarten, dass NAT über ihre Oberfläche konfiguriert wird, und handbearbeitete Fragmente werden beim nächsten Neuladen überschrieben. Regelsätze, die aus Anleitungen kopiert wurden, die vor dem Schlüsselwort match entstanden, laden auf einem aktuellen Kernel nicht, also portieren Sie die Syntax und lesen Sie den Fehler, statt zu raten.

Die Entscheidungsregel, die den Kontakt mit echten Netzen übersteht, ist kurz: Installieren Sie eine Rückroute, wenn Sie können, übersetzen Sie, wenn Sie nicht können, und notieren Sie, welche der drei Bedingungen Ihre Wahl bestimmt hat. Diese Notiz spart der nächsten Person einen Nachmittag.