Miért marad le az OpenVPN-kliense egyetlen időtúllépés után

Hétfő reggel: a pénteken felépült alagút eltűnt, az interfész még szerepel a listán, és semmi nem állítja a naplóban, hogy bárki észrevette volna. A gazdagép online, a műszerfal zöld, és minden, amit a hétvégén küldött, a fizikai interfészen keresztül ment ki. Két független döntés hiányzik itt: az egyik arról, hogy a kliensfolyamat túléli-e az átmeneti hibát, a másik arról, hogy valami felette újraindítja-e a folyamatot a kilépése után. Ha csak az egyiket javítja, a másik rés nyitva marad.

Abból induljon ki, amit az egység valóban tett, ne abból, amit a megfigyelés állít. A systemctl status openvpn-client@office és a journalctl -u openvpn-client@office -n 50 mutatja a kilépés okát és az utolsó sort, amelyet a kliens távozása előtt írt.

A folyamat azelőtt kilépett, hogy bárki észrevette volna

A hiba nélkül eltűnő kliens általában szándékosan lépett ki. Ezt a viselkedést a profil dönti el, nem a szolgáltatáskezelő: a ping-exit azonnal lezárja a folyamatot, amint a másik fél nem válaszol, míg a ping-restart megtartja a folyamatot, és azon belül kapcsolódik újra. A munkamenet-korlátok és az inaktivitási időzítők kívülről ugyanazt a képet adják: alagút nélkül és riasztás nélkül.

A két ping-utasítás nem szerepelhet egyszerre egy profilban, ezért válasszon egyet, és jegyezze fel a döntést. Nézze meg a kiszolgálót is, mert a saját ping-exit attól függetlenül zárja le a munkamenetet, hogy a kliens mit kért, és csak a kiszolgáló naplója rögzíti, ki hozta ezt a döntést.

Választás a ping-exit és a ping-restart között

Válassza a ping-restart beállítást laptop vagy távoli hely számára, amelynek magától meg kell gyógyulnia, a ping-exit beállítást pedig tartsa meg azokra az esetekre, amikor egy halott alagútnak le kell állítania a folyamatot, hogy valami más reagálhasson rá. A számok kevésbé fontosak, mint a kapcsolat: a ping 10 a ping-restart 60 mellett tíz másodperc csendet jelent a vizsgálat előtt és hatvanat az újraindítás előtt, ami veszteséges mobil linken agresszív, vezetékesen pedig ésszerű. Írja oda az okot a sor mellé, különben a következő olvasó azt hiszi, hogy az alapértékek szándékosak voltak.

Utána erősítse meg, hogy valóban a folyamat lépett ki. Az az egység, amely a halott alagút mellett aktívnak jelentkezik, más hiba, amelyet lentebb tárgyalunk.

Olyan felügyelet, amely valóban újraindítja az egységet

systemd gazdagépen a legkisebb tartós változás egyetlen drop-in fájl: a Restart=on-failure és a RestartSec=10 a /etc/systemd/system/[email protected]/restart.conf fájlban. A drop-in csak akkor olvasódik be, amikor a systemd újratölti a saját definícióit, ezért utána futtassa a systemctl daemon-reload parancsot. Ellenőrizze a systemctl show -p Restart -p ExecMainStatus openvpn-client@office paranccsal, ahelyett hogy feltételezné, hogy az érték megérkezett. A fájlnévben szereplő példánynak annak a profilnak kell lennie, amelyet az egység valóban betölt, ezért a office számára írt fájl semmit sem tesz a openvpn-client@home esetében.

A on-failure egy esetet figyelmen kívül hagy: a nulla állapotú tiszta kilépést. Egyes lebontási útvonalak így végződnek, ezért olvassa a rögzített állapotot, ne bízzon a kézikönyv oldalának megfogalmazásában. Ha a kliense nullával adja fel, a Restart=always kell, és ennek ára, hogy egy valóban törött profil újra meg újra visszatér, amíg az indítási sebességkorlát be nem lép, és a napló meg nem telik.

A Restart=always szándékos leállítás után is aktiválódik. Karbantartáshoz használja a systemctl stop parancsot, és maszkolja az egységet, ha a munka alatt leállítva kell maradnia.

Kapja el a szivárgást, amíg az alagút le van állva

A felügyelet visszahozza az alagutat; nem akadályozza meg, hogy a forgalom kimenjen, amíg az alagút nincs ott. A persist-tun megtartja az eszközt és az útvonalait az újracsatlakozások között, ami kényelmes, és ablakot nyit. Az eszköz túléli, az útvonalak továbbra is rá mutatnak, és a csomagok védelem nélkül, jelentés nélkül folynak ki. Ez szabályzati döntés, nem semleges alapérték.

Amikor egy gazdagép egyáltalán nem bocsáthat ki védtelen csomagokat, ezt csak a tűzfal garantálhatja. Egy kimeneti szabály, amely engedi az alagút interfészét és a VPN-kiszolgáló címét, minden mást pedig eldob, a kliens halála után is érvényben marad, és a kliens saját konfigurációjában semmi nem tudja szűrni azt a forgalmat, amelyet a kliens nem továbbít.

Tesztelje úgy, hogy szándékosan leállítja a klienst. Futtassa a systemctl stop openvpn-client@office parancsot, majd a curl -m 5 https://example.com parancsot, amelynek a fizikai linken inkább meg kell hiúsulnia, mint sikerülnie. A siker azt jelenti, hogy a tűzfalszabály hiányzik, vagy túl engedékeny.

Csatlakozzon újra, erősítse meg, hogy az alagút ismét forgalmat továbbít, és csak ezután adja hozzá az ellenőrzést a megfigyeléshez. A ip addr cronból történő lekérdezése egy tun eszközhöz a leggyakrabban meghiúsuló felügyelet, mert a persist-tun mellett az eszköz túléli a munkamenetet, és a vizsgálat egészséget jelent, miközben semmi sem továbbítódik.