proto udp o tcp-client: alin ang naririnig ng iyong server?

Isang profile na gumana noong nakaraang buwan ang nag-time out ngayon, at may nagmumungkahing palitan ang proto udp ng proto tcp-client. Minsan iyon ang tamang hakbang, minsan gumagawa ito ng client na kumokonekta sa isang port kung saan walang nakikinig, dahil hindi kailanman na-configure ang server para sa kabilang transport. Inilalarawan ng direktiba kung paano nagsasalita ang iyong panig; hindi ito makakagawa ng tagapakinig sa kabilang dulo. Basahin ang profile at ang server nang sabay bago baguhin ang alinman sa kanila.

Basahin ang transport na ginagamit ng napiling koneksyon

Maaaring magdala ang isang profile ng ilang entry na remote, at bawat isa ay maaaring magbanggit ng sarili nitong transport. Pinoproseso ng client ang mga ito nang sunud-sunod, kaya ang linyang una mong nakikita ay hindi kinakailangang iyon ang naaangkop.

Hanapin ang entry na talagang sinusubukan, pagkatapos basahin ang transport nito. Mahalaga ang pagkakasunod-sunod, dahil hindi tahimik na lumilipat ang client sa susunod. Sinusubukan ng ilang build ang susunod na entry pagkatapos lamang ng timeout, kaya ang gumaganang alternatibo sa ilalim ng file ay naaabot nang mas huli nang ilang segundo kaysa inaasahan mo. Panoorin sa log kung aling endpoint ang sinusubukan sa halip na ipagpalagay na nanalo ang unang linya.

Kung ang file ay may isang linyang proto malapit sa itaas at ilang entry na remote sa ilalim nito, ang linyang iyon ang default para sa anumang remote na hindi ito nalalabuan. Ang lokal na pag-edit ng default ay walang ginagawa para sa isang entry na remote na nagbanggit ng sarili nitong transport.

grep -nE '^(remote|proto)\b' client.ovpn

Ang UDP at TCP ay hindi setting ng bilis

Nagpapadala ang UDP ng datagram nang walang itinayong pagkakasunod-sunod na stream, kaya ang trapiko ng tunnel mismo ay hindi nababalot sa pangalawang maaasahang transport. Binibigyan ka ng TCP ng daan sa mga network na nagtatapon o humaharang sa UDP, kapalit ng naka-nest na muling pagpapadala na maaaring magpalala ng pakiramdam sa isang link na may pagkalugi.

Ito ay palitan sa maabot, hindi isang pandaigdigang ranggo. Ang tamang pagpili ay iyon na pinahihintulutan ng network sa harap ng client. Ang daang nagtatapon ng UDP sa port ng VPN ay hindi kailanman makikipag-ayos, gaano man kahusay ang pagkakasulat ng profile. Subukan ang daan, pagkatapos piliin ang transport.

Ang pagpili sa pagitan ng mga ito batay lamang sa pagsukat ay isang pagkakamali, dahil ang sagot ay nakasalalay sa pinahihintulutan ng network sa harap mo. Maaaring payagan ng isang hotel o corporate proxy ang papalabas na TCP sa 443 at wala nang iba, kaya iniaalok ng mga provider ang variant na iyon. Nananatili itong koneksyong OpenVPN sa port na iyon, hindi isang sesyon ng HTTPS, kahit pamilyar ang numero ng port.

Ano ba talaga ang ibig sabihin ng tcp-client

Pinangalanan ng direktiba sa panig ng client ang dulong nagsisimula ng koneksyon ng TCP. Ginagamit ng panig ng server ang sarili nitong anyo ng pakikinig, at ang pagkopya ng salita ng client sa isang configuration ng server ay gumagawa ng tagapakinig na naghihintay na tawagan, hindi isang tumatanggap.

Ang pagtutugma ay nangangahulugang nagkasundo ang dalawang dulo sa transport, hindi na nagbabahagi sila ng parehong string.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Tanungin ang server kung ano ang pinakikinggan nito bago ipagpalagay na mali ang profile. Ang tagapakinig na UDP ay hindi lumalabas sa isang listahan ng socket ng TCP, at totoo rin ang kabaligtaran, kaya tingnan ang pananaw na partikular sa protocol sa halip na isang pangkalahatan.

Kapag na-import ang profile ngunit hindi kailanman kumokonekta

Ang na-import na profile na agad na nag-time out ay karaniwang nabibigo bago pa ang anumang pagpapatotoo. Pumupunta ang packet sa isang port na walang tagapakinig, o tahimik itong tinatapon ng network.

Subukan ang daan sa pinakasimpleng paraan: kumonekta sa parehong host at port gamit ang transport na inaangkin ng profile, mula sa parehong network ng client na nabibigo.

Kung walang nakuha ang pagsubok na UDP at kumonekta ang pagsubok na TCP, iniaalok ng server ang kabilang transport at luma na lamang ang profile. Kung wala sa dalawa ang tumugon, nasa itaas ng pagpili ng transport ang problema at walang pag-edit ng profile ang makakatama nito. Ang pagkakaiba ng dalawang kasong ito ay tumatagal ng isang minuto at nakakatipid ng isang oras ng pag-debug ng sertipiko na hindi kailanman naging mahalaga.

Itala ang gumaganang transport

Kapag gumana ang isang kombinasyon, isulat ito kasama ng server, port at protocol, at tandaan kung saang network ito sinubukan.

Kung hindi, uulitin ng susunod na taong makakatagpo ng timeout ang parehong eksperimento sa kabilang direksyon, at maaaring baguhin ang isang server na maayos naman.

Kung inilalathala ng provider ang parehong variant, itago ang parehong file at lagyan ng label ayon sa network na angkop para sa mga ito. Dalawang profile na may malinaw na pangalan ang pumipigil sa aksidenteng paghahalo ng transport ng client sa isang tagapakinig ng server na hindi kailanman na-configure para dito.