Hvorfor en VPN-unit starter før netværket og derefter dør

Start maskinen, log ind, og erfar, at tunnelen kom op og døde få sekunder senere. Profilen var i orden, certifikatet var i orden, og det eneste spor, der er tilbage, er journalen fra den opstart. Det, der normalt skete, er et kapløb: unitten startede, før maskinen havde en adresse, og den rækkefølge, den erklærede, betød ikke det, den ser ud som. Alt nedenfor handler om at bevise det kapløb ud fra beviser og lukke det ordentligt.

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

network-online.target aner ikke, hvad et netværk er. Det er et koordinationspunkt, der samler den tjeneste, som skal forsinke opstarten, indtil forbindelsen er brugbar, og det uddelegerer definitionen til den netværksadministrator, der ejer maskinen. På de fleste stationære computere og servere betyder det en ventetjeneste, som leveres af NetworkManager eller af systemd-networkd. Aktiverer du ingen af dem, har målet intet at vente på, så det fuldføres i det øjeblik, noget trækker det ind, hvilket kan være længe før DHCP svarer. Rækkefølgelinjen i din unit var ærlig og stadig ubrugelig.

Det første spørgsmål er derfor ikke, hvad din unit erklærer. Det er, om noget på denne maskine faktisk udfører ventetiden.

Læs den sidste opstart i stedet for unitfilen

Unitfiler beskriver hensigt, og journalen beskriver, hvad der skete. Bed kun om den opstart, med monotone tidsstempler, så hver besked sidder på ét ur. Find derefter to linjer: det øjeblik, tunnelunitten begyndte at starte, og det øjeblik, adressen dukkede op, eller ventetjenesten blev færdig. Sæt de to tal i rækkefølge, og kapløbet er enten bekræftet eller udelukket.

Afhængighedsvisningen bekræfter det. Hvis en kritisk kæde for tunnelunitten ikke indeholder en ventetjeneste, forsinkede intet på den vej opstarten, og målet udførte ikke det arbejde, du antog. To visninger, én konklusion.

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

Tilføj ventetiden, derefter nyt forsøg

Brug en drop-in i stedet for at redigere en pakket unit, så en pakkeopdatering ikke lydløst kasserer ændringen. To direktiver er vigtige: unitten skal være ordnet efter målet, og den skal trække målet ind i samme transaktion. Orden alene tilkalder ikke målet; det gør ønsket.

Den pakkede unit til OpenVPN-klienten bærer allerede begge. Håndskrevne units bærer normalt én eller ingen, hvilket er værd at kontrollere, før du tilføjer noget.

[Service]
Restart=on-failure
RestartSec=15

Hvorfor en fast søvn er en fælde

En søvn i ExecStartPre føles som en ordensrettelse og opfører sig som en forsinkelse med ekstra trin. Den gør hver opstart langsommere, også dem, der var sunde, og taber stadig, når forbindelsen tager længere tid end det tal, du valgte.

Værre, den skjuler, om ventetjenesten virker, så den næste fejl fremstår som et helt nyt problem i stedet for det samme med en anden timing. En kort genstartsforsinkelse er det bedre instrument: den koster intet ved en sund opstart og forvandler et tabt kapløb til endnu et forsøg. Hold intervallet beskedent, og lad unitten lykkes. Hvis den genstarter for evigt, er profilen i stykker, og ingen mængde af nye forsøg ændrer det, så læs loggen i stedet for at hæve intervallet.

Når rækkefølgen er rigtig, og navne stadig fejler

En aktiv unit med en tunnelrute betyder, at rækkefølgen gjorde sit arbejde, og at den resterende fejl sidder et lag højere oppe. Den sædvanlige form er en resolverindstilling, som tunnelens up-script anvender, før forbindelsen eller resolveren var klar til at holde på den. Sammenlign resolverens tilstand under fejlen med tilstanden efter en genstart af tunnelunitten.

Hvis genstarten retter opslag, har du en opstartsfejl i rækkefølgen og ikke en forkert DNS-server, og de to kræver forskellige rettelser. Bevis derefter det hele med en kold opstart i stedet for en tjenestegenstart, fordi genstart kører mod et netværk, der allerede er oppe, og vil skjule præcis den fejl, du jagter. Gentag det med forbindelsen bevidst langsom, og betragt en unit, der kun virker, når netværket er hurtigt, som stadig i stykker.