Pag-timeout ng koneksyon sa VPN: DNS, transport, negosasyon o pag-log in
Ang timeout ay nangangahulugang lumipas lamang ang isang deadline. Ihambing ang apat na yugto, paglutas ng pangalan, transport, negosasyon at pag-log in, para makita kung alin ang huling natapos.
“Nag-timeout ang koneksyon” ang pinakamalabong error na maaaring i-print ng isang VPN client. Ibig sabihin, may isang operasyong lumampas sa deadline nito, at bawat yugto mula sa paglutas ng pangalan hanggang sa sagot ng pag-log in ay may deadline. Ang mga client na nagpapakita lamang ng huling mensahe ay ginagawang magkapareho ang mga yugto, kaya pinapataas ng mga tao ang timeout, pinapalitan ang port at ini-install muli ang profile, sa ganoong pagkakasunod-sunod, nang walang natututuhan. Mas mabilis ang paghahambing ng mga yugto: bawat isa ay nabigo sa ibang lugar, at bawat kabiguan ay nag-iiwan ng ibang uri ng ebidensiya.
Apat na yugto, apat na magkaibang kabiguan
Ang pagkakasunod-sunod ay pirmihan kahit itinatago ito ng client: dapat lutasin ang pangalan, dapat magtatag ng transport patungo sa resultang address, dapat makipagnegosasyon ang protocol sa mga parameter at key nito, at dapat ma-authenticate ang account. Ang gabay ng OpenVPN sa pag-troubleshoot ng koneksyon ay sumusunod sa parehong pagkakasunod-sunod para sa sarili nitong client, at malapit itong sinusundan ng iba. Ang timeout sa ikalawang yugto at sa ikaapat ay walang pagkakatulad maliban sa salita sa screen.
| Stage | Looks like | What it does not prove |
|---|---|---|
| Name resolution | fails in under a second, before any contact | nothing about the server being up |
| Transport | waits the full timeout, then gives up | nothing about the VPN service behind the port |
| Negotiation | connects, then stalls at handshake | nothing about credentials |
| Login | a reply arrives and is rejected or hangs on a prompt | nothing about reachability |
Basahin ang log para sa huling linyang nagpapakita ng pag-usad, hindi ang huling linya bago ang error. Karamihan sa mga client ay nagpi-print ng tulad ng naresolbang address, naitatag na socket, nasimulang handshake o kahilingan sa authentication, at ang yugtong kasunod ng linyang iyon ang nag-timeout.
Nabibigo ang paglutas ng pangalan bago pa makipag-ugnayan sa anuman
Kung hindi kailanman naresolba ang endpoint, walang maidudugtong ang client at walang transport work na nangyari. Ang kabiguan na iyon ay karaniwang agaran kaysa buong timeout, at iyon ang pinakamurang paraan para maiba ito sa iba. Subukan ang pangalan sa resolver ng system at sa pangalawang resolver, at ihambing ang dalawang sagot bago magpasya na down ang server.
Ang lumang address na kinopya mula sa post sa forum ay karaniwang sanhi ng timeout na mukhang problema sa server, dahil pag-aari na ngayon ng address ang iba o wala. Gamitin ang kasalukuyang profile ng operator sa halip na palitan ang address na dating gumagana. Ang kawalan ng sagot sa ping ay hindi ebidensiya sa alinmang direksyon: maraming endpoint ang nagtatapon ng ICMP habang mahusay na naglilingkod.
Naghihintay ang pag-setup ng transport sa packet na hindi darating
Kapag maayos ang DNS at sinusunog pa rin ng client ang buong timeout, ang layer ng transport ang pinaghihinalaan. Sa TCP, maaari mong subukan ang port nang direkta; Test-NetConnection sa Windows o nc -vz sa Linux ay nagsasabi kung may tumatanggap ng koneksyon, at iyon ay mas kapaki-pakinabang kaysa ping. Sa UDP, hindi mo ito masusubukan sa parehong paraan, dahil walang handshake na tatapusin sa layer na iyon, at ang asimetriyang ito ay nagdudulot ng maraming maling konklusyon.
Ang pinapatunayan ng TCP test ay limitado: ang serbisyong tumatanggap ng port 443 ay hindi laging ang tagapakinig ng VPN, at ang endpoint na UDP lamang ay walang port na TCP para tumanggap ng anuman. Ang muling pagsulat ng profile mula UDP patungong TCP ay hindi lumilikha ng tagapakinig sa kabilang panig; binabago lamang nito ang hinihintay ng iyong client. Kung sinasala ng network ang protocol, ang pagbabago ay gumagawa ng ibang timeout sa parehong yugto.
Ang mga captive portal ay karapat-dapat sa sariling pagsusuri sa yugtong ito. Hanggang hindi pinapayagan ng portal ang device, ang lumalabas na trapiko ay pumupunta sa portal at ang pagtatangkang tunnel ay nakabitin lamang. Tapusin muna ang portal sa browser, pagkatapos ay subukan muli, at huwag baguhin ang profile habang nakabinbin pa ang portal.
Ang negosasyon at pag-log in ay nangangahulugang sumagot ang server
Sa sandaling maabot ng tunnel ang server, nagsisimula ang client ng handshake at nagbabago ang katangian ng error. Ang paghinto rito ay tungkol sa pagiging compatible, hindi sa maabot: magkaibang bersyon ng protocol, setting ng cipher o data channel na hindi tatanggapin ng kabilang panig, o profile na umaasa sa feature na hindi iniaalok ng server. OpenVPN ay inilipat ang default nitong negosasyon sa pagitan ng mga major version nang sapat na madalas kaya ang profile na isinulat para sa isang henerasyon ay maaaring umabot sa server at hindi pa rin umangat.
Ang authentication ang huling yugto at pinakamadaling mabasa nang mali. Ang tahasang pagtanggi ay isang sagot, na nangangahulugang gumagana ang landas at ang problema ay ang pagkakakilanlan, sertipiko o kalagayan ng account. Ang browser-based na single sign-on flow ay ikatlong kaso: hinihintay ng client ang aksiyong hindi mo ginawa, o browser na hindi nito mailunsad, at walang darating hanggang hindi mo natatapos ang hakbang na iyon.
Ihambing ang ebidensiya bago baguhin ang muling pagtatangka
Panatilihing pirmi ang device at profile at isa-isang baguhin, simula sa network. Kung ang parehong profile ay kumokonekta sa hotspot ng telepono at nag-timeout sa Wi-Fi ng hotel, ang variable ay ang landas, hindi ang server. Kung nabigo ito sa lahat ng lugar, ang variable ay ang profile o endpoint. Kung nabigo lamang sa isang oras ng araw, itala ang timestamp at ihambing ito sa mga pangyayari sa panig ng server bago magpalagay ng anuman tungkol sa load.
Para sa serbisyong pinangangasiwaan mo, ang mapagpasyang paghahambing ay kung dumarating man lang ang pagtatangka. Ang koneksyong umaabot sa tagapakinig at pagkatapos ay humihinto ay kabilang sa yugto ng negosasyon; ang hindi kailanman lumilitaw sa paningin ng tagapakinig ay problema sa transport o paglutas, at walang pagsasaayos ng muling pagtatangka ang makakagalaw nito. Hinihiwalay din ng mga log ng server ang tinanggihang pag-log in mula sa tahimik na pagbagsak, na siyang pagkakaiba ng pagwawasto ng pagkakakilanlan at pagwawasto ng firewall.
Itala ang bersyon ng client, pangalan ng profile, oras ng pagtatangka kasama ang time zone nito at ang unang kapaki-pakinabang na error sa halip na ang huling linyang nadiskonekta. Alisin ang mga key at materyal na may dalang kredensyal bago ibahagi ang sipi. Pagkatapos ay gumawa ng isang makabuluhang pagwawasto at subukan muli, dahil ang mas mahabang deadline ay tumutulong lamang sa dokumentadong mabagal na operasyon at walang ginagawa para sa maling address o naka-block na port.