Ein OpenVPN-Hub, drei LANs: Adressplan und iroute-Dateien

Vier disjunkte Präfixe, eine Kernelroute pro Zweig, ein iroute pro Besitzer. Eine Arbeitsreihenfolge für einen Hub mit drei Standorten, der still scheitert, wenn ein Name falsch ist.

Drei private LANs können sich an einem Hub treffen, ohne dass eine Site die Interna der anderen erfährt, und das ganze Design ruht auf vier kurzen Konfigurationsentscheidungen. Es funktioniert nicht wegen eines exotischen Protokollmerkmals, sondern wegen eines Adressplans, den niemand raten muss, plus Routen pro Client, die dem Hub sagen, welcher Zweig welches Präfix besitzt. Macht man eines davon falsch, kommt der Tunnel trotzdem hoch, und genau das macht den Fehler verwirrend.

Arbeiten Sie die Schritte der Reihe nach ab. Jeder hängt vom Plan des vorigen Schritts ab, und keiner verlangt eine neue Zertifizierungsstelle.

Beginnen Sie mit einem Plan, den niemand raten muss

Notieren Sie vier disjunkte Präfixe, bevor Sie eine Konfigurationsdatei anfassen: das eigene LAN des Hubs, das LAN jedes Zweigs und den Pool, der an roaming Clients ausgegeben wird. Disjunktheit hält alles andere einfach, denn überlappende Bereiche machen aus dem Routing ein Rätsel des längsten Treffers, das keine Konfiguration pro Client repariert. Bestätigen Sie dann, welcher Rechner das Standardgateway jedes LANs ist, denn ein Zweigrouter, der nicht das Gateway seines LANs ist, braucht die entfernten Routen ganz woanders installiert. Legen Sie schließlich die authentifizierten Namen fest, die jeden Zweig identifizieren, denn nach diesen Namen werden die Dateien pro Client nachgeschlagen.

Ein beispielhafter Plan hält den Pool weit von den drei LANs entfernt. Ihrer wird anders aussehen, und die einzige harte Regel ist, dass sich keine zwei Bereiche überlappen.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Sagen Sie dem Kernel des Hubs, wo die Zweige liegen

Der Hub braucht pro Zweig zwei Informationen: eine Kernelroute, die das Präfix in das Tunnelgerät schickt, und einen iroute Eintrag, der dem OpenVPN Prozess sagt, welcher Client ihn besitzt. Die Kernelroute allein liefert Pakete an den Tunnel und hört dort auf, denn der Dämon muss noch entscheiden, welcher Peer sie erhalten soll. Der iroute Eintrag allein lässt diese Pakete im Kernel ohne eine Route, der sie folgen könnten. Beide Zeilen gehören in die Konfiguration, die der Dämon tatsächlich lädt, was sich zu prüfen lohnt, bevor man irgendetwas anderes debuggt.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Schalten Sie Client-zu-Client ab, wenn der Kernel der Durchsetzungspunkt sein soll. Diese Option leitet Peer-Verkehr innerhalb des Dämons weiter, was bequem ist und auch bedeutet, dass Ihre Weiterleitungsregeln den Fluss nie sehen. Alles Folgende setzt voraus, dass der Kernel jedes Paket zwischen Zweigen sieht.

Geben Sie jedem Zweig die Routen, die er braucht

Jeder Zweig braucht Routen zu den anderen Zweigen und zum LAN des Hubs, und keine für sein eigenes angeschlossenes LAN. Schieben Sie die entfernten Präfixe vom Hub aus, statt sie in jeden Router zu kleben, sodass eine vierte Site später eine neue Datei pro Client bedeutet statt vier Änderungen. Die Datei pro Client trägt auch die Zeile iroute, die Besitz und Ankündigung an derselben Stelle hält. Machen Sie das Verzeichnis und seine Dateien unter dem Berechtigungsmodell des Servers lesbar, sonst schlägt die Suche ohne Meldung fehl.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Eine vierte Site folgt demselben Muster: ein eigener authentifizierter Name, ein eigenes Präfix, eine Kernelroute im Hub, ein iroute Eintrag und Ankündigungen nur an die Sites, die sie erreichen dürfen.

Testen Sie in beide Richtungen, bevor Sie es für fertig erklären

Aktivieren Sie IPv4-Weiterleitung auf allen drei Routern und bestätigen Sie dann, dass die Firewall die beabsichtigten Flüsse in beide Richtungen zulässt, denn ein Einwegtest besteht mit kaputtem Rückweg häufiger, als irgendjemand erwartet. Zwischen den Sites ist keine Quellübersetzung nötig, und gerade die Bewahrung der ursprünglichen Quelle erlaubt jedem Zweig, seine eigene Politik auf eine Anfrage anzuwenden.

Testen Sie von einem Host im LAN eines Zweigs zu einem Dienst in einem anderen, drehen Sie dann die Richtung um und testen Sie anschließend von einem Zweig zum LAN des Hubs. Diese drei Ergebnisse sind unterschiedliche Belege, und keines von ihnen setzt die anderen voraus. Wenn ein Zweigrouter nicht das Standardgateway seines LANs ist, installieren Sie die entfernten Präfixe auf dem echten Gateway und nehmen Sie den Pool mit auf, wenn Tunnelclients Verbindungen in dieses LAN starten sollen.

Halten Sie den Plan, die Dateien pro Client und die Firewallregeln als ein Dokument fest, denn die nächste Site-Ergänzung wird daran gemessen.

Das Design hält zusammen, weil jede Schicht eine Aufgabe hat: der Plan hält Präfixe eindeutig, die Kernelroute bewegt Pakete, der iroute benennt den Besitzer, und die Firewall entscheidet, was erlaubt ist. Wenn etwas bricht, ist diese Liste zugleich die Reihenfolge, in der man es prüft.

Ähnliche Artikel