Bakit hindi maaaring magdala ang proxy ng Cloudflare ng OpenVPN sa isang pangalan

Isang makina ang nagpapatakbo ng website at ng OpenVPN server, at ang tukso ay ituro ang isang hostname dito at hayaang ayusin ng orange na ulap ang trapiko. Inaayos ng proxy ang HTTP at HTTPS. Hindi nito inaayos ang isang sesyon ng OpenVPN, anuman ang port na gamitin ng sesyong iyon. Dalawang pangalan, isang direkta at isang sa pamamagitan ng proxy, ay walang gastos at inaalis ang buong uri ng kalituhan.

Dalawang pangalan, dalawang transportasyon

Bigyan ang website ng rekord na may proxy upang dumaan sa Cloudflare ang trapiko nitong HTTP at HTTPS. Bigyan ang VPN ng rekord na DNS lamang na tumutugon nang direkta sa pampublikong pasukan ng VPN, at hayaang gamitin ng kliyente ang port na UDP o TCP na inayos para dito.

Maaaring parehong mapunta ang dalawang pangalan sa iisang pinagmulang makina. Ang pagkakaiba ay ang nangyayari sa pagitan ng kliyente at ng makinang iyon, at ang pagkakaibang iyon ang layunin ng paghahati.

Inililista ng sanggunian sa mga port ng network ng Cloudflare kung aling mga port ang tinatanggap ng karaniwang web proxy. Ang listahang iyon ay tungkol sa HTTP at HTTPS sa mga port na iyon, hindi sa mga arbitraryong protocol na nagkataong nagbabahagi ng isang numero.

Ang port ay hindi ang protocol

Ang ilipat ang OpenVPN sa TCP 443 ay hindi ito ginagawang HTTPS. Umiiral pa rin ang proxy ng isang kahilingang HTTP sa simula ng koneksyon, at ang kliyente ng OpenVPN ay nagpapadala sa halip ng isang binary na kontrol na mensahe. Nabibigo ang koneksyon sa paraang mukhang hadlang sa network dahil walang kapaki-pakinabang na naabot ang log.

Kung ang pangangailangan ay talagang ilagay ang isang produkto ng Cloudflare sa landas ng data ng VPN, suriin ang isang produktong may dokumentadong suporta sa protocol na kailangan mo. Huwag ipagpalagay na ang orange na ulap ay isang pangkalahatang TCP o UDP tunnel, dahil ito ay isang reverse proxy para sa trapiko ng web na may tiyak na gawain.

Ang rekord na DNS lamang ang nakakainip na sagot na gumagana, at ito ang unang dapat abutin.

Kailangan pa rin ng isang makina ang dalawang tagapakinig

Ang magkahiwalay na pangalan ay hindi nagpapahintulot sa dalawang proseso na bigkisin ang parehong address, port at transportasyon nang sabay. Kung hawak na ng web server ang TCP 443 sa lahat ng address, hindi rin ito maaaring kunin ng isang instance ng OpenVPN nang walang sadyang pag-aayos.

Itali ang tagapakinig ng VPN sa ibang port, o sa ibang address, o maglagay ng dokumentadong multiplexer sa harap at tanggapin ang gastos sa operasyon na kasama nito. Ang bawat isa sa mga pagpipiliang iyon ay dapat makita sa mga tuntunin ng firewall, dahil ang tagapakinig na walang nagdokumento ay siyang napapabayaan kapag may insidente. Isulat ang piniling pagtali sa parehong runbook na naglalarawan ng tunnel. Pagkatapos ay hindi na ito muling matutuklasan ng susunod na tao alas-dos ng madaling-araw.

Sinusundan ng mga sertipiko ang koneksyong pinoprotektahan nila

Ang TLS na koneksyon ng browser sa Cloudflare at ang koneksyon ng Cloudflare sa iyong pinagmulan ay dalawang hiwalay na ugnayan na may dalawang hiwalay na sertipiko. Nakikita ng browser ang isang sertipiko sa gilid. Ipinapakita ng pinagmulan ang sarili nitong sertipiko sa Cloudflare, at ang sertipiko ng Cloudflare Origin CA ay para mismo sa ikalawang ugnayang iyon.

Ang sertipikong iyon ng pinagmulan ay pinagkakatiwalaan ng Cloudflare sa mode na Full (strict) at hindi ito isang sertipiko ng browser na pinagkakatiwalaan sa pangkalahatan. Kung may bumisita nang direkta sa hostname na DNS lamang at nakatanggap ng babala, iyon ang inaasahang bunga ng nabagong landas ng pagtitiwala, hindi patunay na huminto ang pag-encrypt.

Kaya ang isang website na binibisita nang direkta ay nangangailangan ng kadena ng mga sertipiko na pinagkakatiwalaan ng mga browser nito. Maaari iyon mamalagi kasama ng isang site na may proxy na ang pinagmulan ay hindi talaga nilalayong bisitahin.

Dinadala ng OpenVPN ang sarili nitong pagkakakilanlan ng server at pagpapatunay ng kliyente, kasama ang sarili nitong awtoridad sa sertipiko at sarili nitong proteksyon ng control channel. Ang kandado sa website ay walang ibinibigay sa mga iyon, at ang dalawang proseso ng paghahanda ay dapat manatiling hiwalay.

Sinusundan ng paglalantad ang pangalan

Ang rekord ng VPN na DNS lamang ay naglalathala ng address na tinutukoy nito. Kung ang address na iyon ay pinagmulan din ng web, hindi nakatago ang pinagmulan, at ang ilarawan ito bilang nakatago dahil ang ibang pangalan ay may proxy ay isang pagkakamaling nananatili hanggang may mag-scan para dito.

Magpasya kung aling mga kahilingan sa web ang maaaring direktang umabot sa pinagmulan at ipatupad iyon sa pinagmulan, pagkatapos ay payagan ang tagapakinig ng VPN sa sarili nitong mga tuntunin. Ang mga pahina ng pamamahala, pag-download ng profile at tagapakinig ng data ay maaaring may tatlong magkakaibang pangangailangan sa paglalantad kahit na isang pakete lang ang nagbibigay ng tatlo.

Panatilihin ang mga nabuong link sa pampublikong pangalan ng web at scheme na HTTPS, at panatilihin ang mga profile ng kliyente sa pangalan ng VPN kasama ang tunay na protocol at port. Ni isa sa dalawang serbisyo ay hindi dapat umasa sa pagbabaliktad ng setting ng proxy ng isa pa sa normal na operasyon.

Pagkakasunod-sunod ng gawain: pangalang may proxy para sa site, pangalang DNS lamang para sa VPN, magkahiwalay na tagapakinig, sertipiko bawat ugnayan, at pagkatapos ay isang pagsubok na nagpapatunay na ang bawat pangalan ay umabot lamang sa serbisyong dapat nitong abutin.