Kial la prokurilo de Cloudflare ne povas porti OpenVPN sur unu nomo

Unu maŝino funkciigas la retejon kaj la OpenVPN-servilon, kaj la tento estas direkti unu gastigantan nomon al ĝi kaj lasi la oranĝan nubon ordigi la trafikon. La prokurilo ordigas HTTP kaj HTTPS. Ĝi ne ordigas OpenVPN-sesion, sendepende de tio, kiun havenon tiu sesio uzas. Du nomoj, unu rekta kaj unu prokurita, kostas nenion kaj forigas la tutan klason de konfuzo.

Du nomoj, du transportoj

Donu al la retejo prokuritan rikordon, por ke ĝia HTTP kaj HTTPS trafiko pasu tra Cloudflare. Donu al la VPN rikordon nur-DNS, kiu solvas rekte al la publika VPN-enirejo, kaj lasu la klienton uzi la UDP aŭ TCP havenon, por kiu ĝi estis agordita.

Ambaŭ nomoj povas finiĝi ĉe la sama origina maŝino. La diferenco estas tio, kio okazas inter la kliento kaj tiu maŝino, kaj ĝuste tiu diferenco estas la senco de la apartigo.

La referenco pri retaj havenoj de Cloudflare listigas, kiujn havenojn akceptas la ordinara reta prokurilo. Tiu listo temas pri HTTP kaj HTTPS sur tiuj havenoj, ne pri arbitraj protokoloj, kiuj hazarde dividas numeron.

La haveno ne estas la protokolo

Transloki OpenVPN al TCP 443 ne igas ĝin HTTPS. La prokurilo ankoraŭ atendas HTTP-peton komence de la konekto, kaj OpenVPN-kliento anstataŭe sendas duuman regan mesaĝon. La konekto malsukcesas tiel, ke ĝi aspektas kiel reta blokado, ĉar nenio utila atingas protokolon.

Se la postulo vere estas meti Cloudflare-produkton en la VPN-datvojon, taksu tian, kiu dokumentas subtenon de la protokolo, kiun vi bezonas. Ne supozu, ke la oranĝa nubo estas ĝenerala TCP aŭ UDP tunelo, ĉar ĝi estas inversa prokurilo por reta trafiko kun specifa tasko.

Rikordo nur-DNS estas la enuiga respondo, kiu funkcias, kaj ĝi estas tiu, al kiu oni unue turnu sin.

Unu maŝino ankoraŭ bezonas du aŭskultantojn

Apartaj nomoj ne permesas al du procezoj ligi la saman adreson, havenon kaj transporton samtempe. Se la reta servilo jam tenas TCP 443 sur ĉiuj adresoj, OpenVPN-ekzemplero ne povas ankaŭ preni ĝin sen intenca aranĝo.

Ligu la VPN-aŭskultanton al alia haveno, aŭ al alia adreso, aŭ metu dokumentitan multipliksilon antaŭe kaj akceptu la funkcian koston, kiu venas kun ĝi. Ĉiu el tiuj elektoj devus esti videbla en la fajroŝirmaj reguloj, ĉar aŭskultanto, kiun neniu dokumentis, estas tiu, kiu maltrafiĝas dum incidento. Skribu la elektitan ligon en la sama runlibro, kiu priskribas la tunelon. Tiam la sekva persono ne remalkovros ĝin je la dua matene.

Atestiloj sekvas la konekton, kiun ili protektas

La TLS-konekto de la retumilo al Cloudflare kaj la konekto de Cloudflare al via origino estas du apartaj rilatoj kun du apartaj atestiloj. La retumilo vidas randan atestilon. La origino prezentas sian propran atestilon al Cloudflare, kaj Cloudflare Origin CA-atestilo estas destinita ĝuste por tiu dua rilato.

Tiun originan atestilon Cloudflare fidas en la reĝimo Full (strict) kaj ĝi ne estas ĝenerale fidinda retumila atestilo. Se iu vizitas la nur-DNS gastigantan nomon rekte kaj ricevas averton, tio estas la atendata sekvo de ŝanĝita fido-vojo, ne pruvo, ke ĉifrado haltis.

Retejo vizitata rekte do bezonas atestilan ĉenon, kiun ĝiaj retumiloj fidas. Tio povas kunekzisti kun prokurita retejo, kies origino tute ne estas destinita por vizitado.

OpenVPN portas sian propran servilan identecon kaj klientan aŭtentikigon, kun sia propra atestila aŭtoritato kaj sia propra protekto de la rega kanalo. Seruro sur la retejo provizas neniom da tio, kaj la du provizaj procezoj devus resti apartaj.

Ekspozicio sekvas la nomon

VPN-rikordo nur-DNS publikigas la adreson, al kiu ĝi montras. Se tiu adreso ankaŭ estas la reta origino, la origino ne estas kaŝita, kaj priskribi ĝin kiel kaŝitan ĉar la alia nomo estas prokurita estas eraro, kiu daŭras ĝis iu skanas por ĝi.

Decidu, kiuj retaj petoj rajtas atingi la originon rekte, kaj plenumu tion ĉe la origino, poste permesu la VPN-aŭskultanton laŭ ĝiaj propraj kondiĉoj. Administraj paĝoj, profilaj elŝutoj kaj la data aŭskultanto povas havi tri malsamajn ekspoziciajn postulojn eĉ kiam unu pakaĵo provizas ĉiujn tri.

Konservu generitajn ligilojn sur la publika reta nomo kaj la HTTPS-skemo, kaj konservu klientajn profilojn sur la VPN-nomo kun la reala protokolo kaj haveno. Neniu el la du servoj devus dependi de ŝanĝado de la prokurila agordo de la alia dum normala funkciado.

Laborordo: prokurita nomo por la retejo, nur-DNS nomo por la VPN, apartaj aŭskultantoj, atestilo por ĉiu rilato, poste unu testo, kiu pruvas, ke ĉiu nomo atingas nur la servon, kiun ĝi devas.