Az OpenVPN hálózat előtti indítása nem hiba

A rendszerindításkor elindítja az ügyfelet, az egység aktívnak jelenti magát, és az alagút nincs ott. A természetes következtetés az, hogy a szolgáltatás nem indult el, a természetes javítás pedig az, hogy újraindítja. Mindkettő elég gyakran téves ahhoz, hogy szabályt érdemeljen: egy futó ügyfél, amely újrapróbálkozik, kívülről pontosan úgy néz ki, mint egy hibás. A különbség abban van, mit tesz a folyamat, nem az egység állapotában.

Mítosz: az elindult szolgáltatás működő alagutat jelent

Egy aktív egység bizonyítja, hogy a folyamatot elindították, és nem lépett ki. Nem bizonyítja, hogy a profil betöltődött, a tanúsítványt elfogadták, vagy a túloldal válaszolt. Egy csomagolt ügyfél percekig ülhet újrapróbálkozási hurokban, miközben a systemd csak sikerről számol be. Az állapot és a viselkedés közötti ez a szakadék az egész téma.

Az ellenkező eset ugyanilyen gyakori. A folyamat kiléphetett, miután nem tudott beolvasni egy kulcsot, és az egység ekkor sikertelen állapotot jelent, amely semmit nem mond az okról. Mindkét állapot megkülönböztetéséhez a napló kell.

Az egység állapota helyett az adott példány naplóját olvassa. Az okot tartalmazó sor a naplóban van, nem az állapotcímkében.

Mítosz: az újrapróbálkozási beállítások minden hibát lefednek

A névfeloldás és a szállítási újrapróbálkozások külön vezérlők külön alapértékekkel. A resolv-retry a távoli gazdanév ismételt lekérdezéseit vezérli, és a dokumentált alapérték korlátlanul próbálkozik. A connect-retry a kísérletek közötti időközt állítja be, míg a connect-retry-max korlátozhatja, hogy egy-egy távoli bejegyzést hányszor próbálnak meg. Mielőtt bármelyiket módosítaná, ellenőrizze, melyik szakaszt nevezi meg a napló.

Ebből semmi nem vonatkozik a hibás profilra, az olvashatatlan titkos kulcsra vagy az elutasított fiókra. Ezek javítást igényelnek, és az ügyfél, amely folyton újrapróbálja őket, nem halad.

Egy nem jóváhagyott tanúsítvány végtelen újrapróbálkozása nem ok az ellenőrzés eltávolítására. Ok arra, hogy elolvassa a hibát.

Mítosz: egy indító elég, ezért adjon hozzá még egyet

Az a kapcsolat, amelyet már a NetworkManager vagy egy csomagolt egység kezel, nem igényel második indítót. Két folyamat, amely ugyanazokért az útvonalakért verseng, duplikált interfészeket, zavaros naplókat és olyan alagutat hoz létre, amely senki számára nem látható okokból leng. A második példány általában azért érkezik kerülőútként, mert az első lassú.

Döntse el, melyik komponens birtokolja az alagutat, mielőtt bármit hozzáad. Ezután távolítsa el a másik indítót, ahelyett hogy letiltaná és reménykedne.

A tulajdonos azt is meghatározza, honnan jönnek az újrapróbálkozások és a hitelesítő adatok, ezért ez a döntés minden hangolás előtt áll. A tulajdonjog pontosan ezért jön előre.

Minek van valóban szüksége sorrendre

A sorrend várhat egy beállított címre, és ez minden, amit garantál. A network-online.target késlelteti az aktiválást, amíg a kezelő a hálózatot felálltnak nem tekinti, a felállt definíciója pedig a kezelőtől függ. Semmit nem mond arról, hogy feloldódik-e a VPN gazdanév, válaszol-e a figyelő, vagy beengedte-e az eszközt egy fogságba ejtett portál.

A függőségek hozzáadása előtt olvassa el a telepített egységet és minden drop-in fájlt. Egy széles After= minden hálózati szolgáltatáson késlelteti az indítást anélkül, hogy létrehozná a valóban szükséges kapcsolatot.

Rendezze sorba a tesztelhető függőséget, és minden mást készenléti szondával ellenőrizzen. Az alagutat megnyitó szonda jobb, mint egy tippelő időzítő.

Mi történik, miután az alagút először feljön

Az indítás egy esemény a sok közül. A hozzáférési kapcsolat változik, egy portál munkamenet lejár, a partner újraindul. Különböztesse meg a belső újracsatlakozást attól a folyamatkilépéstől, amelyet a szolgáltatáskezelő kezel, mert a kettőnek különböző tulajdonosai vannak, és különböző bizonyítékokat hagy.

Az interaktív hitelesítés korlátozza a felügyelet nélküli helyreállítást. Egy háttéregység nem nyitja ki az asztali kulcstartót, és nem válaszol MFA-kérésre, ezért kövesse a szolgáltatáskörnyezethez jóváhagyott hitelesítőadat-elrendezést.

Külön döntse el, mit tehetnek az alkalmazások, amíg az alagút le van állva. Az újrapróbálkozás helyreállítja a kapcsolatot, míg egy blokkolási szabályzat eldönti, hogy a résben engedélyezett-e a közvetlen forgalom.