Waarom Cloudflare se proxy OpenVPN nie op een naam kan dra nie

Een masjien bedryf die webwerf en die OpenVPN-bediener, en die versoeking is om een gasheernaam daarop te rig en die oranje wolk die verkeer te laat uitsorteer. Die proxy sorteer HTTP en HTTPS uit. Dit sorteer nie 'n OpenVPN-sessie uit nie, ongeag watter poort daardie sessie gebruik. Twee name, een direk en een via die proxy, kos niks en verwyder die hele klas verwarring.

Twee name, twee transportweë

Gee die webwerf 'n rekord wat deur die proxy gaan, sodat sy HTTP- en HTTPS-verkeer deur Cloudflare loop. Gee die VPN 'n DNS-only rekord wat reguit na die publieke VPN-toegangspunt wys, en laat die kliënt die UDP- of TCP-poort gebruik waarvoor dit opgestel is.

Albei name kan by dieselfde oorsprongmasjien uitkom. Die verskil is wat tussen die kliënt en daardie masjien gebeur, en daardie verskil is die punt van die splitsing.

Cloudflare se netwerkpoort-verwysing lys watter poorte die gewone webproxy aanvaar. Daardie lys gaan oor HTTP en HTTPS op daardie poorte, nie oor willekeurige protokolle wat toevallig 'n nommer deel nie.

Die poort is nie die protokol nie

Om OpenVPN na TCP 443 te skuif, maak dit nie HTTPS nie. Die proxy verwag steeds 'n HTTP-versoek aan die begin van die verbinding, en 'n OpenVPN-kliënt stuur eerder 'n binêre beheerboodskap. Die verbinding misluk op 'n manier wat soos 'n netwerkblokkade lyk, omdat niks nuttigs 'n log bereik nie.

As die vereiste werklik is om 'n Cloudflare-produk in die VPN-datapad te plaas, ondersoek een wat dokumenteer dat dit die protokol ondersteun wat jy nodig het. Moenie aanvaar die oranje wolk is 'n algemene TCP- of UDP-tonnel nie, want dit is 'n omgekeerde proxy vir webverkeer met 'n spesifieke taak.

'n Slegs-DNS-rekord is die vervelige antwoord wat werk, en dit is die een om eerste te probeer.

Een masjien het steeds twee luisteraars nodig

Geskeide name laat nie twee prosesse toe om dieselfde adres, poort en transport gelyktydig te bind nie. As die webbediener reeds TCP 443 op alle adresse hou, kan 'n OpenVPN-instansie dit nie ook neem sonder 'n doelbewuste reëling nie.

Bind die VPN-luisteraar aan 'n ander poort, of aan 'n ander adres, of plaas 'n gedokumenteerde multiplekser voor en aanvaar die bedryfskoste wat daarmee saamkom. Elkeen van daardie keuses moet in die firewall-reëls sigbaar wees, want 'n luisteraar wat niemand gedokumenteer het nie, is die een wat tydens 'n voorval gemis word. Skryf die gekose binding in dieselfde runbook wat die tonnel beskryf. Dan herontdek die volgende persoon dit nie om twee-uur die oggend nie.

Sertifikate volg die verbinding wat hulle beskerm

Die blaaier se TLS-verbinding na Cloudflare en Cloudflare se verbinding na jou oorsprong is twee afsonderlike verhoudings met twee afsonderlike sertifikate. Die blaaier sien 'n rand-sertifikaat. Die oorsprong bied sy eie sertifikaat aan Cloudflare, en 'n Cloudflare Origin CA-sertifikaat is juis vir daardie tweede verhouding bedoel.

Daardie oorsprongsertifikaat word deur Cloudflare in Full (strict)-modus vertrou en is nie 'n algemeen vertroude blaaier-sertifikaat nie. As iemand die slegs-DNS-gasheernaam direk besoek en 'n waarskuwing kry, is dit die verwagte gevolg van 'n veranderde vertrouenspad, nie bewys dat enkripsie opgehou het nie.

'n Webwerf wat direk besoek word, het dus 'n sertifikaatketting nodig wat sy blaaier vertrou. Dit kan saam bestaan met 'n webwerf via die proxy waarvan die oorsprong glad nie bedoel is om besoek te word nie.

OpenVPN dra sy eie bedieneridentiteit en kliëntverifikasie, met sy eie sertifikaatowerheid en sy eie beskerming van die beheerkanaal. 'n Hangslot op die webwerf verskaf niks daarvan nie, en die twee voorsieningsprosesse moet geskei bly.

Blootstelling volg die naam

'n Slegs-DNS VPN-rekord publiseer die adres waarna dit wys. As daardie adres ook die web-oorsprong is, is die oorsprong nie versteek nie, en om dit as versteek te beskryf omdat die ander naam via die proxy gaan, is 'n fout wat bly voortduur totdat iemand daarna scan.

Bepaal watter webversoeke die oorsprong direk mag bereik en handhaaf dit by die oorsprong, en laat dan die VPN-luisteraar op sy eie voorwaardes toe. Bestuursbladsye, profielaflaaie en die dataluisteraar kan drie verskillende blootstellingsvereistes hê selfs wanneer een pakket al drie verskaf.

Hou gegenereerde skakels op die publieke webnaam en HTTPS-skema, en hou kliëntprofiele op die VPN-naam met die werklike protokol en poort. Nie een diens moet daarvan afhang om die ander se proxy-instelling tydens normale werking om te skakel nie.

Volgorde van werk: naam via die proxy vir die werf, slegs-DNS-naam vir die VPN, aparte luisteraars, sertifikaat per verhouding, dan een toets wat bewys elke naam bereik net die diens wat dit moet.