OpenVPN at HTTPS sa port 443: kanino ang listener?
Magkaibang socket ang TCP at UDP 443. Ang pagbabahagi ng isang TCP listener ay nangangailangan ng may-ari, at ang pagbabahagi ng port ng OpenVPN ay makitid na kasunduan, hindi trick ng proxy.
Dalawang serbisyo ang parehong makakasagot sa port 443 nang hindi kailanman nagkakumpitensya, dahil ang listener ay tinutukoy ng transport, address at port nang magkasama, hindi ng numero lamang. Maglagay ng web server at OpenVPN sa isang makina, at ang tanging tanong na dapat sagutin muna ay kung aling socket ang hinihingi ng bawat proseso sa kernel. Isulat ang listahang iyon bago mag-edit ng configuration, at ang karamihan ng error na «ginagamit na ang address» ay nagpapaliwanag sa sarili nito. Lahat ng sumusunod sa listahan ay pagpili sa pagitan ng UDP listener, pinagsasaluhang TCP socket o front end na nagruruta ayon sa protocol.
Magsimula sa socket na hinihingi ng bawat proseso
Ang bind ay nagtatagumpay o nabibigo sa triple na iyon, kaya dalawang daemon ang nagbabanggaan lamang kapag nagtutugma ang lahat ng tatlong bahagi. Ito ang dahilan kung bakit ang isang website sa TCP 443 ay walang hanggang kasamang umiiral sa isang OpenVPN listener sa UDP 443, at ito rin ang dahilan kung bakit ang paglilipat ng isa sa kanila sa ikalawang lokal na address sa parehong host ay nagtatapos din sa debate. Basahin ang mga buhay na listener, hindi ang mga file na dapat ay gumawa sa kanila, dahil ang lumang include o nakalimutang unit file ay nabubuhay nang mas matagal kaysa sa edit na natatandaan mong ginawa mo.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Patakbuhin ang ss -lntup bilang root at basahin ang bawat linyang nagbabanggit ng 443, kasama ang mga entry na IPv6. Karaniwang tumatanggap din ang wildcard listener para sa v6 ng trapikong v4, at ganoon kung paano pinananatiling okupado ng nakalimutang listener ang port pagkatapos mong baguhin ang file na inaakala mong responsable. Kung ang pangalan ng proseso ay nagulat sa iyo, paliitin ang output gamit ang ss -lntup 'sport = :443' bago hawakan ang anuman.
Ilipat ang tunnel sa UDP kapag pinapayagan ng network
Ang UDP listener ay lumalampas sa banggaan nang buo at karaniwang ito ang pinakamaikling pag-aayos, dahil walang socket na pinagsasaluhan at walang karagdagang produkto ang pumapasok sa landas. Ngunit hindi ito libre. Itinatapon ng ilang network ng kliyente ang UDP 443 nang walang reset, kaya tumitigil ang tunnel sa pagtatatag sa halip na mabigo sa bind, at iniuulat ng user na patay ang VPN nang walang error na mababasa. Nakakaligtas din ang UDP listener sa restart ng web layer, na mahalaga sa makinang madalas i-deploy muli ang site. Subukan mula sa network kung saan nakaupo ang mga user, dahil ang shell sa server ay nagpapatunay lamang na naaabot ng server ang sarili nito.
Baguhin ang transport sa configuration ng server at sa profile ng kliyente nang sabay. Ang profile na humihingi pa ng TCP ay iikot sa mga cycle ng muling pagkonekta laban sa listener na UDP lamang, at mukhang sira ng network iyon hanggang ihambing mo ang dalawang file.
Hayaang pagmamay-arian ng proseso ng VPN ang TCP 443 at ipasa ang iba pa
Ang Community OpenVPN sa TCP server mode ay nagbabasa ng mga unang byte ng papasok na koneksyon at ipinapasa ang lahat ng hindi sariling protocol sa isang HTTPS backend, at iyon ang gamit ng direktibang port-share. Ang backend ay ordinaryong web server na may TLS na naka-enable, pinangalanan ayon sa host at port sa direktibang iyon at hindi ayon sa URL.
port-share 10.0.0.5 8080
Sa makinang may ikalawang pribadong address ang site, ipinapadala ng linyang iyon ang trapikong hindi VPN sa 10.0.0.5:8080, kaya ang virtual host ng HTTPS ay dapat nakabitin doon at dapat pahintulutan ng firewall ang lokal na pagtalon. Kailangang tapusin ng web server ang TLS mismo, dahil ang mga byte na dumarating ay orihinal na handshake ng browser at walang nag-decrypt sa mga ito sa pagitan. Itutok ang direktiba sa ordinaryong HTTP listener at makakakuha ang browser ng error sa di-wastong method, na binabasa na parang sirang site kaysa backend na maling nakalagay. Umiiral lamang ang direktiba sa TCP server mode, at walang stream na masisiyasat ang UDP listener.
Dahil tinatanggap ng proseso ng VPN ang bawat koneksyon, nakikita ng web application na ang ipinasang kahilingan ay dumarating mula sa isa sa mga address ng host mismo kaysa sa bisita. Ang lahat ng nangangailangan ng tunay na address ng kliyente ay nakasalalay sa suporta ng protocol na PROXY sa backend o sa front end na nagdaragdag nito. Ang paglilipat ng backend sa ibang lokal na address ay hindi nagbabalik ng address ng bisita; binabago lamang nito kung alin sa mga address ng host ang itinatala ng site. Isulat ang limitasyong iyon sa mga tala ng deployment bago magtanong ang isang ulat ng analytics.
Ang reverse proxy ay maling kasangkapan; ang layer-four router ay hindi
Ang HTTP reverse proxy ay nagtatapos ng TLS upang makabasa ng mga kahilingan, na nangangahulugang hindi nito maipapasa ang isang OpenVPN stream nang hindi nahahawakan. Ang layer-four router na nagpapasa ayon sa SNI o ayon sa inspeksyon ng unang packet ay maaaring tumayo sa harap ng dalawa, sa kondisyon na hindi nito tinatapos ang session na umaasa ang VPN. Magkahawig ang dalawang device sa diagram at lubos na magkaiba ang kilos sa socket.
Ang komersyal na Access Server ay may sariling mga setting ng pagbabahagi ng port, at hindi ito tumutugma nang isa-sa-isa sa direktiba ng komunidad. Tukuyin ang produkto at bersyon bago iangkop ang gabay na isinulat para sa isa pa. Ang kinopyang setting na tahimik na binabalewala ay mas masama kaysa walang setting, dahil mukhang kapani-paniwala pa rin ang listahan ng listener pagkatapos.
Subukan ang website at ang tunnel bilang dalawang hiwalay na landas
I-load ang site at ikonekta ang tunnel, pagkatapos ay basahin muli ang listahan ng listener upang makita kung aling proseso ang nagmamay-ari ng 443 ngayon. Ang page na naglo-load ay walang pinapatunayan tungkol sa VPN, at ang tunnel na kumokonekta ay walang pinapatunayan tungkol sa site, kahit pareho silang gumagamit ng parehong numero. Sinusuri ng tatlong utos sa ibaba ang pinagsasaluhang socket, ang web path at ang serbisyo ng VPN sa ganoong pagkakasunod-sunod.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Ihambing ang address ng kliyente sa access log ng backend sa nasa VPN log para sa parehong sandali. Kung itinatala ng site ang bawat bisita bilang ang host mismo, gumagana ang pagpapasa at hindi gumagana ang paghawak ng address. Kung tahimik ang dalawang log, hindi kailanman isinuko ng front end ang koneksyon. Alinman sa dalawa, ang listahan ng listener ang nagpapasya kung sino ang tumatanggap ng socket, at iyon ang katotohanang kailangang kumpirmahin bago ka magbago ng isa pang file.
Iwanan ang mapa ng listener na iyon sa tabi ng configuration upang malaman ng susunod na taong humawak sa 443 kung aling proseso ang tumatanggap at saan napunta ang isa pang protocol. Kumpirmahin ang pagmamay-ari pagkatapos ng pagbabago kaysa magtiwala sa kung ano ang dapat gawin ng edit.