Varför en VPN-enhet startar före nätverket och sedan dör

Starta maskinen, logga in och upptäck att tunneln kom upp och dog några sekunder senare. Profilen var i ordning, certifikatet var i ordning, och det enda spåret som finns kvar är journalen från den starten. Det som vanligen hände är en kapplöpning: enheten startade innan maskinen hade en adress, och ordningen den deklarerade betydde inte det den ser ut som. Allt nedan handlar om att bevisa den kapplöpningen utifrån bevis och stänga den ordentligt.

Målet är en mötesplats, inte en administratör

network-online.target har ingen aning om vad ett nätverk är. Det är en samordningspunkt som samlar den tjänst som ska fördröja starten tills förbindelsen är användbar, och den delegerar definitionen till den nätverkshanterare som äger maskinen. På de flesta stationära datorer och servrar betyder det en väntetjänst som levereras av NetworkManager eller av systemd-networkd. Aktiverar du ingen av dem har målet inget att vänta på, så det slutförs i samma ögonblick som något drar in det, vilket kan vara långt före DHCP svarar. Ordningsraden i din enhet var ärlig och ändå värdelös.

Den första frågan är därför inte vad din enhet deklarerar. Det är om något på den här maskinen faktiskt utför väntan.

Läs den senaste starten i stället för enhetsfilen

Enhetsfiler beskriver avsikt, och journalen beskriver vad som hände. Fråga bara efter den starten, med monotona tidsstämplar så att varje meddelande sitter på en enda klocka. Hitta sedan två rader: ögonblicket då tunnelenheten började starta, och ögonblicket då adressen dök upp eller väntetjänsten blev klar. Sortera de två talen och kapplöpningen är antingen bekräftad eller utesluten.

Beroendevyen bekräftar det. Om en kritisk kedja för tunnelenheten inte innehåller någon väntetjänst fördröjde inget på den vägen starten, och målet gjorde inte arbetet du antog. Två vyer, en slutsats.

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

Lägg till väntan, sedan det nya försöket

Använd en drop-in i stället för att redigera en paketerad enhet, så att en paketuppdatering inte tyst kastar ändringen. Två direktiv spelar roll: enheten måste vara ordnad efter målet, och den måste dra in målet i samma transaktion. Ordning ensam kallar inte på målet; viljan gör det.

Den paketerade enheten för OpenVPN-klienten bär redan båda. Handskrivna enheter bär vanligen en eller ingen, vilket är värt att kontrollera innan du lägger till något.

[Service]
Restart=on-failure
RestartSec=15

Varför en fast sömn är en fälla

En sömn i ExecStartPre känns som en ordningsreparation och beter sig som en fördröjning med extra steg. Den saktar ner varje start, även de som var friska, och den förlorar fortfarande när förbindelsen tar längre tid än talet du valde.

Värre, den döljer om väntetjänsten fungerar, så nästa fel framstår som ett helt nytt problem i stället för samma med annan timing. En kort omstartsfördröjning är det bättre instrumentet: den kostar inget vid en frisk start och förvandlar en förlorad kapplöpning till ett nytt försök. Håll intervallet blygsamt och låt enheten lyckas. Om den startar om för alltid är profilen trasig och ingen mängd nya försök ändrar det, så läs loggen i stället för att höja intervallet.

När ordningen är rätt och namnen ändå misslyckas

En aktiv enhet med en tunnelrutt betyder att ordningen gjorde sitt jobb och att det återstående felet sitter ett lager högre upp. Den vanliga formen är en resolverinställning som tunnelns up-skript tillämpar innan förbindelsen eller resolveraren var redo att hålla kvar den. Jämför resolverarens tillstånd under felet med tillståndet efter en omstart av tunnelenheten.

Om omstarten rättar uppslagningar har du ett startordningsfel och inte en felaktig DNS-server, och de två behöver olika rättelser. Bevisa sedan hela saken med en kall start i stället för en tjänsteomstart, eftersom en omstart kör mot ett nätverk som redan är uppe och kommer att dölja precis det fel du jagar. Upprepa det med förbindelsen avsiktligt långsam, och behandla en enhet som bara fungerar när nätverket är snabbt som fortfarande trasig.