OpenVPN som start før nettet er oppe, er ingen feil

Du startar klienten ved oppstart, eininga melder aktiv, og tunnelen er ikkje der. Den naturlege slutninga er at tenesta ikkje starta, og den naturlege rettinga er å starte ho på nytt. Båe er feil ofte nok til å fortjene ei regel: ein køyrande klient som prøver på nytt ser nøyaktig ut som ein øydelagd ein frå utsida. Skilnaden ligg i kva prosessen gjer, ikkje i tilstanden til eininga.

Myte: ei starta teneste tyder ein tunnel som verkar

Ei aktiv eining viser at prosessen vart starta og ikkje har avslutta. Ho viser ikkje at profilen vart lasta, at sertifikatet vart godteke, eller at den andre enden svara. Ein pakka klient kan sitje i ei løkke med nye forsøk i minuttar medan systemd ikkje melder anna enn suksess. Det gapet mellom tilstand og åtferd er heile saka.

Det motsette tilfellet er like vanleg. Prosessen kan ha avslutta etter å ikkje ha klart å lese ein nøkkel, og eininga melder då ein feiltilstand som ikkje seier noko om kvifor. Båe tilstandane treng loggen for å skiljast.

Les journalen for instansen i staden for tilstanden til eininga. Årsakslinja står i loggen, ikkje i statusetiketten.

Myte: innstillingar for nye forsøk dekkjer alle feil

Namneoppslag og transportnytt er separate kontrollar med separate standardverdiar. resolv-retry styrer gjentekne oppslag av eit eksternt vertsnamn, og den dokumenterte standardverdien held fram å prøve på ubestemt tid. connect-retry set intervallet mellom forsøk, medan connect-retry-max kan avgrense kor mange gonger kvar ekstern oppføring vert prøvd. Sjekk kva trinn loggen nemner før du endrar nokon av dei.

Ingenting av dette gjeld ein øydelagd profil, ein uleseleg privatnøkkel eller ein avvist konto. Dei treng ei retting, og ein klient som held fram å prøve dei gjer ingen framgang.

Å prøve eit ikkje-godkjent sertifikat for alltid er ikkje grunn til å fjerne verifiseringa. Det er grunn til å lese feilen.

Myte: éin oppstartar er nok, så legg til ein til

Ei tilkopling som allereie vert styrt av NetworkManager eller ei pakka eining, treng ikkje ein andre oppstartar fest til seg. To prosessar som kjempar om dei same rutene gjev doble grensesnitt, forvirra loggar og ein tunnel som blafrar av grunnar ingen kan sjå. Den andre kopien kjem vanlegvis som ein omveg fordi den første er treg.

Avgjer kva komponent som eig tunnelen før du legg til noko. Fjern deretter den andre oppstartaren i staden for å deaktivere han og håpe.

Eigaren avgjer òg kvar nye forsøk og påloggingsinformasjon kjem frå, og difor kjem denne avgjerda før noko vert justert. Eigarskap kjem først nettopp av den grunn.

Kva som faktisk treng rekkjefølgje

Rekkjefølgje kan vente på ei konfigurert adresse, og det er alt ho garanterer. network-online.target utset aktiveringa til behandlaren reknar nettet som oppe, og definisjonen av oppe avheng av behandlaren. Ho seier ingenting om VPN-vertsnamnet vert løyst opp, om lyttaren svarar, eller om ein captive portal har sleppt eininga inn.

Les den installerte eininga og eventuelle drop-ins før du legg til avhengnader. Ein brei After= på kvar nettverksteneste utset oppstarten utan å opprette tilkoplinga du faktisk treng.

Set rekkjefølgje på avhengnaden du kan teste, og sjekk alt anna med ein beredskapsprobe. Ein probe som opnar tunnelen slår ein timer som gissar.

Kva som skjer etter at tunnelen først kjem opp

Oppstart er éi hending blant mange. Aksesslenkja endrar seg, ei portalsøkt går ut, motparten startar på nytt. Skil ei intern gjenoppkopling frå ei prosessavslutting som tenestebehandlaren handterer, fordi dei to har ulike eigarar og etterlet ulike spor.

Interaktiv autentisering avgrensar ubemanna gjenoppretting. Ei bakgrunneining låser ikkje opp ein skrivebordsnøkkelring eller svarar på ein MFA-førespurnad, så fylg den godkjende legitimasjonsordninga for tenestekonteksten.

Avgjer separat kva applikasjonar kan gjere medan tunnelen er nede. Nye forsøk gjenopprettar ei tilkopling, medan ein blokkeringspolicy avgjer om direkte trafikk er tillaten i gapet.