Hvorfor Cloudflares proxy ikke kan bære OpenVPN på ét navn

Én maskine kører websitet og OpenVPN-serveren, og fristelsen er at pege ét værtsnavn mod den og lade den orange sky klare trafikken. Proxyen klarer HTTP og HTTPS. Den klarer ikke en OpenVPN-session, uanset hvilken port den session bruger. To navne, ét direkte og ét proxet, koster ingenting og fjerner hele den klasse af forvirring.

To navne, to transportformer

Giv websitet en proxet post, så dets HTTP- og HTTPS-trafik går gennem Cloudflare. Giv VPN'en en DNS-kun-post, der slår direkte op på den offentlige VPN-indgang, og lad klienten bruge den UDP- eller TCP-port, den er konfigureret til.

Begge navne kan ende på samme oprindelsesmaskine. Forskellen er, hvad der sker mellem klienten og den maskine, og den forskel er hele pointen med delingen.

Cloudflares oversigt over netværksporte viser, hvilke porte den almindelige webproxy accepterer. Den liste handler om HTTP og HTTPS på de porte, ikke om vilkårlige protokoller, der tilfældigvis deler et nummer.

Porten er ikke protokollen

At flytte OpenVPN til TCP 443 gør det ikke til HTTPS. Proxyen forventer stadig en HTTP-anmodning i starten af forbindelsen, og en OpenVPN-klient sender i stedet en binær kontrolbesked. Forbindelsen fejler på en måde, der ligner en netværksblokering, fordi intet brugbart når en log.

Hvis kravet virkelig er at sætte et Cloudflare-produkt i VPN'ens datastrøm, bør du vurdere et, der dokumenterer støtte til den protokol, du har brug for. Antag ikke, at den orange sky er en generel TCP- eller UDP-tunnel, for den er en reverse proxy for webtrafik med en bestemt opgave.

En DNS-kun-post er det kedelige svar, der virker, og det er den, man skal gribe efter først.

Én maskine kræver stadig to lyttere

Adskilte navne tillader ikke to processer at binde samme adresse, port og transport samtidig. Hvis webserveren allerede har TCP 443 på alle adresser, kan en OpenVPN-instans ikke også tage den uden en bevidst aftale.

Bind VPN-lytteren til en anden port, eller en anden adresse, eller sæt en dokumenteret multiplekser foran og accepter den driftsudgift, der følger. Hvert af disse valg bør fremgå af firewall-reglerne, for en lytter, som ingen har dokumenteret, er den, der bliver overset under en hændelse. Skriv den valgte binding i samme runbook, som beskriver tunnelen. Så skal den næste person ikke genopdage den klokken to om natten.

Certifikater følger den forbindelse, de beskytter

Browserens TLS-forbindelse til Cloudflare og Cloudflares forbindelse til din oprindelse er to adskilte forhold med to adskilte certifikater. Browseren ser et kantcertifikat. Oprindelsen præsenterer sit eget certifikat for Cloudflare, og et Cloudflare Origin CA-certifikat er netop beregnet til det andet forhold.

Det oprindelsescertifikat er betroet af Cloudflare i Full (strict)-tilstand og er ikke et almindeligt betroet browsercertifikat. Hvis nogen besøger DNS-kun-værtsnavnet direkte og får en advarsel, er det den forventede konsekvens af en ændret tillidssti, ikke bevis for at krypteringen er stoppet.

Et website, der besøges direkte, har derfor brug for en certifikatkæde, som dets browsere stoler på. Det kan eksistere side om side med et proxet site, hvis oprindelse slet ikke er beregnet til at blive besøgt.

OpenVPN bærer sin egen serveridentitet og klientgodkendelse med sin egen certifikatmyndighed og sin egen beskyttelse af kontrolkanalen. En hængelås på websitet skaffer intet af det, og de to skabelsesprocesser bør holdes adskilt.

Eksponering følger navnet

En VPN-post med kun DNS offentliggør den adresse, den peger på. Hvis den adresse også er weboprindelsen, er oprindelsen ikke skjult, og at beskrive den som skjult, fordi det andet navn er proxet, er en fejl, der består, indtil nogen scanner efter den.

Beslut, hvilke webanmodninger der må nå oprindelsen direkte, og håndhæv det på oprindelsen, og tillad derefter VPN-lytteren på dens egne vilkår. Administrationssider, profildownloads og datalytteren kan have tre forskellige eksponeringskrav, selv når én pakke leverer alle tre.

Hold genererede links på det offentlige webnavn og HTTPS-skemaet, og hold klientprofiler på VPN-navnet med den rigtige protokol og port. Ingen af tjenesterne bør afhænge af at vende den andens proxyindstilling under normal drift.

Arbejdsrækkefølge: proxet navn til sitet, DNS-kun-navn til VPN'en, adskilte lyttere, certifikat pr. forhold, og derefter én test, der beviser, at hvert navn kun når den tjeneste, det skal.