Proč proxy Cloudflare neumí přenášet OpenVPN na jednom jménu

Jeden stroj provozuje web i server OpenVPN a pokušení je nasměrovat na něj jedno jméno hostitele a nechat oranžový oblak, ať provoz vyřeší. Proxy vyřeší HTTP a HTTPS. Nevyřeší však relaci OpenVPN, ať už tato relace používá jakýkoli port. Dvě jména, jedno přímé a jedno proxované, nic nestojí a odstraňují celou třídu zmatení.

Dvě jména, dva přenosy

Dejte webu proxovaný záznam, aby jeho HTTP a HTTPS provoz procházel přes Cloudflare. Dejte VPN záznam pouze s DNS, který se překládá přímo na veřejný vstup VPN, a nechte klienta použít port UDP nebo TCP, na který byl nastaven.

Obě jména mohou skončit na stejném zdrojovém stroji. Rozdíl je v tom, co se děje mezi klientem a tímto strojem, a právě tento rozdíl je smyslem rozdělení.

Cloudflare ve přehledu síťových portů uvádí, které porty běžná webová proxy přijímá. Tento seznam se týká HTTP a HTTPS na těchto portech, nikoli libovolných protokolů, které náhodou sdílejí stejné číslo.

Port není protokol

Přesun OpenVPN na TCP 443 z něj neudělá HTTPS. Proxy stále očekává na začátku spojení HTTP požadavek, zatímco klient OpenVPN posílá binární řídicí zprávu. Spojení selže způsobem, který vypadá jako síťové blokování, protože do logu se nedostane nic užitečného.

Pokud je požadavek skutečně umístit produkt Cloudflare do datové cesty VPN, vyhodnoťte takový, který dokumentuje podporu protokolu, který potřebujete. Nepředpokládejte, že oranžový oblak je univerzální TCP nebo UDP tunel, protože je to reverzní proxy pro webový provoz s konkrétní úlohou.

Záznam pouze s DNS je nudná odpověď, která funguje, a je to ta, po které je třeba sáhnout nejdřív.

Jeden stroj stále potřebuje dva posluchače

Oddělená jména neumožňují, aby dva procesy svázaly stejnou adresu, port a přenos zároveň. Pokud webový server už drží TCP 443 na všech adresách, instance OpenVPN ho nemůže také převzít bez úmyslné dohody.

Svažte posluchač VPN s jiným portem, nebo s jinou adresou, nebo před něj postavte zdokumentovaný multiplexor a přijměte provozní náklady, které to přináší. Každá z těchto voleb má být vidět v pravidlech firewallu, protože posluchač, který nikdo nezdokumentoval, je ten, který se při incidentu přehlédne. Zapište zvolené svázání do stejného runbooku, který popisuje tunel. Pak ho příští člověk nebude ve dvě ráno znovu objevovat.

Certifikáty sledují spojení, které chrání

TLS spojení prohlížeče s Cloudflare a spojení Cloudflare s vaším zdrojem jsou dva oddělené vztahy se dvěma oddělenými certifikáty. Prohlížeč vidí hraniční certifikát. Zdroj předkládá Cloudflare svůj vlastní certifikát a certifikát Cloudflare Origin CA je určen přesně pro tento druhý vztah.

Tomuto zdrojovému certifikátu Cloudflare důvěřuje v režimu Full (strict) a není to obecně důvěryhodný certifikát prohlížeče. Pokud někdo navštíví jméno hostitele pouze s DNS přímo a dostane varování, je to očekávaný důsledek změněné cesty důvěry, nikoli důkaz, že šifrování přestalo.

Web, který se navštěvuje přímo, proto potřebuje řetěz certifikátů, kterému jeho prohlížeče důvěřují. To může existovat vedle proxovaného webu, jehož zdroj se vůbec nemá navštěvovat.

OpenVPN nese vlastní identitu serveru a autentizaci klienta, s vlastní certifikační autoritou a vlastní ochranou řídicího kanálu. Zámek na webu nic z toho nezajišťuje a oba procesy zajištění mají zůstat oddělené.

Expozice sleduje jméno

Záznam VPN pouze s DNS zveřejňuje adresu, na kterou ukazuje. Pokud je tato adresa i webovým zdrojem, zdroj není skrytý, a popisovat ho jako skrytý proto, že druhé jméno je proxované, je chyba, která přetrvá, dokud ho někdo naskenuje.

Rozhodněte, které webové požadavky smějí dosáhnout zdroje přímo, a prosazujte to na zdroji, poté povolte posluchač VPN za jeho vlastních podmínek. Stránky správy, stahování profilů a datový posluchač mohou mít tři různé požadavky na expozici, i když jeden balíček poskytuje všechny tři.

Držte generované odkazy na veřejném webovém jménu a schématu HTTPS a klientské profily na jménu VPN se skutečným protokolem a portem. Ani jedna služba nemá při běžném provozu záviset na přepínání nastavení proxy té druhé.

Pořadí práce: proxované jméno pro web, jméno pouze s DNS pro VPN, oddělené posluchače, certifikát pro každý vztah, pak jeden test, který prokáže, že každé jméno dosáhne jen na službu, na kterou má.