Pse vdes OpenVPN pasi laptopi zgjohet?

Gjumi mund ta vrasë sesionin e OpenVPN dhe të lërë tun0 pas. Testoni tunelin, pastaj rinisni njësinë nga një grep gjumi i systemd, jo pajisjen.

Vendoseni makinën në gjumë, zgjojeni dhe më pas kontrolloni tri gjëra në këtë rend para se të prekni çdo konfigurim: nëse tun0 ekziston ende, nëse rruga drejt një adrese të brendshme e zgjedh ende dhe nëse serveri e liston ende këtë peer. Një pajisje që i mbijeton gjumit ndërsa rruga tregon diku tjetër është mbetje, jo tunel. Kur rruga është e saktë dhe trafiku vdes gjithsesi, defekti qëndron mbi tunel dhe rinisja e klientit nuk do ta ndryshojë. Automatizimi i një rinisje ka kuptim vetëm pasi një test manual të ketë treguar se cili nga këto tri raste është i juaji.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Riprodhoni zgjimin para se ta automatizoni

Gjumi e përfundon sesionin e kriptuar më shpesh sesa e heq pajisjen. Rrjedha UDP që e mbante tunelin gjallë ndalon, serveri mund ta hedhë peer-in dhe klienti ose e vëren dhe rilidhet ose mban një ndërfaqe pa asgjë pas saj. Kontrolli i ndërfaqes vetëm sa vetë dëshmon pak, sepse një pajisje e vjetër duket saktësisht si një që funksionon derisa paketat duhet të kalojnë nëpër të. Ekzekutoni kërkimin e rrugës plus një kërkesë të vërtetë përmes tunelit, pastaj lexoni regjistrin rreth momentit të zgjimit.

Nëse klienti kthehet vetë, një grep shton rrëmujë në vend të besueshmërisë. Nëse nuk rikuperohet kurrë, automatizimi është zgjidhja e ndershme.

Ku jeton në të vërtetë një grep gjumi i systemd

Shumë udhëzues të vjetër tregojnë /etc/pm/sleep.d, një drejtori në pronësi të pm-utils të cilën një gjumë i bazuar në systemd nuk e konsulton kurrë. systemd lexon grep-at nga /usr/lib/systemd/system-sleep/ dhe /etc/systemd/system-sleep/, duke kaluar fillimisht fazën dhe më pas operacionin, kështu që pre dhe post janë të vetmet vlera në të cilat një grep degëzohet. Mbani kopjen lokale nën /etc në vend që të redaktoni një skedar të paketuar dhe mbani mend se skripti ekzekutohet si root në mes të tranzicionit, prandaj duhet të kthehet shpejt.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart prek një njësi vetëm kur ajo është tashmë aktive, kështu që një tunel që e keni fikur me qëllim mbetet i fikur gjatë zgjimit. --no-block e pengon grepin të presë ndërsa klienti negocion, gjë që ka rëndësi kur rrjeti nuk është ngritur ende. Së bashku dy flamujt nënkuptojnë një grep që dështon në heshtje në vend që të mbajë të gjithë sekuencën e zgjimit. Kur njësia është ndalur tashmë, nuk ndodh absolutisht asgjë, dhe ky është saktësisht rezultati që doni atje.

Rikthe shërbimin, lëre tun0 në paqe

Ulja e tun0 me dorë e lë demonin të mbikëqyrë një ndërfaqe që nuk e zotëron më, dhe ndryshimi i ardhshëm i gjendjes prodhon gabime ngatërruese. Synoni shërbimin ose profilin e lidhjes së tij, jo ndërfaqen; kontrolloni fillimisht emrin e saktë të njësisë, sepse paketat e shpërndarjes, OpenVPN 3 dhe NetworkManager zgjedhin të gjithë të ndryshëm. Një profil i NetworkManager kthehet kur ajo lidhje riciklohet, prandaj njësia e systemd nuk është objektivi atje. Cilido qoftë mekanizmi, duhet të jetë i njëjti veprim që keni verifikuar me dorë.

Një rinisje riinstalon rrugët që klienti shtyu kur u lidh. Shumica e zgjimeve e duan këtë. Një makinë ku keni shtuar rrugë tuajat jo, prandaj rikontrolloni ato në vend që të supozoni se rikuperimi i ktheu, dhe shkruajini atje ku zgjimi i radhës mund t'i gjejë.

Përballuni me kohën që nuk mund ta kontrolloni

Shoqërimi pa tel dhe DHCP shpesh përfundojnë pasi grepi ka ekzekutuar, kështu që një rinisje mund të dështojë ndërsa nuk ekziston ende një rrugë drejt serverit. Prisni pak për atë adresë, provoni edhe një herë dhe regjistroni rezultatin.

Zgjidhja e emrave është një garë më vete, sepse stiva e rrjetit të desktopit mund ta rikthejë DNS-in pasi tuneli është ngritur tashmë. Testoni kërkimet veçmas me resolvectl query internal.example në vend që t'i nxirrni nga një rrugë funksionale. Një tunel që rrugëton saktë dhe nuk zgjidh asgjë është problem DNS, jo problem i grepit.

Mbajeni vendimin e grepit të dukshëm duke shkruar fazën, emrin e njësisë dhe rezultatin në regjistër. Shënoni në shënimet e makinës cilin test zgjimi ekzekutuat, që një rikuperim funksional të dallohet nga një i fatit. Zgjidhni veprimin më pak shqetësues që e kthen shërbimin dhe lëreni një klient që rikuperohet vetë ta bëjë atë. Një rinisje e plotë hedh poshtë sesionet në rrjedhë, gjë që është një kosto reale në një laptop që zgjohet disa herë në ditë.

Artikuj të ngjashëm