Hvorfor Cloudflare-proxyen ikke kan bære OpenVPN på ett navn

Én maskin kjører nettstedet og OpenVPN-serveren, og fristelsen er å peke ett vertsnavn mot den og la den oransje skyen ordne trafikken. Proxyen ordner HTTP og HTTPS. Den ordner ikke en OpenVPN-økt, uansett hvilken port den økten bruker. To navn, ett direkte og ett proxet, koster ingenting og fjerner hele denne klassen av forvirring.

To navn, to transportlag

Gi nettstedet en proxet post slik at HTTP- og HTTPS-trafikken går gjennom Cloudflare. Gi VPN-en en DNS-bare post som løses direkte til den offentlige VPN-inngangen, og la klienten bruke den UDP- eller TCP-porten den er konfigurert for.

Begge navnene kan ende på samme opprinnelsesmaskin. Forskjellen er hva som skjer mellom klienten og den maskinen, og den forskjellen er poenget med delingen.

Cloudflares referanse for nettverksporter lister opp hvilke porter den vanlige nettproxyen godtar. Den listen handler om HTTP og HTTPS på disse portene, ikke om vilkårlige protokoller som tilfeldigvis deler et nummer.

Porten er ikke protokollen

Å flytte OpenVPN til TCP 443 gjør det ikke til HTTPS. Proxyen forventer fortsatt en HTTP-forespørsel ved starten av tilkoblingen, og en OpenVPN-klient sender i stedet en binær kontrollmelding. Tilkoblingen feiler på en måte som ser ut som en nettverksblokkering, fordi ingenting nyttig når en logg.

Hvis kravet virkelig er å sette et Cloudflare-produkt i VPN-ens datasti, vurder et som dokumenterer støtte for protokollen du trenger. Ikke anta at den oransje skyen er en generell TCP- eller UDP-tunnel, for den er en omvendt proxy for netttrafikk med en bestemt oppgave.

En DNS-bare post er det kjedelige svaret som fungerer, og det er det man bør gripe til først.

Én maskin trenger fortsatt to lyttere

Adskilte navn lar ikke to prosesser binde samme adresse, port og transport samtidig. Hvis nettserveren allerede holder TCP 443 på alle adresser, kan en OpenVPN-forekomst ikke også ta den uten en bevisst ordning.

Bind VPN-lytteren til en annen port, eller en annen adresse, eller sett en dokumentert multiplekser foran og godta driftskostnaden som følger med. Hvert av disse valgene bør være synlig i brannmurreglene, for en lytter som ingen har dokumentert, er den som blir oversett under en hendelse. Skriv den valgte bindingen i samme runbook som beskriver tunnelen. Da oppdager ikke neste person den på nytt klokken to om natten.

Sertifikater følger tilkoblingen de beskytter

Nettleserens TLS-tilkobling til Cloudflare og Cloudflares tilkobling til opprinnelsen din er to separate forhold med to separate sertifikater. Nettleseren ser et kantsertifikat. Opprinnelsen presenterer sitt eget sertifikat for Cloudflare, og et Cloudflare Origin CA-sertifikat er ment nettopp for det andre forholdet.

Dette opprinnelsessertifikatet stoles på av Cloudflare i Full (strict)-modus, og det er ikke et allment klarert nettlesersertifikat. Hvis noen besøker DNS-bare vertsnavnet direkte og får en advarsel, er det den forventede konsekvensen av en endret tillitssti, ikke bevis for at krypteringen stoppet.

Et nettsted som besøkes direkte trenger derfor en sertifikatkjede som nettleserne stoler på. Det kan eksistere side om side med et proxet nettsted der opprinnelsen slett ikke er ment å besøkes.

OpenVPN bærer sin egen serveridentitet og klientautentisering, med sin egen sertifikatmyndighet og sin egen beskyttelse av kontrollkanalen. En hengelås på nettstedet gir ingenting av dette, og de to klargjøringsprosessene bør holdes adskilt.

Eksponering følger navnet

En DNS-bare VPN-post publiserer adressen den peker til. Hvis den adressen også er nettopprinnelsen, er opprinnelsen ikke skjult, og å beskrive den som skjult fordi det andre navnet er proxet, er en feil som varer til noen skanner etter den.

Bestem hvilke nettforespørsler som kan nå opprinnelsen direkte, og håndhev det ved opprinnelsen, og tillat deretter VPN-lytteren på egne vilkår. Administrasjonssider, profildownloads og datalytteren kan ha tre forskjellige eksponeringskrav selv når én pakke leverer alle tre.

Hold genererte lenker på det offentlige nettnavnet og HTTPS-skjemaet, og hold klientprofiler på VPN-navnet med den ekte protokollen og porten. Ingen av tjenestene bør avhenge av å snu den andres proxyinnstilling under normal drift.

Arbeidsrekkefølge: proxet navn for nettstedet, DNS-bart navn for VPN-en, adskilte lyttere, sertifikat per forhold, og deretter én test som beviser at hvert navn bare når tjenesten det skal.