Zergatik hiltzen da OpenVPN ordenagailua esnatu ondoren?

Jarri makina etenean, esnatu eta gero egiaztatu hiru gauza ordena honetan, edozein konfigurazio ukitzen hasi aurretik: ea tun0 oraindik existitzen den, barne-helbiderako ibilbideak oraindik hura aukeratzen duen eta zerbitzariak peer hau oraindik zerrendatzen duen. Loaldia gainditzen duen gailua, ibilbidea beste nonbait seinalatzen duen bitartean, hondar bat da, ez tunel bat. Ibilbidea zuzena denean eta trafikoa hala ere hiltzen denean, hutsegitea tunelaren gainetik dago eta bezeroa berrabiarazteak ez du hori aldatuko. Berrabiaraztea automatizatzeak zentzua du proba manual batek hiru kasu horietatik zein duzun erakutsi ondoren soilik.

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

Erreproduzitu esnatzea, automatizatu aurretik

Etenak saio zifratua gailua kentzen duen baino sarriago amaitzen du. Tunela bizirik mantentzen zuen UDP fluxua gelditzen da, zerbitzariak peer-a bota dezake, eta bezeroak edo nabaritzen du eta berriro konektatzen da, edo atzean ezer ez duen interfaze bat mantentzen du. Interfazearen egiaztapenak bakarrik gutxi frogatzen du, zeren gailu zaharkitu bat funtzionatzen ari den baten berdin-berdina dirudi paketeek hura zeharkatu behar duten arte. Exekutatu ibilbidearen bilaketa eta tunelaren bidezko eskaera erreal bat, eta gero irakurri egunkaria esnatzearen uneko inguruan.

Bezeroa bere kabuz itzultzen bada, kako batek eragozpena gehitzen du fidagarritasunaren ordez. Inoiz berreskuratzen ez bada, automatizazioa da konponbide zintzoa.

Non bizi da systemd-ren lo-kako bat benetan

Gida zahar askok /etc/pm/sleep.d seinalatzen dute, pm-utils-en jabetzako direktorioa, systemd-n oinarritutako etenak inoiz kontsultatzen ez duena. systemd-k kakoak /usr/lib/systemd/system-sleep/ eta /etc/systemd/system-sleep/ irakurtzen ditu, lehenengo faseari eta gero eragiketari pasatuz, beraz pre eta post dira kako bat adarkatzen den balio bakarrak. Mantendu kopia lokala /etc azpian, paketatutako fitxategi bat editatu beharrean, eta gogoratu scripta root gisa exekutatzen dela trantsizioaren erdian, beraz azkar itzuli behar du.

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

try-restart unitate bat ukitzen du soilik jadanik aktiboa denean, beraz nahita itzali duzun tunel bat itzalita jarraitzen du esnatze osoan. --no-block kakorri uzten dio bezeroak negoziatzen duen bitartean itxaroten, eta hori garrantzitsua da sareak oraindik gora egin ez duenean. Bi banderek batera esan nahi dute kako bat isilean huts egiten duela esnatze-sekuentzia osoa eusten duen ordez. Unitatea jada geldituta badago, ez da ezer gertatzen, eta hori da hantxe nahi duzun emaitza zehazki.

Berreskuratu zerbitzua, utzi tun0 bakean

tun0 eskuz jaisteak deabrua jada ez duen interfaze baten gainbegiratzen uzten du, eta hurrengo egoera-aldaketak errore nahasgarriak sortzen ditu. Heldu zerbitzuari edo bere konexio-profilari interfazearen ordez; egiaztatu lehenengo unitatearen izen zehatza, banaketa-paketeek, OpenVPN 3-k eta NetworkManager-ek desberdinak hautatzen baitituzte. NetworkManager profila itzultzen da konexio hori birziklatzen denean, beraz systemd unitatea ez da han helburua. Mekanismoa edozein dela ere, eskuz egiaztatu duzun ekintza bera izan beharko litzateke.

Berrabiarazteak bezeroak konektatzean bultzatutako ibilbideak berriro instalatzen ditu. Esnatze gehienek hori nahi dute. Zure bideak gehitu dituzun makina batek ez, beraz egiaztatu berriro horiek, berreskuratzeak leheneratu zituela suposatu beharrean, eta idatzi itzazu hurrengo esnatzeak aurkitu ahal izateko lekuan.

Kudeatu kontrolatu ezin duzun denbora

Haririk gabeko elkarketak eta DHCP-k sarritan kakoa exekutatu ondoren amaitzen dute, beraz berrabiarazteak huts egin dezake zerbitzarirako bidea oraindik ez dagoenean. Itxaron pixka bat helbide hori lortzeko, saiatu berriro behin eta erregistratu emaitza.

Izenen ebazpena lasterketa bereizia da, mahaigaineko sare-pilak DNS leheneratu baitezake tunela jada gora egon ondoren. Egiaztatu bilaketak bereiz resolvectl query internal.example erabiliz, ibilbide funtzional batetik ondorioztatu beharrean. Behar bezala bideratzen duen eta ezer ebazten ez duen tunel bat DNS arazoa da, ez kakoaren arazoa.

Egin kakoaren erabakia ikusgai, fasea, unitatearen izena eta emaitza egunkarian idatziz. Idatzi makinaren oharretan zein esnatze-proba exekutatu duzun, berreskuratze funtzional bat zortedun batetik bereizteko. Aukeratu zerbitzua itzultzen duen ekintzarik gutxien suntsitzen duena, eta utzi bere kabuz berreskuratzen den bezeroari hori egitea. Berrabiarazte osoak martxan dauden saioak botatzen ditu, eta hori benetako kostua da egunean hainbat aldiz esnatzen den ordenagailu batean.