OpenVPN som starter før nettverket er oppe, er ingen feil

Du starter klienten ved oppstart, enheten melder aktiv, og tunnelen er ikke der. Den naturlige slutningen er at tjenesten ikke startet, og den naturlige rettelsen er å starte den igjen. Begge er feil ofte nok til å fortjene en regel: en kjørende klient som prøver på nytt ser nøyaktig ut som en ødelagt en fra utsiden. Forskjellen ligger i hva prosessen gjør, ikke i enhetens tilstand.

Myte: en startet tjeneste betyr en tunnel som virker

En aktiv enhet beviser at prosessen ble startet og ikke har avsluttet. Den beviser ikke at profilen ble lastet, at sertifikatet ble godtatt, eller at den andre enden svarte. En pakket klient kan sitte i en løkke med nye forsøk i minutter mens systemd ikke melder annet enn suksess. Det gapet mellom tilstand og atferd er hele saken.

Det motsatte tilfellet er like vanlig. Prosessen kan ha avsluttet etter å ikke ha klart å lese en nøkkel, og enheten melder da en feiltilstand som ikke sier noe om hvorfor. Begge tilstandene trenger loggen for å skilles.

Les journalen for instansen i stedet for enhetens tilstand. Årsakslinjen står i loggen, ikke i statusetiketten.

Myte: innstillinger for nye forsøk dekker alle feil

Navneoppslag og transportnytt er separate kontroller med separate standardverdier. resolv-retry styrer gjentatte oppslag av et eksternt vertsnavn, og den dokumenterte standardverdien fortsetter å prøve på ubestemt tid. connect-retry setter intervallet mellom forsøk, mens connect-retry-max kan begrense hvor mange ganger hver ekstern oppføring prøves. Sjekk hvilket trinn loggen navngir før du endrer noen av dem.

Ingenting av dette gjelder en ødelagt profil, en uleselig privatnøkkel eller en avvist konto. De trenger en rettelse, og en klient som fortsetter å prøve dem gjør ingen fremgang.

Å prøve et ikke-godkjent sertifikat for alltid er ikke grunn til å fjerne verifiseringen. Det er grunn til å lese feilen.

Myte: én oppstarter er nok, så legg til en til

En tilkobling som allerede styres av NetworkManager eller en pakket enhet, trenger ikke en andre oppstarter festet til seg. To prosesser som konkurrerer om de samme rutene gir dupliserte grensesnitt, forvirrede logger og en tunnel som blafrer av grunner ingen kan se. Den andre kopien kommer vanligvis som en omvei fordi den første er treg.

Bestem hvilken komponent som eier tunnelen før du legger til noe. Fjern deretter den andre oppstarteren i stedet for å deaktivere den og håpe.

Eieren avgjør også hvor nye forsøk og påloggingsinformasjon kommer fra, og derfor kommer denne beslutningen før noe justeres. Eierskap kommer først nettopp av den grunn.

Hva som faktisk trenger rekkefølge

Rekkefølge kan vente på en konfigurert adresse, og det er alt den garanterer. network-online.target utsetter aktivering til behandleren anser nettverket som oppe, og definisjonen av oppe avhenger av behandleren. Den sier ingenting om VPN-vertsnavnet løses opp, om lytteren svarer, eller om en captive portal har sluppet enheten inn.

Les den installerte enheten og eventuelle drop-ins før du legger til avhengigheter. En bred After= på hver nettverkstjeneste utsetter oppstarten uten å opprette tilkoblingen du faktisk trenger.

Sett rekkefølge på avhengigheten du kan teste, og sjekk alt annet med en beredskapsprobe. En probe som åpner tunnelen slår en timer som gjetter.

Hva som skjer etter at tunnelen først kommer opp

Oppstart er én hendelse blant mange. Aksesslenken endres, en portallsøkt utløper, motparten starter på nytt. Skill en intern gjenoppkobling fra en prosessavslutning som tjenestebehandleren håndterer, fordi de to har forskjellige eiere og etterlater forskjellige spor.

Interaktiv autentisering begrenser ubemannet gjenoppretting. En bakgrunnsenhet låser ikke opp en skrivebordsnøkkelring eller svarer på en MFA-forespørsel, så følg den godkjente legitimasjonsordningen for tjenestekonteksten.

Bestem separat hva applikasjoner kan gjøre mens tunnelen er nede. Nye forsøk gjenoppretter en tilkobling, mens en blokkeringspolicy avgjør om direkte trafikk er tillatt i gapet.