Hindi laging mas mabilis ang UDP: pagpili ng transport ng OpenVPN

Sinasabi ng bawat gabay na mas maganda ang UDP kaysa TCP para sa OpenVPN, at ang payong iyon ay default, hindi pagsukat. Binabago ng transport kung paano inihahatid ang mga packet at ano ang nangyayari kapag itinapon sila ng landas, hindi kung paano ini-encrypt ang tunel. Sa likod ng captive portal o proxy na pinapayagan lamang ang port 443, ang mas mabagal na opsyon ang siyang kumokonekta man lang. Ang sumusunod ay naghihiwalay sa ginagawa ng protocol at sa pinapayagan ng iyong access network.

Ano ang tunay na binabago ng transport

Naghahatid ang TCP ng maaasahan at maayos na byte stream at muling nagpapadala ng lahat ng nawawala, gaya ng itinakda ng RFC 9293. Ipinapasa ng UDP ang mga datagram sa network, at pinapatakbo ng OpenVPN ang sarili nitong layer ng pagiging maaasahan sa socket na iyon. Ang pag-encapsulate ng TCP sa loob ng TCP ay nagpapatong ng dalawang recovery loop, kaya ang isang nawalang segment ay makapipigil sa panloob na stream hanggang dumating ang panlabas na retransmission. Ang interaksyong iyon ang tunay na argumento para sa UDP, at lumilitaw ito bilang latency at hindi bilang throughput.

Lumalaki ang epekto sa pagkawala at oras ng pagpunta't pagbalik. Sa malinis na lokal na landas, magkapareho ang pakiramdam ng dalawang transport, kaya bihirang maulit ng pagsubok sa laboratoryo ang reklamo. Sa masikip na mobile link, makikita ang pagkakaiba sa mga interactive na session bago pa man may mapansin ang malaking transfer.

Wala sa mga ito ang humahawak sa pagiging kompidensyal o integridad. Ang TLS handshake at ang cipher ng data channel ay pareho para sa dalawang transport, kaya hindi maililigtas ng paglipat ang mahinang cipher suite.

Saan nakakamit ng TCP ang lugar nito

Ang mga access network ang karaniwang dahilan upang piliin ang TCP. Maaaring payagan ng hotel, paliparan o guest network ang palabas na 443 at itapon ang lahat ng iba, at ang TCP listener sa port na iyon ang tanging profile na gumagana. Iyon ay abot, hindi performance, at sapat na magandang dahilan sa sarili nito.

Nakakatulong din ang TCP kapag matatag ang landas pero pagalit ang mga middlebox. Nirereset ng ilang network ang pangmatagalang UDP flow habang pinapayagan ang TCP session na mukhang ordinaryong web traffic. Kung magtatagumpay ang pagkakahawig na iyon ay katangian ng partikular na network, at walang gabay ang makapangangako nito para sa lahat. Subukan sa loob ng network na nabibigo bago sisihin ang protocol.

Ang tinanggihang pag-login ay hindi problema sa transport. Ang pag-disable ng verification ng certificate upang pilitin ang koneksyon ay ibang pagbabago na may mas malubhang resulta.

Ang paghahanda ng TCP profile ang praktikal na kompromiso. Karamihan ng kliyente ay nag-iimbak ng dalawa at hinahayaan kang lumipat kapag tinanggihan ng network ang UDP na landas, na walang gastos hanggang kailanganin mo. Ang hindi mo dapat gawin ay magpadala ng dalawang profile na tumuturo sa magkaibang endpoint, dahil ang paghahambing mo ay sumusukat sa mga server.

Tingnan kung aling tagapakinig ang talagang mayroon ka

Bago ihambing ang performance, tiyakin na magkasundo ang dalawang dulo sa transport at port. Ang pagpapalit ng proto udp sa proto tcp sa file ng kliyente ay hindi gumagawa ng server listener. Dapat na naka-configure ang server para sa protocol na iyon, at dapat tumugma ang profile dito.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

Ipinapakita ng grep kung ano ang sinabihan sa server na gamitin, habang ang dalawang listahan ng socket ay nagpapakita kung ano ang nakakabit dito. Ang UDP listener ay lumilitaw lamang sa unang listahan at ang TCP listener lamang sa pangalawa, kaya ang nawawalang linya ang pinakamabilis na paraan upang makahanap ng profile na hindi kailanman naipatupad. Ihambing din ang port, dahil ang TCP profile sa 1194 ay kumikilos nang iba kaysa sa nasa 443 sa karamihan ng access network. I-restart ang serbisyo pagkatapos ng pagbabago at basahin ang log line na nag-uulat ng binding.

Mura ang kumpirmasyon sa panig ng kliyente: patakbuhin ang koneksyon gamit ang --verb 4 at basahin ang transport line sa log. Kung sinasabi ng kliyente na UDP habang nakikinig ang server sa TCP, hindi kailanman nagsisimula ang handshake at walang tuning ang makakatulong.

Ihambing ang workload, hindi ang label ng transport

Ang patas na paghahambing ay nagpapanatili ng lahat maliban sa transport. Parehong device, parehong access network, parehong destinasyong host, parehong application at, sa pinakamainam, parehong server. Kung ang dalawang profile ay tumuturo sa magkaibang host, sinusukat mo rin ang mga host na iyon.

Itala ang tatlong resulta sa bawat pagtakbo: kung nabubuo ang tunel, kung nananatili ito, at kung natatapos ang gawain. Ang maliliit na kahilingan na gumagana habang natigil ang malalaking transfer ay tumuturo sa laki ng packet at MTU, hindi sa transport. Ang paulit-ulit na muling pagkonekta ay tumuturo sa landas o sa timeout ng isang middlebox.

Itago ang profile na gumagana sa mga kundisyong aktuwal mong nararanasan, at itabi ang isa. Pag-aari ng network ang pagpili, hindi ng tao, kaya anumang nag-iisang default na sagot ay mali sa isang lugar.