Kial via OpenVPN-kliento restas malsupre post unu tempolimo

Lunde matene: la tunelo, kiu ekfunkciis vendrede, malaperis, la interfaco ankoraŭ listiĝas, kaj nenio en la ĵurnalo diras, ke iu rimarkis tion. La gastiganto estas interrete, la panelo estas verda, kaj ĉio, kion ĝi sendis dum la semajnfino, eliris tra la fizika interfaco anstataŭe. Ĉi tie mankas du sendependaj decidoj: unu pri tio, ĉu la klienta procezo postvivas paseman paneon, kaj unu pri tio, ĉu io super ĝi restartigas la procezon post ĝia eliro. Ripari nur unu el ili lasas la alian breĉon malfermita.

Komencu de tio, kion la unuo efektive faris, ne de tio, kion asertas la monitorado. systemctl status openvpn-client@office kaj journalctl -u openvpn-client@office -n 50 montras la kaŭzon de la eliro kaj la lastan linion, kiun la kliento skribis antaŭ ol foriri.

La procezo eliris antaŭ ol iu rimarkis

Kliento, kiu malaperas sen eraro, kutime eliris intence. La profilo decidas tiun konduton, ne la servoadministranto: ping-exit finas la procezon tuj kiam la kontraŭparto ĉesas respondi, dum ping-restart konservas la procezon kaj rekonektas ene de ĝi. Sesiolimoj kaj neaktivecaj tempigiloj produktas de ekstere la saman bildon: neniun tunelon kaj neniun alarmon.

La du ping-direktivoj ne povas aperi kune en unu profilo, do elektu unu kaj notu la elekton. Rigardu ankaŭ la servilon, ĉar ĝia propra ping-exit fermas sesion sendepende de tio, kion petis la kliento, kaj nur la servila ĵurnalo registras, kiu faris tiun decidon.

Elekti inter ping-exit kaj ping-restart

Elektu ping-restart por tekokomputilo aŭ fora loko, kiu devas mem resaniĝi, kaj konservu ping-exit por kazoj, kie morta tunelo devas haltigi la procezon por ke io alia povu reagi al ĝi. La nombroj malpli gravas ol la rilato: ping 10 kun ping-restart 60 signifas dek sekundojn da silento antaŭ sondado kaj sesdek antaŭ la restartigo, kio estas agresema sur perda poŝtelefona ligo kaj racia sur drata. Skribu la kialon apud la linio, ĉar alie la sekva leganto supozos, ke la implicitaj valoroj estis intencaj.

Poste konfirmu, ke vere la procezo eliris. Unuo, kiu raportas aktivan dum la tunelo estas morta, estas alia paneo, traktata pli malsupre.

Superrigardo, kiu vere restartigas la unuon

Sur systemd-gastiganto la plej malgranda daŭra ŝanĝo estas unu drop-in dosiero: Restart=on-failure kaj RestartSec=10 en /etc/systemd/system/[email protected]/restart.conf. Drop-in estas legata nur kiam systemd reŝargas siajn proprajn difinojn, do rulu systemctl daemon-reload poste. Kontrolu per systemctl show -p Restart -p ExecMainStatus openvpn-client@office anstataŭ supozi, ke la valoro alvenis. La instanco en la dosiernomo devas esti la profilo, kiun la unuo vere ŝargas, do dosiero skribita por office faras nenion por openvpn-client@home.

on-failure ignoras unu kazon: puran eliron kun stato nulo. Iuj malkonstrupadaj vojoj finiĝas tiel, do legu la registritan staton anstataŭ fidi la vortigon de manpaĝo. Se via kliento rezignas kun nulo, vi bezonas Restart=always, kaj la kosto estas, ke vere difektita profilo revenas denove kaj denove, ĝis la limo de starta rapideco ekfunkcias kaj la ĵurnalo pleniĝas.

Restart=always ankaŭ ekfunkcias post intenca haltigo. Uzu systemctl stop por bontenado, kaj masku la unuon, se ĝi devas resti malsupre dum vi laboras.

Kaptu la likon dum la tunelo estas malsupre

Superrigardo revenigas la tunelon; ĝi ne malhelpas trafikon eliri dum la tunelo mankas. persist-tun konservas la aparaton kaj ĝiajn itinerojn trans rekonektoj, kio estas oportuna kaj malfermas fenestron. La aparato postvivas, la itineroj ankoraŭ celas ĝin, kaj pakaĵoj elfluas neprotektite kaj neraportite. Tio estas politika decido, ne neŭtrala implicita valoro.

Kiam gastiganto tute ne rajtas elsendi neprotektitajn pakaĵojn, nur la fajroŝirmilo povas garantii tion. Eliga regulo, kiu permesas la tunelan interfacon kaj la adreson de la VPN-servilo dum ĝi forĵetas ĉion alian, daŭre validas post la morto de la kliento, kaj nenio en la propra agordo de la kliento povas filtri trafikon, kiun la kliento ne portas.

Testu ĝin haltigante la klienton intence. Rulu systemctl stop openvpn-client@office, poste curl -m 5 https://example.com, kiu devus malsukcesi anstataŭ sukcesi tra la fizika ligo. Sukceso signifas, ke la fajroŝirmila regulo mankas aŭ estas tro permesema.

Rekonektiĝu, konfirmu, ke la tunelo denove portas trafikon, kaj nur tiam aldonu la kontrolon al monitorado. Sondadi ip addr per cron por tun aparato estas la superrigardo, kiu plej ofte malsukcesas, ĉar kun persist-tun la aparato postvivas la sesion kaj la sondado raportas sanecon dum nenio estas portata.