OpenVPN Ubuntu indításakor: NetworkManager vagy systemd?

A legtöbb útmutató kozmetikai kérdésként tálalja a választást: vagy hagyja, hogy a NetworkManager felhozza az alagutat, vagy engedélyezzen egy systemd-példányt, és kész. A két útvonal egyetlen dologban tér el, amely eldönti az eredményt egy képernyő nélküli gépen, és annak semmi köze ahhoz, melyik eszköz újabb. A NetworkManager munkameneten keresztül nyitja fel a titkokat; egy systemd-példánynak nincs munkamenete, amit felnyithatna. Azt válassza, amelynek titokkezelése illik az előtte álló géphez.

Minden más, az útvonalak telepítésétől az újracsatlakozás viselkedéséig, ebből az első döntésből következik.

A kulcstartó az a különbség, amiről senki nem beszél

Amikor a NetworkManager birtokol egy VPN-profilt, a jelszó a bejelentkezési kulcstartóban élhet, amely akkor nyílik fel, amikor egy felhasználó bejelentkezik. Ez jól működik hordozható gépen: a személy jelen van, a kulcstartó kinyílik, az alagút feljön. Egy felügyelet nélkül induló kiszolgálón nincs, aki bármit is felnyisson, ezért a profil olyan titokra vár, amely soha nem érkezik meg. A kapcsolat beállítottnak látszik, és soha nem aktiválódik.

A systemd-példány elkerüli ezt a problémát azzal, hogy hitelesítő fájlt olvas a lemezről, ami a fájlt teszi azzá, amit véd. chmod 400 plusz a root tulajdona a minimum, és a fájlnak távol kell maradnia azoktól a biztonsági mentésektől és lemezképsablonoktól, amelyeket nem Ön ellenőriz.

A VPN kapcsolathoz csatolása nem indítási garancia

A nm-connection-editor felületen a VPN helyett a vezetékes vagy vezeték nélküli kapcsolatot válassza, nyissa meg a General lapot, pipálja ki az automatikus VPN-csatlakozás lehetőségét, és nevezze el a profilt. Ezután a NetworkManager másodlagos kapcsolatként aktiválja a VPN-t, amikor az elsődleges eléri a csatlakoztatott állapotot. Ez függőség, nem tűzfalszabály. A csomagok még mindig kimehetnek az alagút feljövetele előtti másodpercekben, és egy tárolt titok, amelyet nem sikerül felnyitni, az alagút nélkül hagyja a gépet online.

Ha az a követelmény, hogy semmi ne menjen ki az alagút nélkül, mondja ki, és építsen kill switch-et, mert ez a beállítás nem ad egyet. A felfüggesztést és a folytatást is tesztelje, mert a másodlagos kapcsolat a visszatéréskor újraértékelődik.

A systemd-példánynak egyező fájlnévre van szüksége

Helyezze a profilt abba az ügyfélkönyvtárba, amelyet a csomag elvár, például /etc/openvpn/client/office.conf, és belülről hivatkozzon a hitelesítő fájlra a auth-user-pass office.cred használatával. A példány neve a fájlnév kiterjesztés nélkül, tehát a openvpn-client@office a office.conf fájlt olvassa. Engedélyezze a sudo systemctl enable --now openvpn-client@office paranccsal, és erősítse meg a hozzárendelést a systemctl cat openvpn-client@office paranccsal, ahelyett hogy egy blog példájában bízna.

A profilon belüli útvonalak az egység munkakönyvtárához viszonyítva oldódnak fel, nem magához a profilhoz, ezért egy relatív ca vagy auth-user-pass sor induláskor meghiúsulhat, miközben kézi teszteléskor működik. Használjon abszolút útvonalakat mindenhez, amit az egységnek meg kell találnia. Ezután egy valódi indítás után olvassa el a journalctl -u openvpn-client@office -b kimenetét; az az egység, amely alagút nélkül jelent aktív állapotot, általában megnevez egy hiányzó fájlt abban a naplóban.

A régebbi csomagok más sablonnevet szállítanak, ezért a systemctl list-unit-files 'openvpn*' eldönti, melyik létezik ezen a gazdagépen.

Az újracsatlakozás viselkedése külön döntés

A ping-restart beállítást tartalmazó profil újraépíti az alagutat, miután az leesett, az újraindítási direktívát tartalmazó egység pedig hasonlót tesz szolgáltatási szinten. Ezek az Ön által választott szabályzatok, nem örökölt alapértékek. Ha a kapcsolatnak csak igény szerint kell feljönnie, szándékosan távolítsa el az újraindítási viselkedést, és írja le, miért. Ha az egység a hálózat használhatóvá válása előtt indul, újrapróbálkozási szabályzatra van szüksége, mert egy sikertelen indítási kísérlet nem ismétlődik magától.

A leállítás ugyanolyan szó szerinti: a sudo systemctl disable --now openvpn-client@office leállítja a futó példányt, és eltávolítja az indítási hivatkozást. Az önmagában való letiltás az alagutat a következő újraindításig futva hagyja, ami mindenkit meglep, aki letiltással tesztel, és látja, hogy az interfész fent marad.

Indítsa újra, majd ellenőrizzen négy dolgot sorrendben

A szolgáltatás újraindítása a szolgáltatást teszteli; a gép újraindítása az indítási útvonalat. Az újraindítás után erősítse meg, hogy az egység feljött, majd hogy létezik útvonal a távoli alhálózathoz, majd hogy milyen címet mutat a gép az internet felé, végül hogy a nevek az alagúton keresztül oldódnak fel. Ez a négy ellenőrzés ebben a sorrendben hibázik, amikor valami baj van, ami az első hibát teszi hasznossá.

Az útvonal nélkül aktív egység általában azt jelenti, hogy a profil csatlakozott, de a kiszolgáló nem küldött útvonalat, vagy az útvonal olyan interfészre települt, amely később eltűnt. A működő névfeloldás nélküli útvonal a DNS-beállításra mutat, nem magára az alagútra.

Döntse el előre, mi történjen, ha az alagút nem tud feljönni. A visszaesés egyszerű kapcsolódásra szabályzat, és le kell írni, ahelyett hogy arra a kezelőre hagynák, amelyik először elindult.