OpenVPN-Clients über Cloudflare routen? Prüfen Sie zuerst die Rolle

Sie haben einen funktionierenden OpenVPN-Server und einen Host, der auch die Gerätesoftware von Cloudflare ausführt, und der naheliegende nächste Schritt sieht so aus, als würde man den Client-Verkehr dorthin lenken. Zwei funktionierende Verbindungen auf einer Maschine ergeben noch kein Transit-Gateway. Was fehlt, ist eine dokumentierte Rolle zum Weiterleiten von Paketen, die jemand anderem gehören, und eine Richtlinie, die diese Pakete bei ihrer Ankunft klassifiziert.

Vor jeder Regel stehen vier Fragen: Welcher Verkehr kommt herein, wohin geht er als Nächstes, wie finden die Antworten den Weg zurück, und was tut das Design, wenn dieser zweite Pfad ausfällt. Die ersten beiden sind Fähigkeitsfragen.

Zwei Dienste auf einem Host sind kein Transitpfad

Ein Geräteclient ist dafür gebaut, Verkehr zu verarbeiten, der auf der Maschine entsteht, auf der er läuft. Er fängt die Namensauflösung oder ausgewählten Anwendungsverkehr ab und schickt ihn durch seinen eigenen Tunnel, und seine Richtlinie ist für den Benutzer dieses Geräts und dessen Prozesse geschrieben. Ein Paket, das von einem OpenVPN-Client weitergeleitet wird, ist keine lokale Ausgabe, daher klassifizieren dieselben Regeln es nicht. Das ist kein Konfigurationsdetail, das man mit einer breiteren Regel überdecken kann, denn es entscheidet, ob die Software das Paket überhaupt sieht.

Deshalb ist die Designfrage eine Fähigkeitsfrage. Entweder hat das installierte Produkt eine dokumentierte Rolle, die Verkehr für andere Netze weiterleitet, oder die Transitfunktion gehört ganz woanders hin.

Welche Cloudflare-Rolle weiterleiten darf

Der Geräteclient von Cloudflare bietet Modi, die sich im Umfang unterscheiden: nur Namensauflösung, Verkehr vom Gerät und manchmal beides. Keiner dieser Modi macht den Host zu einem Router für einen privaten Bereich, der über einen anderen Tunnel ankommt. Die dedizierte Routingrolle ist ein separates Produkt mit eigenem Connector, eigener Registrierung und eigenem Netzmodell.

Prüfen Sie die installierte Rolle, bevor Sie Routen darum herum entwerfen. Lesen Sie, welche Schnittstelle der Connector anlegt, ob er bestimmte Präfixe oder eine Standardroute ankündigt und ob die lokale Richtlinie auch für weitergeleitete Pakete gilt. Wird nur lokaler Verkehr verarbeitet, kann der OpenVPN-Server nicht der Transitpunkt sein, egal wie die Übersetzungsregel geschrieben ist.

Hier muss auch eine Anforderung an einen öffentlichen Ausgang präzise formuliert werden. Ein von Cloudflare bereitgestellter Ausgang für weitergeleiteten Client-Verkehr ist ein bestimmter Anwendungsfall und muss gegen den Dienst bestätigt werden, den Sie tatsächlich haben.

Halten Sie den äußeren Tunnel unabhängig von der neuen Route

In dem Moment, in dem Sie eine Standardroute zur neuen Schnittstelle hinzufügen, beginnt der eigene ausgehende Verkehr des Servers, darum zu konkurrieren, und das schließt Antworten an die OpenVPN-Clients und Ihre SSH-Sitzung zur Kiste ein. Das übliche Symptom ist ein Tunnel, der sich aufbaut und dann stirbt, oder ein Administrator, der ausgesperrt wird, während die Änderung zu funktionieren scheint. Vergleichen Sie ip route get für den Endpunkt vorher und nachher, und verwenden Sie Policy-Routing oder eine Host-Route, um den eigenen Transport des Servers dort zu lassen, wo er war. Führen Sie diesen Vergleich von der Kiste selbst aus, denn die Sicht des Servers auf seine eigene Route ist die, die zählt.

Eine Ausnahme für die öffentliche Adresse des Servers reicht für sich genommen nicht aus, denn der Rückweg jedes entfernten Administrators ist ein anderer Fluss. Entscheiden Sie, welche dieser Flüsse die Änderung überleben müssen, und prüfen Sie dann jeden einzelnen, statt anzunehmen, der erste decke die übrigen ab.

Begrenzen Sie Weiterleitung und Übersetzung auf einen Fluss

Empfangene Pakete folgen dem Weiterleitungspfad, nicht dem lokalen Ausgabepfad, also lebt die entscheidende Regel im Forward-Hook. Wo die weitere Schnittstelle eine Übersetzung braucht, begrenzen Sie die Quelle auf den Client-Pool, das Ziel auf das Erlaubte und den Ausgang auf diese eine Schnittstelle. Eine Masquerade-Regel, die nur an eine Schnittstelle gebunden ist, wählt selbst keine Route und erlaubt keine Weiterleitung an einem anderen Filter vorbei.

Entscheiden Sie das Fail-Closed-Verhalten im Voraus und testen Sie es dann. Stoppen Sie den weiteren Pfad und bestätigen Sie, dass die Clients den vorgesehenen Ausgang verlieren, statt still auf den gewöhnlichen Uplink zurückzufallen, denn das ist das Ergebnis, das niemand bemerkt, bis der Verkehr durch die falsche Tür hinausgeht. Wiederholen Sie die Prüfung für die Namensauflösung und für IPv6, denn ein Regelsatz nur für v4 lässt einen v6-Pfad offen.

Schreiben Sie die vier Antworten auf, auf die Sie sich festgelegt haben, und die Beobachtung, die jede davon belegt. Ein Transitpfad, den Sie beschreiben können, ist einer, den Sie bei der nächsten Incident-Überprüfung verteidigen können.