Warum der Cloudflare-Proxy OpenVPN nicht über einen Namen tragen kann

Eine Maschine betreibt die Website und den OpenVPN-Server, und die Versuchung ist, einen Hostnamen darauf zu zeigen und die orange Wolke den Verkehr regeln zu lassen. Der Proxy regelt HTTP und HTTPS. Er regelt keine OpenVPN-Sitzung, auf welchem Port diese Sitzung auch läuft. Zwei Namen, einer direkt und einer über den Proxy, kosten nichts und beseitigen die ganze Klasse der Verwirrung.

Zwei Namen, zwei Transportwege

Geben Sie der Website einen proxyten Eintrag, damit ihr HTTP- und HTTPS-Verkehr durch Cloudflare läuft. Geben Sie dem VPN einen reinen DNS-Eintrag, der direkt auf den öffentlichen VPN-Einstiegspunkt auflöst, und lassen Sie den Client den UDP- oder TCP-Port nutzen, für den er konfiguriert ist.

Beide Namen können auf derselben Ursprungsmaschine landen. Der Unterschied ist, was zwischen dem Client und dieser Maschine geschieht, und genau dieser Unterschied ist der Sinn der Trennung.

Die Netzwerkport-Referenz von Cloudflare listet auf, welche Ports der gewöhnliche Webproxy annimmt. Diese Liste betrifft HTTP und HTTPS auf diesen Ports, nicht beliebige Protokolle, die zufällig dieselbe Nummer teilen.

Der Port ist nicht das Protokoll

OpenVPN auf TCP 443 zu verschieben macht daraus kein HTTPS. Der Proxy erwartet am Verbindungsbeginn weiterhin eine HTTP-Anfrage, und ein OpenVPN-Client sendet stattdessen eine binäre Steuernachricht. Die Verbindung scheitert auf eine Weise, die wie eine Netzwerksperre aussieht, weil nichts Nützliches in einem Protokoll ankommt.

Wenn die Anforderung wirklich darin besteht, ein Cloudflare-Produkt in den VPN-Datenpfad zu bringen, prüfen Sie eines, das die Unterstützung des benötigten Protokolls dokumentiert. Nehmen Sie nicht an, die orange Wolke sei ein allgemeiner TCP- oder UDP-Tunnel, denn sie ist ein Reverse-Proxy für Webverkehr mit einer bestimmten Aufgabe.

Ein reiner DNS-Eintrag ist die langweilige Antwort, die funktioniert, und die, zu der man zuerst greifen sollte.

Eine Maschine braucht trotzdem zwei Listener

Getrennte Namen erlauben es nicht, dass zwei Prozesse gleichzeitig dieselbe Adresse, denselben Port und dasselbe Transportprotokoll belegen. Wenn der Webserver bereits TCP 443 auf allen Adressen hält, kann eine OpenVPN-Instanz ihn nicht ebenfalls nehmen, ohne eine bewusste Regelung.

Binden Sie den VPN-Listener an einen anderen Port oder an eine andere Adresse, oder setzen Sie einen dokumentierten Multiplexer davor und akzeptieren Sie die Betriebskosten, die damit einhergehen. Jede dieser Entscheidungen sollte in den Firewall-Regeln sichtbar sein, denn ein Listener, den niemand dokumentiert hat, ist der, der während eines Vorfalls übersehen wird. Schreiben Sie die gewählte Bindung in dasselbe Runbook, das den Tunnel beschreibt. Dann entdeckt die nächste Person sie nicht um zwei Uhr morgens neu.

Zertifikate folgen der Verbindung, die sie schützen

Die TLS-Verbindung des Browsers zu Cloudflare und die Verbindung von Cloudflare zu Ihrem Ursprung sind zwei getrennte Beziehungen mit zwei getrennten Zertifikaten. Der Browser sieht ein Edge-Zertifikat. Der Ursprung präsentiert Cloudflare sein eigenes Zertifikat, und ein Cloudflare Origin CA-Zertifikat ist genau für diese zweite Beziehung gedacht.

Diesem Ursprungszertifikat vertraut Cloudflare im Modus Full (strict), und es ist kein allgemein vertrauenswürdiges Browserzertifikat. Wenn jemand den reinen DNS-Hostnamen direkt besucht und eine Warnung erhält, ist das die erwartete Folge eines geänderten Vertrauenspfads und kein Beweis, dass die Verschlüsselung aufgehört hat.

Eine direkt besuchte Website braucht daher eine Zertifikatskette, der ihre Browser vertrauen. Das kann mit einer proxyten Seite koexistieren, deren Ursprung überhaupt nicht für Besuche gedacht ist.

OpenVPN trägt seine eigene Serveridentität und Client-Authentifizierung, mit eigener Zertifizierungsstelle und eigenem Schutz des Steuerkanals. Ein Schloss auf der Website stellt nichts davon bereit, und die beiden Bereitstellungsprozesse sollten getrennt bleiben.

Die Exposition folgt dem Namen

Ein VPN-Eintrag mit reinem DNS veröffentlicht die Adresse, auf die er zeigt. Wenn diese Adresse auch der Web-Ursprung ist, ist der Ursprung nicht verborgen, und ihn als verborgen zu beschreiben, weil der andere Name über den Proxy läuft, ist ein Fehler, der bestehen bleibt, bis jemand danach scannt.

Entscheiden Sie, welche Webanfragen den Ursprung direkt erreichen dürfen, und setzen Sie das am Ursprung durch, dann erlauben Sie den VPN-Listener zu seinen eigenen Bedingungen. Verwaltungsseiten, Profil-Downloads und der Daten-Listener können drei verschiedene Expositionsanforderungen haben, selbst wenn ein Paket alle drei bereitstellt.

Halten Sie generierte Links auf dem öffentlichen Webnamen und dem HTTPS-Schema und Client-Profile auf dem VPN-Namen mit dem echten Protokoll und Port. Keiner der Dienste sollte im Normalbetrieb davon abhängen, die Proxy-Einstellung des anderen umzuschalten.

Reihenfolge der Arbeit: proxierter Name für die Seite, reiner DNS-Name für das VPN, getrennte Listener, Zertifikat pro Beziehung, dann ein Test, der beweist, dass jeder Name nur den Dienst erreicht, den er erreichen soll.