Bakit mas matagal bumangon ang VPN mo kaysa sa pagkawala ng koneksyon

Bumalik ang Wi-Fi tatlumpung segundo ang nakalipas at patay pa rin ang VPN, kaya mukhang sira ang kliyente. Kadalasan, sinusunod lang nito ang sarili nitong iskedyul ng muling pagtatangka, at hindi alam ng iskedyul na iyon na kababalik lang ng network. Ang agwat na iyon ang buong kuwento: ang oras ng pagbangon ay ang pagkawala kasama ang anumang paghihintay na tinanggap na ng kliyente. Ang pagbaba ng bawat timer ay isang sagot, at ang pag-unawa kung aling timer ang mahalaga ay ang isa pa.

Tatlong kundisyon ang nagpapasya kung makakatulong ang pagsasaayos: aling yugto ang mabagal, kung ang pagkabigo ay maaaring ulitin man lang, at paano nalalaman ng kliyente na bumalik na ang network.

Tatlong paghihintay na mukhang isa

Ang paglutas ng endpoint, ang negosasyon ng IKE o TLS, ang muling pagpapadala ng packet at ang pagsisimula ng bagong pagtatangka ay magkakahiwalay na pangyayari na may magkakahiwalay na timer. Idinokumento ng strongSwan ang backoff ng muling pagpapadala para sa IKE, at ang OpenVPN ay may sariling mga kontrol sa muling pagtatangka na may ibang kahulugan. Ang pagkopya ng numero mula sa isa patungo sa isa pa ay nagpapalagay na magkatugma ang mga mekanismo, at hindi sila magkatugma. Basahin ang pagkakasunod-sunod sa log bago magpasya kung aling pagitan ang tinitingnan mo.

Ang tahimik na minuto sa log ay hindi laging nagyelong proseso. Maaaring ito ay exponential na backoff na ginagawa ang eksaktong itinakda para gawin.

Aling yugto ang talagang mabagal?

Kung ang log ay nagpapakita ng mga pagtatangkang nabibigo dahil sa error sa pagpapatunay, walang pagbabago sa timer ang makakatulong, dahil mali ang kredensyal. Kung wala talagang pagtatangkang ginagawa, nasa loob ng window ng paghihintay ang kliyente at ang iskedyul ang solusyon. Kung may mga pagtatangkang ginagawa at nag-time out, ang problema ay abot-kaya o kulang na listener, at ang mas mabilis na muling pagtatangka ay pinupuno lang ang log. Bawat isa sa tatlong estadong iyon ay may ibang may-ari, at isa lang sa kanila ang problema sa oras.

I-uri ang pagkabigo bago hawakan ang isang numero.

Kailan nakakatulong ang pagbaba ng timer, at kailan hindi

Babaan ang kisame ng muling pagtatangka kapag ang nangingibabaw na gastos ay ang paghihintay pagkatapos ng maikli at madalas na pagkawala, tulad ng laptop na gumagalaw sa pagitan ng mga access point. Iwanan ito kapag mahaba o bihira ang mga pagkabigo, dahil ang agresibong muling pagtatangka ay nagdaragdag ng karga sa eksaktong sandaling pinakamahina ang concentrator na tumugon. Sa dalawang kaso, baguhin ang isang parameter, itala ito, at sukatin ang susunod na pagbangon sa halip na ipalagay na bumuti ito.

Ang napakababang timeout na kinopya sa bawat profile ay ang karaniwang huling kalagayan ng pagsasaayos na walang pagsukat.

Suriin ang kahandaan bago sisihin ang kliyente

Kadalasan ay hindi nakikita ng kliyente na magagamit ang network hanggang may sumubok. Ang captive portal, pag-renew ng DHCP o pagbabago ng ruta ay maaaring magpahintay dito sa iskedyul na itinakda bago mangyari ang lahat ng iyon. Panoorin ang pagbabago ng estado ng network ng operating system at ang susunod na pagtatangka ng kliyente sa parehong orasan, at makikita mo kung kaninong paghihintay ito. Ang mabilis na bersyon ay itala ang timestamp ng kaganapang network-ready at ang timestamp ng unang pagtatangka pagkatapos nito.

Kumpirmahin din na nakaharang pa rin ang direktang trapiko sa panahon ng paghihintay, dahil ang mas mabilis na muling pagkonekta na naglalabas ng trapiko ay hindi pagpapabuti.

Ano ang itatala

Isulat kung aling timer ang nagbago, mula sa aling halaga patungo sa alin, at paano nagmukha ang pagbangon pagkatapos. Itala rin ang bersyon ng kliyente, dahil gumagalaw ang mga default sa pagitan ng mga release at ang hindi nakadokumentong napakababang timeout ay malilito ang susunod na tao na magbabasa ng profile.

Ang talang iyon ay ginagawang paghahambing ang susunod na pag-upgrade ng software sa halip na eksperimento.