Stuck na VPN pagkatapos ng reboot ng router: tatlong bagay na nagbago

Natapos nang mag-boot ang router, muling sumasali ang laptop sa parehong SSID, at nananatiling nakakonekta ang VPN na walang gumagalaw. Buo pa ang naka-save na profile. Ang nag-expire sa ilalim nito ay ang landas, at hawak pa rin ng kliyente ang estado na itinayo nito para sa luma.

Tatlong kondisyon ang nagtatakda ng ayos. Suriin ang mga ito nang sunod-sunod, dahil nasasayang ang huli kung ipinaliwanag na ng una ang pagtigil.

Unang kondisyon: nagbago ang lokal na address

Maaaring magbigay ang reboot ng ibang address sa makina. Pagkatapos, ang VPN na naka-configure na may fixed na lokal na endpoint ay patuloy na gumagamit ng koneksyon na wala na. Ganoon din sa kliyenteng nagbigkis ng socket nito sa lumang address. Maaaring manatiling nakaupo ang interface ng tunnel habang bawat packet na ginagawa nito ay napupunta sa walang silbi.

Ihambing ang address na ginagamit ng kliyente sa address na hawak ng interface ngayon. Ang default na ruta na tumuturo sa isang gateway na nagbago rin ay parehong uri ng problema sa ibang pangalan.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Ikalawang kondisyon: nawala ang isinaling mapping

Isinasalin ng mga router sa bahay ang papuntang labas na daloy, at ang mga mapping na iyon ay nabubuhay sa memorya. Binubura ng reboot ang bawat isa sa kanila. Hindi iyon mapanganib para sa bagong koneksyon at nakamamatay para sa tunnel na naniniwalang wasto pa ang umiiral nitong daloy. Wala nang makikita ang kabilang panig, kaya hindi kailanman nakakatanggap ang kliyente ng error na maaaring aksyunan.

Dito tumitigil nang tahimik ang isang tunnel na walang keepalive sa halip na mabigo nang malakas. Ang mga dokumentadong limitasyon ng WireGuard ay naglalarawan ng parehong hugis ng pagkabigo. Ang maling estado ng endpoint ay gumagawa ng itinatapong packet sa halip na diagnosis.

Ang persistenteng keepalive na 25 segundo ang karaniwang pagpapagaan, dahil nire-refresh nito ang mapping bago mag-expire ang idle timeout. Hindi nito inaayos ang mapping na nawala na. Ipares ang keepalive sa logic ng muling pagkonekta sa halip na ituring itong ayos.

Ikatlong kondisyon: nagbago ang pampublikong address

Kung nagbago ang sariling panlabas na address ng router, anumang bagay sa kabilang panig na nagfi-filter ayon sa source address ay nakakakita na ngayon ng ibang kapareha. Maaaring umangat ang tunnel at maaaring itapon pa rin ng server ang trapiko, na mukhang sirang kliyente at sa totoo lang ay patakaran sa kabilang dulo.

Itala ang panlabas na address bago at pagkatapos ng reboot. Kapag magkaiba ang dalawa, lumilipat ang tanong mula sa kliyente sa sinumang nagpapanatili ng allowlist, at hindi makatutulong ang pag-reset ng mga kredensyal sa laptop.

Ibalik sa tamang ayos

Tapusin muna ang anumang kailangang sign-in sa captive portal, pagkatapos hayaan ang kliyenteng muling kumonekta sa sinusuportahang pamamaraan nito sa halip na patayin ang proseso. Panoorin kung bumalik ang pagkakakilanlan at trapiko ng data, dahil dalawa ang mga iyon na magkaibang yugto ng parehong koneksyon.

Walang pinatutunayan ang naka-cache na pahina, at ganoon din ang chat app na kusang muling kumonekta. Subukan ang endpoint na talagang mahalaga sa iyo gamit ang bagong kahilingan. Panatilihin ang patakaran sa direktang trapiko habang may pagkaantala, dahil ang pagtatangkang muling kumonekta ay hindi pagharang.

Kapag paulit-ulit ito pagkatapos ng bawat reboot, mas mahalaga ang tala kaysa sa muling pagsubok. Itala ang lokal na address, ang gateway, ang panlabas na address at ang estado ng kliyente bago at pagkatapos, pagkatapos ay ihambing ang dalawang hanay. Ginagawa nitong bug sa lifecycle ang malabong reklamo na may makakaayos, at pinipigilan ang ikatlong pagpapalit ng mga sertipiko dahil sa timeout ng mapping.