Nakakatulong nga ba ang TCP 443? Kung ang server ay nakikinig doon
Ang profile ng TCP ay isang alternatibong ruta, hindi isang pagbabalatkayo. Tiyakin na nakikinig ang server sa port na iyon, pagkatapos timbangin ang gastos ng dobleng TCP laban sa hindi maabot.
Ang TCP 443 ay isang alternatibong ruta na may paunang kondisyon, hindi isang pagbabalatkayo na nagpapalusot ng tunel sa anumang filter. Nakakatulong ito kapag ang operator ay naglalathala na ng tagapakinig ng TCP sa port na iyon at ang ruta ay tumatagal ng koneksiyon na nananatiling bukas nang maraming oras. Nabibigo ito, karaniwang bilang timeout, kapag kulang ang isa sa dalawa, at bihirang sabihin ng timeout kung alin. Ang pagpapasya kung lilipat ay nangangailangan ng tatlong tanong, at isa lamang sa kanila ang tungkol sa numero ng port.
Ang numero ng port ay hindi pangako ng transportasyon
Pinangalanan ng port ang isang dulo; ginagawa itong ng TCP na maayos na daloy ng byte; ang OpenVPN ang nagpapasya kung ano ang bumibiyahe sa loob ng daloy na iyon. Ang web server sa parehong numero ay gumagamit ng lubos na ibang kaayusan ng aplikasyon, kaya ang pagbabahagi ng port 443 ay nagpapamukha sa dalawa na magkapareho sa isang filter at wala nang iba. Ang numero ay isang palatandaan na binabasa ng filter, hindi isang katangiang nagbabago ng nilalaman ng mga packet. Ang ituring silang pareho dahil nagbabahagi sila ng port ay ang pagkakamaling nasa likod ng karamihan ng kalituhan dito.
Bihirang gumawa ng simpleng desisyon ng payagan-o-pigilan ang mga intermediate na aparato tungkol sa isang port. Marami ang sumusuri sa mga unang byte, ang ilan ay nagpapako ng destinasyon, at ang iba ay nire-reset ang mga koneksiyong nananatiling bukas nang masyadong matagal. Iyon ang dahilan kung bakit ang parehong profile ay maaaring gumana mula sa isang network at mag-timeout mula sa iba, at iyon ang dahilan kung bakit ang alternatibong ruta ay dapat subukan bilang suportadong opsiyon sa halip na pagkatiwalaan bilang pangako. Kapag sinuri ng filter ang trapiko, ang numero ng port ay ang unang bagay lamang na tinitingnan nito.
Tiyakin ang tagapakinig bago hawakan ang profile
Dapat na naka-configure ang server para sa TCP sa port, at dapat hilingin ng profile ng kliyente ang parehong transportasyon. Ang pagsulat muli ng profile ng UDP upang humiling ng TCP ay hindi lumilikha ng tagapakinig, at ang resultang timeout ay hindi makikilala mula sa firewall na nagtatapon ng port. I-download ang sariling profile ng TCP ng operator kapag mayroon, dahil ang ilang serbisyo ay naglalathala ng hiwalay na dulo at hiwalay na mga setting ng pagkakakilanlan para sa bawat transportasyon. Ang manu-manong pag-edit ay mabuti para sa kontroladong pagsubok at masamang paraan upang hulaan ang sinadya ng provider.
Ang dalawang panig ng tugmang iyon ay lumilitaw sa configuration, at ang mga opsiyon ng link ng proyektong OpenVPN ay nagtatala ng parehong anyo. Ganito ang hitsura ng pinakamaliit na pares:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443Tatlong kundisyon ang nagpapasya kung sulit ang alternatibong ruta
Ang unang kundisyon ay ang operator ay nag-aalok ng transportasyong iyon talaga; kung wala iyon, wala nang ibang mahalaga. Ang pangalawa ay ang ruta ay nagpapanatiling buhay ng pangmatagalang sesyon, dahil ang ilang network ay nire-reset ang mga koneksiyong nananatiling bukas sa halip na harangin ang port nang tuluyan. Ang pangatlo ay kung ang alternatibong ruta ay sinadyang eksepsiyon o pansamantalang solusyon na nagtatakip ng depektong hindi mo pa naayos.
Bawat kundisyon ay may murang pagsusuri. Ang kabiguan sa alinman sa mga ito ay pareho ang hitsura mula sa kliyente:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
Bago ihambing ang mga transportasyon, tapusin ang anumang pag-sign in sa captive portal. Ang network na hindi tumanggap sa iyong aparato ay humaharang sa dalawang transportasyon, at ang paghahambing ay sumusukat noon sa portal at hindi sa tunel. Mag-sign in, tiyakin na gumagana ang karaniwang pag-browse, at pagkatapos lamang simulan ang pagsubok.
Ang gastos na tinatanggap mo: TCP sa loob ng TCP
Muling ipinapadala ng TCP ang mga nawalang segment at pinapanatili ang kanilang pagkakasunod-sunod. Kapag ang isang aplikasyon na gumagamit din ng TCP ay tumatakbo sa loob ng tunel ng TCP, dalawang patong ng pagbawi ang tumutugon sa parehong pagkawala, at ang interaksiyon na iyon ang nagpaparamdam ng bagal ng tunel sa rutang may pagkawala. Ang sintomas ay pagkaantala at jitter sa halip na malinaw na kabiguan, na nagpapadali sa pagsisi sa malayong dulo. Sukatin mula sa kliyente sa dalawang transportasyon bago maghinuha.
Iniiwasan ng UDP ang nesting na ito, at iyon ang pangunahing dahilan kung bakit ginusto ito ng mga operator at inaalok lamang ang TCP bilang alternatibo. Ang matatag na koneksiyong TCP ay mas kapaki-pakinabang pa rin kaysa sa UDP na hindi maabot, kaya ang paghahambing ay sa pagitan ng dalawang tunay na gastos at hindi sa pagitan ng mabuti at masamang opsiyon. Panatilihing hindi nagbabago ang aparato at ang access network habang naghahambing, kung hindi ay mali ang variable na ilalarawan ng resulta.
Ang ilang katangian ng kliyente ay naidokumento para sa isang transportasyon lamang, kaya ang alternatibong profile ay maaaring tahimik na magtanggal ng pag-uugaling inaasahan mo. Basahin ang kinakailangan ng transportasyon ng opsiyon bago ituring ang profile ng TCP na simpleng pagpapalit.
Mga depektong hindi ginalaw ng ibang transportasyon
Ang nag-expire na sertipiko ay kailangan pa rin ng pagsusuri ng orasan o pag-renew, at ang tinanggihang account ay kailangan pa rin ng tamang kredensyal. Panatilihin ang mga pagsusuri ng pagkakakilanlan ng server na ibinigay ng operator, dahil ang pamilyar na numero ng port ay hindi nagpapatunay ng sinuman. Ang port na tumutugon ay nagsasabi lamang na may nakikinig.
Kung umangat ang tunel at nabibigo pa rin ang mga destinasyon, ang natitirang problema ay ang routing o paglutas ng pangalan pagkatapos ng koneksiyon, hindi ang transportasyon. Sundin ang rutang iyon sa halip na paikutin ang mga port, dahil ganoon nawawala ang isang hapon. Sinasabi ng profile kung aling transportasyon ang susubukan; hindi nito kailanman sinasabi kung bakit nabigo ang rutang UDP.