Hvorfor en VPN-enhet starter før nettverket og deretter dør

Start maskinen, logg inn, og oppdag at tunnelen kom opp og døde noen sekunder senere. Profilen var i orden, sertifikatet var i orden, og det eneste sporet som er igjen, er journalen fra den oppstarten. Det som vanligvis skjedde, er et kappløp: enheten startet før maskinen hadde en adresse, og rekkefølgen den erklærte, betydde ikke det den ser ut som. Alt nedenfor handler om å bevise det kappløpet ut fra bevis og lukke det ordentlig.

Målet er et møtepunkt, ikke en administrator

network-online.target aner ikke hva et nettverk er. Det er et koordineringspunkt som samler tjenesten som skal utsette oppstarten til forbindelsen er brukbar, og det delegerer definisjonen til den nettverksadministratoren som eier maskinen. På de fleste stasjonære maskiner og servere betyr det en ventetjeneste som leveres av NetworkManager eller av systemd-networkd. Aktiverer du ingen av dem, har målet ingenting å vente på, så det fullføres i det øyeblikket noe trekker det inn, noe som kan være lenge før DHCP svarer. Rekkefølgelinjen i enheten din var ærlig og likevel ubrukelig.

Det første spørsmålet er derfor ikke hva enheten din erklærer. Det er om noe på denne maskinen faktisk utfører ventingen.

Les den siste oppstarten i stedet for enhetsfilen

Enhetsfiler beskriver hensikt, og journalen beskriver hva som skjedde. Be bare om den oppstarten, med monotone tidsstempler slik at hver melding sitter på én klokke. Finn deretter to linjer: øyeblikket da tunnel-enheten begynte å starte, og øyeblikket da adressen dukket opp eller ventetjenesten ble ferdig. Sorter de to tallene, og kappløpet er enten bekreftet eller utelukket.

Avhengighetsvisningen bekrefter det. Hvis en kritisk kjede for tunnel-enheten ikke inneholder noen ventetjeneste, utsatte ingenting på den veien oppstarten, og målet gjorde ikke arbeidet du antok. To visninger, én konklusjon.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Legg til ventingen, deretter det nye forsøket

Bruk en drop-in i stedet for å redigere en pakket enhet, slik at en pakkeoppdatering ikke stilltiende forkaster endringen. To direktiver betyr noe: enheten må være ordnet etter målet, og den må trekke målet inn i samme transaksjon. Orden alene tilkaller ikke målet; ønsket gjør det.

Den pakkede enheten for OpenVPN-klienten bærer allerede begge. Håndskrevne enheter bærer vanligvis én eller ingen, noe som er verdt å sjekke før du legger til noe.

[Service]
Restart=on-failure
RestartSec=15

Hvorfor en fast søvn er en felle

En søvn i ExecStartPre føles som en ordensreparasjon og oppfører seg som en forsinkelse med ekstra trinn. Den bremser hver oppstart, også de som var sunne, og den taper fortsatt når forbindelsen tar lengre tid enn tallet du valgte.

Verre, den skjuler om ventetjenesten virker, så den neste feilen fremstår som et helt nytt problem i stedet for det samme med en annen timing. En kort omstartsforsinkelse er det bedre instrumentet: den koster ingenting ved en sunn oppstart og gjør et tapt kappløp om til et nytt forsøk. Hold intervallet beskjedent og la enheten lykkes. Hvis den starter på nytt for alltid, er profilen ødelagt og ingen mengde nye forsøk endrer det, så les loggen i stedet for å øke intervallet.

Når rekkefølgen er riktig og navnene likevel feiler

En aktiv enhet med en tunnelrute betyr at rekkefølgen gjorde jobben sin, og at den gjenværende feilen sitter ett lag høyere oppe. Den vanlige formen er en resolver-innstilling som tunnelens up-skript bruker før forbindelsen eller resolveren var klar til å holde på den. Sammenlign resolverens tilstand under feilen med tilstanden etter en omstart av tunnel-enheten.

Hvis omstarten retter oppslag, har du en oppstartsrekkefølgefeil og ikke en feil DNS-server, og de to trenger forskjellige rettelser. Bevis deretter det hele med en kald oppstart i stedet for en tjenesteomstart, fordi omstart kjører mot et nettverk som allerede er oppe, og vil skjule nøyaktig den feilen du jager. Gjenta det med forbindelsen bevisst treg, og behandle en enhet som bare virker når nettverket er raskt, som fortsatt ødelagt.