TLS timeout na animnapung segundo: aling dulo ang talagang tumigil?

Sumusuko ang kliyente pagkatapos ng animnapung segundo na may mensahe tungkol sa pakikipag-usap sa susi, at walang opinyon ang laptop kung bakit. Inilalarawan ng pangungusap na iyon ang pasensya ng kliyente, hindi ang pag-uugali ng server. Tatlong ganap na magkaibang sitwasyon ang lumilikha nito: hindi kailanman nakarating ang packet sa tamang serbisyo, itinapon ito ng serbisyo bago magtala ng anuman, o tinanggihan ito ng serbisyo at sinabi iyon sa lugar na hindi makikita ng kliyente. Ang pag-uugnay ng isang pagtatangka sa magkabilang dulo ang naghihiwalay sa kanila.

Bigyan ang isang pagtatangka ng pagkakakilanlang mahahanap mo

Isulat ang oras ng pagsisimula kasama ang time zone nito, ang pangalan ng profile, ang destinasyong aktwal na niresolba ng kliyente, ang port, at kung ang koneksyon ay UDP o TCP. Kung may ilang malayong entry ang profile, itala kung alin ang pinili ng pagtatangkang iyon, dahil maaaring lumipat ang muling pagtatangka sa susunod na entry nang hindi binabago ang file na binabasa mo.

Kunin ang endpoint mula sa aktibong log, hindi mula sa download na natatandaan mo. Ang profile na nakaturo sa pribadong address ay ganap na wasto at ganap na hindi magagamit mula sa network na hindi makakapag-route doon, at ang kasong iyon ay mukhang kapareho ng server na patay.

Pagkatapos, hilingin sa operator ang parehong window sa nilalayong instance. Ang pagkakaiba ng orasan ay karaniwan kaya ang ilang minutong agwat ay maaaring magpakita ng tugmang pangyayari na parang wala, kaya itala ang agwat sa halip na magpasya na walang pangyayari.

Apat na obserbasyon, apat na magkaibang susunod na hakbang

Ang itinatala ng server ang nagpapasya sa sangay. Ang kawalan ng anumang pagtatangka ay tumuturo sa pag-address, transportasyon o daan patungo sa serbisyo. Ang mga papasok na packet na naglalaho bago ang ordinaryong pagpapalitan ay tumuturo sa mga pangangailangan ng control channel ng aktwal na serbisyo. Ang pinangalanang pagtanggi ay tumuturo sa bagay na pinangalanan nito. Ang mga tugon na umaalis sa server ngunit hindi kailanman umabot sa kliyente ay tumuturo sa daan pabalik.

Ang walang laman na log ng application ay mas mahinang ebidensya kaysa sa itsura nito. Nagsisimula ang pag-log sa isang tiyak na punto ng pagpapalitan, at ang mga packet na itinapon bago ang puntong iyon ay walang iniwanang bakas sa file na binabasa mo. Kung saan pinapayagan, maaaring gamitin ng operator ang mga obserbasyon sa serbisyo at network upang tingnan kung may dumating man.

Panatilihing hiwalay ang apat na resulta sa iyong mga tala. Ang tukso ay pagsamahin ang mga ito sa “hindi tumutugon ang server”, at iyon ang pariralang nagpapadala ng mga tao na magpalit ng cipher kapag ang tunay na problema ay patakaran ng firewall. Ang talang nagtatala lamang ng salitang timeout ay itinapon ang pagkakaibang kababayad mo lang.

Ayusin ang yugtong pinangalanan ng ebidensya

Ang natapos na koneksyong TCP ay nagpapatunay lamang na may tumanggap ng socket. Hindi nito pinatutunayan na ang tagapakinig ay ang serbisyong OpenVPN na inayos mo, at ang web server sa parehong hostname ay perpektong tumutugon sa browser habang walang kaugnayan sa tunnel.

Kung iniuulat ng server ang isang nag-expire na listahan ng pagpapawalang-bisa, iyon ay mas tiyak na katotohanan kaysa sa huling timeout ng kliyente, at ang pagwawasto ay pag-aari ng awtoridad ng sertipiko at hindi ng network. Kung hindi magkasundo ang dalawang dulo tungkol sa proteksyon ng control channel o sa ibinahaging materyal, walang nababago ang pag-reset ng password, dahil nangyayari ang pagtatapon bago pa suriin ang anumang kredensyal.

Baguhin ang isang bagay na tunay na sinasang-ayunan ng ebidensya, pagkatapos ay ulitin ang parehong profile laban sa parehong endpoint. Itago ang unang bagong pangyayari kung mas malayo ang koneksyon, dahil ang pangyayaring iyon ay ang susunod na yugto ng pagsisiyasat, hindi isang bagong problema.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

Ano ba talaga ang binabago ng pagpapahaba ng window

Animnapung segundo ang window ng pagkamay ng kliyente, at ang sanggunian ng kliyente ng komunidad ay nagtatala ng opsyong nag-aayos nito. Ang pagpapataas nito ay nagpapahintay sa kliyente nang mas matagal bago sumuko. Hindi nito pinapakita ang isang serbisyong wala at hindi nito ginagawang katanggap-tanggap ang isang tinanggihang packet.

May lehitimong gamit ang mas mahabang window sa mabagal na link o mabigat na server, at sulit subukan kapag may ebidensya ka na mabagal na sumusulong ang pagpapalitan at hindi na hindi ito nangyayari. Ang subukan ito muna ay nagpapaliban lamang ng parehong diagnosis ng isa pang minuto at ginagawang mas mahirap basahin ang timeline. Kung ang timeline ay nagpapakita ng pagpapalitang sumusulong at pagkatapos ay tumitigil, ang window ay sintomas ng kargada at hindi ng maabot.