A VPN csak bejelentkezés után működik a kulcstartó miatt

A parancs működik, amikor be van jelentkezve, ezért beteszi egy indítási szkriptbe, és hazamegy. Másnap reggel a gép online van, az alagút nem. A mítosz az, hogy a működő hívás működő szolgáltatás. A gyakorlatban a különbség általában két dolog egyike: a profil az Ön felhasználói munkamenetéhez tartozik, nem a rendszerhez, vagy a titkot valami olyan oldja fel, ami csak a bejelentkezés után létezik. Mindkettő tökéletesen működik kézi tesztben, és pontosan abban a pillanatban vall kudarcot, amikor senki sem figyel.

Miért működik tőle a bejelentkezés

A grafikus bejelentkezés elindít egy munkamenet-buszt és egy titokszolgáltatás-ügynököt, és itt tárolják sok asztali kliensek a profil jelszavát vagy a privát kulcs jelmondatát. A bejelentkezés után az Ön felhasználójaként futó aktiválás kérheti a titkot attól az ügynöktől, és sikerülhet. Ugyanaz az aktiválás, amelyet egy indítási egység hajt végre, nem rendelkezik munkamenettel, busszal és ügynökkel, ezért a keresés meghiúsul, vagy elakad egy olyan kérésnél, amelyet senki sem lát.

Futtassa ugyanazt a profilt bejelentkezés előtt és után, és egy konfigurációból két különböző eredményt kap. Ez a hitelesítő adatoktól való függés jele, nem a törött alagúté, és megmagyarázza, miért bizonyít kevesebbet egy terminálban végzett kézi teszt, mint aminek látszik. Az alagút rendben van; hiányzik az, ami feloldja a titkát.

Döntse el, melyik tulajdonos indítja az alagutat

Két támogatott minta létezik, és ezek keverése a másik módja annak, hogy ez elbukjon. A NetworkManager rendszerszintű kapcsolatot aktiválhat, ami akkor megfelelő, ha a gép már ott központosítja a hálózatát. Alternatívaként egy dedikált systemd egység közvetlenül futtatja a VPN-t, és maga birtokolja az interfészt.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

Ne futtassa mindkét tulajdonost egy konfiguráció ellen. Ha a NetworkManager kezeli az interfészt, és egy egység is felhozza, harcolni fognak az útvonalakért és a DNS-ért, és a kialakuló állapot attól függ, ki végzett utoljára.

Tegye a titkot oda, ahol egy szolgáltatás olvashatja

Egy háttérszolgáltatás nem tud válaszolni egy kérésre. A tanúsítvány-jelmondatok, a fiókjelszavak és a hivatkozott hitelesítési fájlok mind olyan tárolási elrendezést igényelnek, amelyet az egység ember nélkül elér, a szolgáltatást futtató fiók birtokol, és mindenki más számára olvashatatlan.

A csábító rövidítés az, hogy a fájlt mindenki számára olvashatóvá tesszük, amíg az engedélyhiba el nem tűnik. Ez egy indítási hibát cserél le egy hosszú életű hitelesítőadat-kitettségre, és ez az a fajta változás, amelyhez senki sem tér vissza. Használja azt a mechanizmust, amelyben a telepítés már bízik: korlátozott hitelesítőadat-fájl, fájlengedélyekkel védett titkosítatlan kulcs, vagy saját titoktárral rendelkező rendszerszintű kapcsolat.

Tesztelje az eseményt, amely valóban megtörténik

A szolgáltatás kézi indítása bejelentkezés után szinte semmit sem tesztel. Indítsa újra, vagy egy ciklusra tiltsa le a grafikus bejelentkezést, és figyelje, ahogy az egység magától feljön. Ez az egyetlen teszt, amely egyszerre gyakorolja a hitelesítő adatok elérhetőségét, a hálózat készségét és az egységek sorrendjét. Ez az a teszt is, amely reprodukálja a felhasználó által jelentett hibát, amit a kézi indítás soha nem tesz.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

A sorrend ugyanolyan fontos, mint a hitelesítő adatok. Egy egység, amely a mögöttes feltöltő kapcsolat konfigurálása előtt indul, feladja, és egyes disztribúciók abban különböznek, hogy megvárják-e a kapcsolatot. Ha az egység indításkor hibát jelent, de harminc másodperccel később kézzel indítva sikerül, sorrendi problémát talált, nem titokproblémát.

Ellenőrizze az útvonalakat és a DNS-t, ne csak az interfészt

Egy létező interfész nem működő alagút. Felügyelet nélküli indítás után ellenőrizze az útvonalakat, a feloldó állapotát és egy célállomást cím szerint, mielőtt egy nevet ellenőrizne. Ezután ellenőrizze azt az alkalmazást, amelyért az alagút létezik.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Ha a cím működik és a név nem, a fennmaradó probléma a DNS-szabályzat, nem az alagút. Jegyezze fel, melyik tulajdonos indítja a szolgáltatást és hol él a titok, mert a következő embernek, aki újraindítja ezt a gépet, mindkét tényre szüksége lesz.