Varför Cloudflares proxy inte kan bära OpenVPN på ett namn

En maskin kör webbplatsen och OpenVPN-servern, och frestelsen är att peka ett värdnamn mot den och låta det orange molnet reda ut trafiken. Proxyn reder ut HTTP och HTTPS. Den reder inte ut en OpenVPN-session, vilken port den sessionen än använder. Två namn, ett direkt och ett proxat, kostar ingenting och tar bort hela den här klassen av förvirring.

Två namn, två transporter

Ge webbplatsen en proxad post så att dess HTTP- och HTTPS-trafik går genom Cloudflare. Ge VPN:en en DNS-bara post som löses direkt till den publika VPN-ingången, och låt klienten använda den UDP- eller TCP-port som den är konfigurerad för.

Båda namnen kan hamna på samma ursprungsmaskin. Skillnaden är vad som händer mellan klienten och den maskinen, och den skillnaden är poängen med delningen.

Cloudflares referens för nätverksportar listar vilka portar den vanliga webbproxyn accepterar. Den listan handlar om HTTP och HTTPS på de portarna, inte om godtyckliga protokoll som råkar dela ett nummer.

Porten är inte protokollet

Att flytta OpenVPN till TCP 443 gör det inte till HTTPS. Proxyn väntar fortfarande på en HTTP-förfrågan i början av anslutningen, och en OpenVPN-klient skickar i stället ett binärt kontrollmeddelande. Anslutningen misslyckas på ett sätt som ser ut som en nätverksblockering, eftersom ingenting användbart når en logg.

Om kravet verkligen är att sätta en Cloudflare-produkt i VPN:ens dataväg, utvärdera en som dokumenterar stöd för det protokoll du behöver. Anta inte att det orange molnet är en allmän TCP- eller UDP-tunnel, för det är en omvänd proxy för webbtrafik med en bestämd uppgift.

En DNS-bara post är det tråkiga svaret som fungerar, och det är det man ska gripa efter först.

En maskin behöver fortfarande två lyssnare

Åtskilda namn låter inte två processer binda samma adress, port och transport samtidigt. Om webbservern redan håller TCP 443 på alla adresser kan en OpenVPN-instans inte också ta den utan en medveten ordning.

Bind VPN-lyssnaren till en annan port, eller en annan adress, eller sätt en dokumenterad multiplexor framför och acceptera driftkostnaden som följer med. Vart och ett av dessa val bör synas i brandväggsreglerna, för en lyssnare som ingen dokumenterat är den som missas under en incident. Skriv den valda bindningen i samma runbook som beskriver tunneln. Då upptäcker nästa person den inte igen klockan två på natten.

Certifikat följer anslutningen de skyddar

Webbläsarens TLS-anslutning till Cloudflare och Cloudflares anslutning till ditt ursprung är två separata relationer med två separata certifikat. Webbläsaren ser ett kantcertifikat. Ursprunget presenterar sitt eget certifikat för Cloudflare, och ett Cloudflare Origin CA-certifikat är avsett just för den andra relationen.

Det ursprungscertifikatet är betrott av Cloudflare i läget Full (strict) och är inte ett allmänt betrott webbläsarcertifikat. Om någon besöker det DNS-bara värdnamnet direkt och får en varning, är det den förväntade följden av en ändrad förtroendeväg, inte ett bevis på att krypteringen upphörde.

En webbplats som besöks direkt behöver därför en certifikatkedja som dess webbläsare litar på. Det kan finnas sida vid sida med en proxad webbplats vars ursprung inte alls är avsett att besökas.

OpenVPN bär sin egen serveridentitet och klientautentisering, med sin egen certifikatutfärdare och sitt eget skydd av kontrollkanalen. Ett hänglås på webbplatsen ger inget av detta, och de två framtagningsprocesserna bör hållas åtskilda.

Exponering följer namnet

En DNS-bara VPN-post publicerar adressen den pekar på. Om den adressen också är webbursprunget är ursprunget inte dolt, och att beskriva det som dolt därför att det andra namnet är proxat är ett fel som består tills någon skannar efter det.

Bestäm vilka webbförfrågningar som får nå ursprunget direkt och genomdriv det vid ursprunget, tillåt sedan VPN-lyssnaren på dess egna villkor. Administrationssidor, profilnedladdningar och datalyssnaren kan ha tre olika exponeringskrav även när ett paket levererar alla tre.

Håll genererade länkar på det publika webbnamnet och HTTPS-schemat, och håll klientprofiler på VPN-namnet med det riktiga protokollet och porten. Ingen av tjänsterna bör under normal drift bero på att vända den andras proxyinställning.

Arbetsordning: proxat namn för webbplatsen, DNS-bart namn för VPN:en, åtskilda lyssnare, certifikat per relation, och sedan ett test som bevisar att varje namn bara når den tjänst det ska.