Patay ang VPN pagkatapos ng sleep: nawalang tunnel o lumang app?

Bumukas ang takip, bumabalik ang wireless icon, at nakikita pa ring konektado ang VPN. Pagkatapos ay nag-hang ang unang internal na pahina hanggang mag-time out, at ganoon din ang bagong tab. Tatlong magkaibang bagay ang maaaring gumawa ng larawang iyon at kailangan nila ng tatlong magkaibang ayos: tunnel na hindi nakaligtas sa sleep, profile na walang nag-utos na i-activate muli, o app na hawak pa rin ang session na namatay ilang oras na ang nakalipas. Mas mabilis ang paghahambing sa kanila kaysa sa muling pag-install ng kahit ano.

Tatlong bagay ang maaaring masira pagkatapos magising

Ang unang kandidato ay ang tunnel mismo. Maaaring naroon pa ang interface na may address habang wala na ang ugnayan sa peer, kaya hindi patunay ng gumaganang landas ang ilaw ng indicator. Ang handshake na mas luma kaysa sa sleep ang palatandaan, at isang command lang ang kailangan upang makita ito.

Ang pangalawa ay ang activation. Maraming client ang kusang kumokonekta muli; ang iba ay hindi, at ang profile na walang nag-uutos na bumalik ay nakaupo lang doon at mukhang naka-configure. Tahimik ang pagkabigong iyon ayon sa disenyo, dahil walang nagbalik ng error.

Ang pangatlo ay ang app. Ang tab ng browser, session ng SSH o koneksyon sa database ay maaaring makaligtas sa pagbabago ng network bilang file descriptor habang patay ang transport sa ilalim nito. Pagkatapos ay perpektong gumagana ang bagong session, na nagsasabi sa iyo na maayos ang tunnel sa buong panahon.

Ihambing ang tatlo bago magbago ng anuman, dahil hindi nagsasapawan ang mga ayos. Ang pag-restart ng client na hindi kailanman inutusan na magsimulang muli ay nag-aaksaya ng ebidensyang kailangan mo. Isulat kung aling kandidato ang tugma ng sintomas bago hawakan ang configuration. Ang isang pangungusap na iyon ang karaniwang nagpapasya sa natitirang pagsisiyasat.

Una: bumalik ba ang tunnel?

Tingnan ang interface at ang kalagayan ng peer sa halip na ang status text ng client. Ang interface na may address at walang kamakailang handshake ay tunnel na umiiral sa pangalan lamang.

ip -brief addr show
wg show
ip route show table all | head -20

Kung tuluyang wala ang interface, hindi nakaligtas ang tunnel at ang tanong ay kung sino ang dapat nagbalik nito. Kung naroon ito pero luma ang handshake, kailangang itatag muli ang ugnayan sa peer, at maaaring naghihintay ang client ng trapikong magpapagana nito.

Suriin din ang mga ruta at ang configuration ng DNS. Maaaring bumalik ang tunnel na wala ang mga ruta nito, na lumilikha ng nakalilitong kalagayan kung saan aktibo ang interface at ang mga panloob na pangalan ay niresolba pa rin sa maling server.

Pangalawa: may humiling bang bumalik ito?

Dito nagiging sulit ang paghahambing. Ang profile ng plugin na OpenVPN at ang katutubong koneksyon ng WireGuard ay iba ang pagtrato ng NetworkManager, at malinaw na sinasabi ng reference ng mga setting ng koneksyon na hindi ina-activate ng connection.autoconnect ang mga profile ng VPN; ang mekanismo upang iangat ang VPN kasama ng koneksyon ay connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Kung inaayos ng manuwal na muling pagkonekta ang problema sa bawat pagkakataon, iyon ang tanda ng kulang na activation at hindi ng sirang tunnel. Karaniwang ipapakita ng log ang interface na bumabagsak at walang nagbabalik nito.

Labanan ang hilig na magdagdag agad ng hook ng sleep. Ang hook na tumatakbo bago pa maka-recover ang network ay karerahan sa mismong prosesong sinusubukan nitong tulungan, at ginagawang paminsan-minsan ang problemang nauulit.

Pangatlo: hawak ba ng app ang lumang estado?

Magbukas ng ganap na bagong session patungo sa parehong destinasyon bago hawakan ang VPN. Kung gumagana ang bagong session at hindi ang luma, maayos ang tunnel at hawak ng app ang patay na koneksyon.

Ito ang pinakamura sa tatlong pagsusuri at ang pinakamadalas laktawan, dahil nasa screen mismo ang bintanang nabibigo. Isara ito, buksan muli, at tandaan kung nananatili ang problema. Kung gumagana ang bagong session, tuluyang ihinto ang pagsisiyasat sa tunnel. Kung nabibigo rin ito, sintomas ang app at hindi dahilan.

Ang ilang app ay kusang gumagaling pagkatapos ng timeout, kaya maaaring magmukhang kusang naayos ang sintomas pagkalipas ng ilang minuto. Itinuturo ng gawi na iyon ang app at hindi ang tunnel, at sulit itong itala nang hiwalay. Ang katrabahong nagsasabing kusang naayos lang ito ay naglalarawan ng huwaran na ito, hindi ng suwerte.

Gawing nauulit ang paghahambing

Panatilihing maliit ang mga variable: isang access network, isang tagal ng sleep at ang parehong unang kahilingan sa bawat pagkakataon. Pagkatapos itala ang dalawang resulta: inaayos ba ito ng manuwal na muling pagkonekta, at ibinabalik ba ng isa pang sleep ang pagkabigo.

Ang huling obserbasyon ang pinaka-maaasahang naghihiwalay sa tatlong kandidato. Ang bagong session na gumagana pagkatapos ng bigong luma ay hindi problema ng tunnel, at walang muling pag-install ng client ang makakabago niyon.

Ang palagiang keepalive ng WireGuard ay kasama sa larawang ito bilang keepalive ng NAT mapping lamang. Naglalabas ito ng mga packet upang manatiling bukas ang mapping; hindi nito pinipigilan ang makina sa pagtulog at hindi ito makapagpapatuloy sa pagpapadala habang nasuspinde ang proseso.

Itala sa ticket ang natuklasan mo: alin sa tatlo ang sira, ano ang nag-ayos nito at paano mo ito muling ginawa. Ang susunod na tao na magbubukas ng takip sa Lunes ay magpapasalamat sa iyo, at ang sagot ay hindi na kailangang tuklasin muli mula sa simula.