OpenVPN som startar innan nätverket är uppe är inget fel

Du startar klienten vid uppstart, enheten rapporterar aktiv och tunneln finns inte. Den naturliga slutsatsen är att tjänsten misslyckades med att starta, och den naturliga rättelsen är att starta den igen. Båda är fel tillräckligt ofta för att förtjäna en regel: en körande klient som försöker igen ser från utsidan exakt ut som en trasig. Skillnaden ligger i vad processen gör, inte i enhetens tillstånd.

Myt: en startad tjänst betyder en fungerande tunnel

En aktiv enhet bevisar att processen startades och inte har avslutats. Den bevisar inte att profilen laddades, att certifikatet godtogs eller att andra änden svarade. En paketerad klient kan sitta i en återförsöksslinga i minuter medan systemd inte rapporterar annat än framgång. Glappet mellan tillstånd och beteende är hela ämnet.

Det motsatta fallet är lika vanligt. Processen kan ha avslutats efter att ha misslyckats med att läsa en nyckel, och enheten rapporterar då ett feltillstånd som inte säger något om varför. Båda tillstånden behöver loggen för att skiljas åt.

Läs journalen för instansen i stället för enhetens tillstånd. Orsaksraden finns i loggen, inte i statusetiketten.

Myt: inställningar för återförsök täcker alla fel

Namnuppslagning och transportåterförsök är separata kontroller med separata standardvärden. resolv-retry styr upprepade uppslagningar av ett fjärranslutet värdnamn, och det dokumenterade standardvärdet fortsätter att försöka i oändlighet. connect-retry anger intervallet mellan försök, medan connect-retry-max kan begränsa hur många gånger varje fjärrpost prövas. Kontrollera vilket steg loggen anger innan du ändrar någon av dem.

Inget av detta gäller en felaktig profil, en oläsbar privat nyckel eller ett avvisat konto. De behöver en rättelse, och en klient som fortsätter att försöka gör inga framsteg.

Att försöka med ett icke godkänt certifikat i evighet är inte skäl att ta bort verifieringen. Det är skäl att läsa felet.

Myt: en startare räcker, så lägg till en till

En anslutning som redan hanteras av NetworkManager eller en paketerad enhet behöver ingen andra startare. Två processer som konkurrerar om samma rutter ger dubbla gränssnitt, förvirrade loggar och en tunnel som fladdrar av skäl ingen ser. Den andra kopian kommer vanligtvis som en kringgång eftersom den första är långsam.

Bestäm vilken komponent som äger tunneln innan du lägger till något. Ta sedan bort den andra startaren i stället för att inaktivera den och hoppas.

Ägaren avgör också var återförsök och inloggningsuppgifter kommer från, och därför kommer detta beslut före all justering. Ägarskap kommer först just av det skälet.

Vad som faktiskt behöver ordning

Ordning kan vänta på en konfigurerad adress, och det är allt den garanterar. network-online.target fördröjer aktiveringen tills hanteraren anser att nätet är uppe, och definitionen av uppe beror på hanteraren. Den säger inget om VPN-värdnamnet löses upp, om lyssnaren svarar eller om en captive portal har släppt in enheten.

Läs den installerade enheten och eventuella drop-ins innan du lägger till beroenden. En bred After= på varje nätverkstjänst fördröjer uppstarten utan att upprätta den anslutning du faktiskt behöver.

Ordna beroendet du kan testa, och kontrollera allt annat med en beredskapsprob. En prob som öppnar tunneln slår en timer som gissar.

Vad som händer efter att tunneln först kommer upp

Uppstart är en händelse bland många. Åtkomstlänken ändras, en portalsession löper ut, motparten startar om. Skilj en intern återanslutning från en processavslutning som tjänstehanteraren hanterar, eftersom de två har olika ägare och lämnar olika spår.

Interaktiv autentisering begränsar obemannad återhämtning. En bakgrundsenhet låser inte upp en skrivbordsnyckelring och svarar inte på en MFA-förfrågan, så följ den godkända ordningen för inloggningsuppgifter i tjänstekontexten.

Bestäm separat vad applikationer får göra medan tunneln ligger nere. Återförsök återställer en anslutning, medan en blockeringspolicy avgör om direkt trafik tillåts i glappet.