Miért indul el egy VPN-egység a hálózat előtt, és miért hal meg utána

Indítsa el a gépet, jelentkezzen be, és tapasztalja meg, hogy az alagút feljött, majd néhány másodperccel később meghalt. A profil rendben volt, a tanúsítvány rendben volt, és az egyetlen maradék nyom az adott indítás naplója. Ami általában történt, az egy verseny: az egység azelőtt indult el, hogy a gépnek címe lett volna, és az általa deklarált sorrend nem azt jelentette, aminek látszik. Az alábbiak mind arról szólnak, hogyan bizonyítsa ezt a versenyt bizonyítékokból, és hogyan zárja le rendesen.

A cél találkozási pont, nem menedzser

A network-online.target fogalma sincs arról, mi a hálózat. Ez egy koordinációs pont, amely összegyűjti azt a szolgáltatást, amelynek az indítást késleltetnie kellene, amíg a kapcsolat használhatóvá nem válik, és a definíciót arra a hálózatkezelőre bízza, amelyik a gép tulajdonosa. A legtöbb asztali gépen és szerveren ez a NetworkManager vagy a systemd-networkd által szállított várakozó szolgáltatást jelenti. Ha egyiket sem engedélyezi, a célnak nincs mire várnia, így abban a pillanatban végrehajtódik, amikor valami behúzza, ami jóval a DHCP válasza előtt lehet. Az egységében lévő sorrendi sor őszinte volt, és mégis hasznavehetetlen.

Az első kérdés tehát nem az, mit deklarál az egysége. Hanem hogy a gépen valami tényleg végzi-e a várakozást.

A legutóbbi indítást olvassa, ne az egységfájlt

Az egységfájlok a szándékot írják le, a napló pedig azt, ami történt. Kérje le csak azt az indítást, monoton időbélyegekkel, hogy minden üzenet egy órán üljön. Aztán keressen két sort: azt a pillanatot, amikor az alagút egysége elkezdett indulni, és azt, amikor a cím megjelent vagy a várakozó szolgáltatás befejeződött. Rendezze sorba ezt a két számot, és a verseny vagy igazolódik, vagy kizáródik.

A függőségi nézet ezt megerősíti. Ha az alagút egységének kritikus lánca nem tartalmaz várakozó szolgáltatást, semmi nem késleltette az indítást azon az úton, és a cél nem végezte el a feltételezett munkát. Két nézet, egy következtetés.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Adja hozzá a várakozást, majd az újrapróbálkozást

Használjon drop-int a csomagolt egység szerkesztése helyett, hogy egy csomagfrissítés ne dobja el csendben a változtatást. Két direktíva számít: az egységet a cél után kell rendezni, és be kell húznia a célt ugyanabba a tranzakcióba. A sorrend önmagában nem idézi meg a célt; a vágy teszi ezt.

Az OpenVPN-ügyfél csomagolt egysége már mindkettőt hordozza. A kézzel írt egységek általában egyet vagy egyet sem hordoznak, amit érdemes ellenőrizni, mielőtt bármit hozzáadna.

[Service]
Restart=on-failure
RestartSec=15

Miért csapda a rögzített alvás

A ExecStartPre-beli alvás sorrendi javításnak tűnik, és extra lépésekkel járó késleltetésként viselkedik. Lassít minden indítást, az egészségeseket is, és még mindig veszít, amikor a kapcsolat tovább tart, mint a választott szám.

Ráadásul elrejti, hogy a várakozó szolgáltatás működik-e, így a következő hiba teljesen új problémaként jelenik meg, nem ugyanazként más időzítéssel. Egy rövid újraindítási késleltetés a jobb eszköz: egészséges indításnál semmibe sem kerül, és az elvesztett versenyt újabb kísérletté alakítja. Tartsa szerényen az intervallumot, és hagyja, hogy az egység sikerüljön. Ha örökké újraindul, a profil tönkrement, és semmilyen újrapróbálkozás nem változtat ezen, ezért olvassa a naplót az intervallum emelése helyett.

Amikor a sorrend helyes, és a nevek mégis elbuknak

Egy aktív egység alagútútvonallal azt jelenti, hogy a sorrend elvégezte a dolgát, és a maradék hiba egy szinttel feljebb van. A szokásos forma egy feloldóbeállítás, amelyet az alagút up-szkriptje alkalmaz, mielőtt a kapcsolat vagy a feloldó készen állt volna megtartani. Hasonlítsa össze a feloldó állapotát a hiba alatt azzal az állapottal, ami az alagút egységének újraindítása után van.

Ha az újraindítás helyrehozza a kereséseket, akkor indítási sorrendi hibája van, nem rossz DNS-kiszolgálója, és a kettő különböző javításokat igényel. Utána hideg indítással bizonyítsa az egészet szolgáltatás-újraindítás helyett, mert az újraindítás egy már fent lévő hálózat ellen fut, és pontosan azt a hibát rejti el, amelyet üldöz. Ismételje meg szándékosan lassú kapcsolattal, és tekintse továbbra is töröttnek azt az egységet, amely csak gyors hálózatnál működik.