Palaging nadidiskonekta ang VPN? Sundan ang ayos na ito

Bago muling i-install ang kliyente, isulat ang tatlong bagay: gaano katagal nanatiling aktibo ang tunnel, ano ang sinabi ng kliyente nang maputol, at kung natulog ba ang makina o nagpalit ng network sa pagitan. Ang talaang iyon ang tanging ebidensiyang magiging sa iyo mamaya, at karaniwang binubura ito ng muling pag-install. Ang pagputol sa paulit-ulit na agwat ay isang timer o pagkapaso ng estado; ang pagputol sa random na sandali ay problema sa ruta. Pinipigilan ka ng ayos sa ibaba na baguhin ang tatlong bagay nang sabay at walang matutunan.

Unang hakbang: itala ang agwat at ang teksto ng error

Magsimula sa sariling log ng kliyente at hindi sa dashboard ng provider. Sa kliyenteng Linux, ang log ng serbisyo at ang live na kalagayan ng tunnel ang sumasakop sa halos lahat:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Itala ang mga timestamp ng huling matagumpay na handshake at ang sandaling tumigil ang trapiko, hindi lang ang sandaling nagbago ang kulay ng icon. Ang GUI client na nagsasabing nadiskonekta pagkatapos ng pangyayari ay maaaring nag-uulat ng estadong naabot ng kernel ilang segundo bago iyon.

Panatilihin ang pananalita ng error. Ang timeout, pagtanggi sa pagpapatunay at error sa adapter o driver ay tumutukoy sa tatlong magkaibang layer, at ang karamihan ng nasayang pagpupunyagi sa problemang ito ay nagmumula sa pagtrato sa kanila bilang isa. Kopyahin ang linya nang eksakto sa iyong tala.

Ikalawang hakbang: baguhin ang isang variable, hindi ang profile

Panatilihing nakatigil ang aparato at profile at ilipat ang makina sa ibang access network, gaya ng hotspot ng telepono. Ito ang pinakamurang pagsubok na naghihiwalay sa kliyente mula sa ruta. Patakbuhin ito nang sapat na tagal upang masakop ang orihinal na agwat ng pagpalya; ang dalawang matatag na minuto ay walang pinapatunayan tungkol sa pagputol na nangyayari sa ika-tatlumpung minuto.

Ang laptop na may Ethernet port ay nagbibigay ng ikalawang paghahambing na nag-aalis ng Wi-Fi nang lubusan sa larawan. Kung nananatili ang tunnel sa dalawang alternatibo, ang orihinal na access network ay dapat bigyan ng pansin: roaming sa pagitan ng mga access point, home router na nag-eexpire ang translation table, o upstream link na nagre-reset ng mahahabang daloy.

Isulat kung aling variable ang binago mo. Ang paghahambing ay binibilang lamang kapag ang lahat ng iba ay nanatiling pareho, at kabilang dito ang endpoint ng server at ang oras ng araw.

Ikatlong hakbang: iugnay ang agwat sa isang layer

Ang haba ng isang mahusay na sesyon ang pinaka-naglalaman ng impormasyong nag-iisang numero na mayroon ka. Basahin ito laban sa listahang ito bago hawakan ang mga timer:

• Pagputol pagkatapos ng pagtulog o pag-resume: nakaligtas ang estado ng tunnel sa pagsususpinde ngunit hindi ang interface. Suriin ang pag-uugali ng muling pagkonekta ng kliyente sa pag-resume at kung ini-restart ng serbisyo ang tunnel o naghihintay ng trapiko.
• Pagputol lamang kapag walang ginagawa: may isang bagay sa gitna na nagpahintulot sa daloy na mag-expire. Ang keepalive ay umiiral para sa ganitong kaso.
• Pagputol sa takdang edad ng sesyon: kaganapan ng muling pagpapatunay o pag-renew ng key, hindi pagkabigo ng ruta. Ang tahasang pagtanggi sa log sa eksaktong agwat na iyon ang senyales.
• Pagputol habang may malalaking paglilipat o malalaking pahina: pagdudahan ang MTU at fragmentation, hindi ang idle timer.

Para sa kaso ng idle, ang mga setting ay partikular sa protocol at mahalaga ang dalawang dulo. Ang keepalive 10 60 ng OpenVPN sa server ay nagpapadala ng ping tuwing 10 segundo at ini-restart ang link pagkatapos ng 60 segundo na wala nito; ang mga kliyenteng WireGuard sa likod ng NAT ay gumagamit ng PersistentKeepalive = 25 sa peer block. OpenVPN ay muling nakikipagnegosasyon din sa data channel sa isang timer, reneg-sec, na default na 3600 segundo sa 2.x.

Huwag kopyahin ang agresibong halaga mula sa gabay ng ibang provider. Ang maikling timeout sa mobile link na may pagkalugi ay lumilikha ng eksaktong mga pagkadiskonektang dapat nitong pigilan, at ang mga halagang itinutulak ng server ay nangingibabaw sa itinakda mo sa profile ng kliyente.

Ikaapat na hakbang: ihambing ang isang suportadong alternatibo

Kung ang operator ay naglalathala ng parehong UDP at TCP na profile, patakbuhin ang parehong aparato at network laban sa isa. Gamitin ang tunay na tugmang file sa halip na i-edit ang transport sa kinopyang profile. Ang matatag na TCP profile sa rutang nire-reset ang UDP ay nagpapaliit ng problema sa rutang iyon; hindi nito pinatutunayan na TCP ang mas mahusay na transport sa lahat ng dako.

Ang parehong lohika ay nalalapat sa mga endpoint. Subukan ang ibang server at itago ang orihinal na resulta sa tabi nito. Kung isang labasan lamang ang nagre-reset ng mga sesyon, ebidensiya iyon tungkol sa endpoint na iyon, hindi dahilan para muling itayo ang bawat adapter sa laptop.

Pagkatapos ng anumang pagbabago, ulitin ang orihinal na trigger at kumpirmahin kung saan talaga napupunta ang trapiko. Ang naibalik na access sa internet ay hindi parehong resulta ng trapikong nasa loob ng tunnel, at ang kliyenteng tahimik na nahulog sa direktang ruta ay mukhang malusog mula sa browser.

I-verify ang pagwawasto, at itago ang rollback

Ang pagwawasto ay vine-verify sa pamamagitan ng muling paggawa ng orihinal na trigger, hindi sa matagumpay na koneksyon. Iwanang idle ang tunnel nang lagpas sa lumang agwat ng pagpalya, suspindihin at i-resume nang isang beses, at pagkatapos ay suriin ang edad ng handshake at ang exit address:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Itago ang nakaraang profile at ang nakaraang mga halaga ng timer hanggang makaligtas ang bagong pag-uugali sa isang buong araw ng trabaho. Kung bumalik ang mga pagkadiskonekta, ibalik ang backup, at pagkatapos ay ilapat muli ang mga pagbabago nang isa-isa upang magsimula ang ikalawang pagtatangka sa kilalang estado.

Kung nananatiling malinis ang log at nadidiskonekta pa rin ang tunnel sa paulit-ulit na agwat, ang susunod na hinto ay ang panig ng server para sa sesyong iyon. Dalhin ang identifier ng sesyon ng kliyente at ang eksaktong oras ng pagkadiskonekta, dahil ang pares na iyon ang nagpapaging-hanap ang log ng server. Ang mga opsyon sa link ng protocol ay nakadokumento sa manwal ng OpenVPN 2.6 kapag kailangan mo ang eksaktong kahulugan ng isang halaga.