Waarom de Cloudflare-proxy OpenVPN niet op één naam kan dragen

Eén machine draait de website en de OpenVPN-server, en de verleiding is om één hostnaam daarop te richten en de oranje wolk het verkeer te laten regelen. De proxy regelt HTTP en HTTPS. Hij regelt geen OpenVPN-sessie, welke poort die sessie ook gebruikt. Twee namen, één direct en één via de proxy, kosten niets en nemen de hele klasse verwarring weg.

Twee namen, twee transporten

Geef de website een geproxiede record zodat het HTTP- en HTTPS-verkeer via Cloudflare loopt. Geef de VPN een DNS-only record dat rechtstreeks naar de openbare VPN-ingang verwijst, en laat de client de UDP- of TCP-poort gebruiken waarvoor hij is geconfigureerd.

Beide namen kunnen op dezelfde oorsprongsmachine uitkomen. Het verschil is wat er tussen de client en die machine gebeurt, en dat verschil is het punt van de splitsing.

Cloudflare's referentie voor netwerkpoorten somt op welke poorten de gewone webproxy accepteert. Die lijst gaat over HTTP en HTTPS op die poorten, niet over willekeurige protocollen die toevallig een nummer delen.

De poort is niet het protocol

OpenVPN naar TCP 443 verplaatsen maakt er geen HTTPS van. De proxy verwacht nog steeds een HTTP-verzoek aan het begin van de verbinding, en een OpenVPN-client stuurt in plaats daarvan een binair besturingsbericht. De verbinding mislukt op een manier die op een netwerkblokkade lijkt, omdat er niets bruikbaars in een logboek belandt.

Als de eis echt is om een Cloudflare-product in het VPN-datapad te zetten, beoordeel dan een product dat ondersteuning voor het protocol dat je nodig hebt documenteert. Ga er niet van uit dat de oranje wolk een algemene TCP- of UDP-tunnel is, want het is een reverse proxy voor webverkeer met een specifieke taak.

Een DNS-only record is het saaie antwoord dat werkt, en dat is degene waarnaar je eerst moet grijpen.

Eén machine heeft nog steeds twee luisteraars nodig

Gescheiden namen laten twee processen niet toe om tegelijk hetzelfde adres, dezelfde poort en hetzelfde transport te binden. Als de webserver al TCP 443 op alle adressen vasthoudt, kan een OpenVPN-instantie die niet ook nemen zonder bewuste afspraak.

Bind de VPN-luisteraar aan een andere poort, of aan een ander adres, of zet een gedocumenteerde multiplexer ervoor en accepteer de operationele kosten die daarmee komen. Elk van die keuzes moet zichtbaar zijn in de firewallregels, want een luisteraar die niemand documenteerde is degene die tijdens een incident wordt gemist. Schrijf de gekozen binding in hetzelfde runbook dat de tunnel beschrijft. Dan ontdekt de volgende persoon hem niet opnieuw om twee uur in de nacht.

Certificaten volgen de verbinding die ze beschermen

De TLS-verbinding van de browser naar Cloudflare en de verbinding van Cloudflare naar jouw oorsprong zijn twee aparte relaties met twee aparte certificaten. De browser ziet een edge-certificaat. De oorsprong presenteert zijn eigen certificaat aan Cloudflare, en een Cloudflare Origin CA-certificaat is precies voor die tweede relatie bedoeld.

Dat oorsprongscertificaat wordt door Cloudflare in Full (strict)-modus vertrouwd en het is geen algemeen vertrouwd browsercertificaat. Als iemand de DNS-only hostnaam rechtstreeks bezoekt en een waarschuwing krijgt, is dat het verwachte gevolg van een gewijzigd vertrouwenspad, niet het bewijs dat versleuteling stopte.

Een website die rechtstreeks wordt bezocht heeft daarom een certificaatketen nodig die de browsers vertrouwen. Dat kan naast een geproxiede site bestaan waarvan de oorsprong helemaal niet bedoeld is om te bezoeken.

OpenVPN draagt zijn eigen serveridentiteit en clientauthenticatie, met zijn eigen certificaatautoriteit en zijn eigen bescherming van het besturingskanaal. Een slotje op de website levert daar niets van, en de twee inrichtingsprocessen moeten gescheiden blijven.

Blootstelling volgt de naam

Een DNS-only VPN-record publiceert het adres waarnaar hij wijst. Als dat adres ook de web-oorsprong is, is de oorsprong niet verborgen, en hem als verborgen beschrijven omdat de andere naam geproxied is, is een fout die blijft tot iemand ernaar scant.

Bepaal welke webverzoeken de oorsprong rechtstreeks mogen bereiken en handhaaf dat bij de oorsprong, sta dan de VPN-luisteraar op zijn eigen voorwaarden toe. Beheerpagina's, profieldownloads en de dataluisteraar kunnen drie verschillende blootstellingsvereisten hebben, zelfs wanneer één pakket alle drie levert.

Houd gegenereerde links op de openbare webnaam en het HTTPS-schema, en houd clientprofielen op de VPN-naam met het echte protocol en de poort. Geen van beide diensten zou tijdens normaal bedrijf afhankelijk moeten zijn van het omzetten van de proxyinstelling van de andere.

Werkvolgorde: geproxiede naam voor de site, DNS-only naam voor de VPN, aparte luisteraars, certificaat per relatie, en dan één test die bewijst dat elke naam alleen de dienst bereikt die hij moet bereiken.