Pse klienti juaj OpenVPN mbetet i ndalur pas një skadimi të vetëm kohe

E hënë në mëngjes: tuneli që u ngrit të premten ka humbur, ndërfaqja është ende në listë dhe asgjë në regjistër nuk thotë se dikush e vuri re. Strehuesi është në linjë, paneli është i gjelbër dhe gjithçka që dërgoi gjatë fundjavës doli përmes ndërfaqes fizike. Këtu mungojnë dy vendime të pavarura: njëri nëse procesi i klientit i mbijeton një dështimi kalimtar dhe tjetri nëse diçka mbi të e rinis procesin pas daljes. Rregullimi i vetëm njërit lë hapësirën tjetër të hapur.

Filloni nga ajo që bëri në të vërtetë njësia, jo nga ajo që pretendon monitorimi. systemctl status openvpn-client@office dhe journalctl -u openvpn-client@office -n 50 tregojnë arsyen e daljes dhe rreshtin e fundit që klienti shkroi para se të largohej.

Procesi doli para se dikush ta vinte re

Një klient që zhduket pa gabim zakonisht ka dalë me qëllim. Profili vendos për këtë sjellje, jo menaxheri i shërbimit: ping-exit e përfundon procesin sapo pala tjetër ndalon së përgjigjuri, ndërsa ping-restart e mban procesin dhe rilidhet brenda tij. Kufijtë e sesionit dhe kohëmatësit e pasivitetit japin nga jashtë të njëjtën pamje: pa tunel dhe pa alarm.

Dy direktivat ping nuk mund të jenë së bashku në një profil, kështu që zgjidhni një dhe shënoni zgjedhjen. Shikoni edhe serverin, sepse ping-exit e tij mbyll një sesion pavarësisht nga ajo që kërkoi klienti, dhe vetëm regjistri i serverit shënon kush e mori atë vendim.

Zgjedhja midis ping-exit dhe ping-restart

Zgjidhni ping-restart për një laptop ose një vend të largët që duhet të shërohet vetë, dhe mbani ping-exit për rastet kur një tunel i vdekur duhet të ndalojë procesin në mënyrë që diçka tjetër të mund të veprojë mbi të. Numrat kanë më pak rëndësi se lidhja: ping 10 me ping-restart 60 nënkupton dhjetë sekonda heshtje para një prove dhe gjashtëdhjetë para rinisjes, çka është agresive në një lidhje celulare me humbje dhe e arsyeshme në një me kabllo. Shkruani arsyen pranë rreshtit, përndryshe lexuesi tjetër do të supozojë se vlerat e paracaktuara ishin të qëllimshme.

Pastaj konfirmoni që ka dalë vërtet procesi. Një njësi që raporton aktivitet ndërsa tuneli është i vdekur është një dështim tjetër, i trajtuar më poshtë.

Mbikëqyrje që e rinis vërtet njësinë

Në një strehues systemd, ndryshimi më i vogël i qëndrueshëm është një skedar drop-in: Restart=on-failure dhe RestartSec=10 në /etc/systemd/system/[email protected]/restart.conf. Një drop-in lexohet vetëm kur systemd rimbush përkufizimet e veta, prandaj ekzekutoni systemctl daemon-reload pas kësaj. Verifikoni me systemctl show -p Restart -p ExecMainStatus openvpn-client@office në vend që të supozoni se vlera mbërriti. Instanca në emrin e skedarit duhet të jetë profili që njësia ngarkon vërtet, kështu që një skedar i shkruar për office nuk bën asgjë për openvpn-client@home.

on-failure injoron një rast: një dalje të pastër me status zero. Disa rrugë çmontimi përfundojnë kështu, prandaj lexoni statusin e regjistruar në vend që të besoni formulimin e një faqe manuali. Nëse klienti juaj dorëzohet me një zero, ju duhet Restart=always, dhe kostoja është që një profil vërtet i prishur kthehet vazhdimisht derisa të aktivizohet kufiri i shpejtësisë së nisjes dhe regjistri të mbushet.

Restart=always aktivizohet edhe pas një ndalimi të qëllimshëm. Përdorni systemctl stop për mirëmbajtje dhe maskoni njësinë nëse duhet të mbetet e ndalur ndërsa punoni.

Kapni rrjedhjen ndërsa tuneli është i ndalur

Mbikëqyrja e kthen tunelin; nuk e pengon trafikun të dalë ndërsa tuneli mungon. persist-tun e mban pajisjen dhe rrugët e saj midis rilidhjeve, çka është e përshtatshme dhe hap një dritare. Pajisja mbijeton, rrugët ende tregojnë drejt saj dhe paketat rrjedhin jashtë të pambrojtura dhe pa njoftim. Ky është një zgjedhje politike, jo një vlerë e paracaktuar neutrale.

Kur një strehues nuk lejohet të emetojë fare paketa të pambrojtura, vetëm muri i zjarrit mund ta garantojë atë. Një rregull daljeje që lejon ndërfaqen e tunelit dhe adresën e serverit VPN ndërsa hedh poshtë gjithçka tjetër vlen edhe pas vdekjes së klientit, dhe asgjë në konfigurimin e vetë klientit nuk mund të filtrojë trafikun që klienti nuk mbart.

Provojeni duke e ndalur klientin me qëllim. Ekzekutoni systemctl stop openvpn-client@office, pastaj curl -m 5 https://example.com, i cili duhet të dështojë në vend që të ketë sukses përmes lidhjes fizike. Suksesi do të thotë që rregulli i murit të zjarrit mungon ose është tepër lejues.

Rilidhuni, konfirmoni që tuneli mbart përsëri trafik dhe vetëm atëherë shtoni kontrollin në monitorim. Sondimi i ip addr nga cron për një pajisje tun është mbikëqyrja që dështon më shpesh, sepse me persist-tun pajisja jeton më gjatë se sesioni dhe sonda raporton shëndet ndërsa asgjë nuk mbartet.