Kvifor ei VPN-eining startar før netverket og deretter døyr

Start maskina, logg inn, og oppdag at tunnelen kom opp og døydde nokre sekund seinare. Profilen var i orden, sertifikatet var i orden, og det einaste sporet som er att, er journalen frå den oppstarten. Det som vanlegvis hende, er eit kapplaup: eininga starta før maskina hadde ei adresse, og rekkjefølgja ho erklærte, tydde ikkje det ho ser ut som. Alt nedanfor handlar om å prova det kapplaupe ut frå prov og lukka det ordentleg.

Målet er eit møtepunkt, ikkje ein administrator

network-online.target anar ikkje kva eit netverk er. Det er eit koordineringspunkt som samlar tenesta som skal utsetja oppstarten til sambandet er brukbart, og det delegerer definisjonen til den nettverksadministratoren som eig maskina. På dei fleste stasjonære maskiner og servarar tyder det ei venteteneste som NetworkManager eller systemd-networkd leverer. Aktiverer du ingen av dei, har målet ingenting å venta på, så det blir fullført i det augneblinken noko dreg det inn, noko som kan vera lenge før DHCP svarar. Rekkjefølgjelinja i eininga di var ærleg og likevel ubrukeleg.

Det første spørsmålet er derfor ikkje kva eininga di erklærer. Det er om noko på denne maskina faktisk utfører ventinga.

Les den siste oppstarten i staden for einingsfila

Einingfiler skildrar hensikt, og journalen skildrar kva som hende. Be berre om den oppstarten, med monotone tidsstempel slik at kvar melding sit på éi klokke. Finn deretter to linjer: augneblinken då tunneleininga byrja å starta, og augneblinken då adressa dukka opp eller ventetenesta vart ferdig. Sorter dei to tala, og kapplaupe er anten stadfesta eller utelukka.

Avhengnadsvisinga stadfester det. Viss ei kritisk kjede for tunneleininga ikkje inneheld noka venteteneste, utsette ingenting på den vegen oppstarten, og målet gjorde ikkje arbeidet du anteke. To visingar, éin konklusjon.

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

Legg til ventinga, deretter det nye forsøket

Bruk ein drop-in i staden for å redigera ei pakka eining, slik at ein pakkeoppdatering ikkje stilltande forkastar endringa. To direktiv tel: eininga må vera ordna etter målet, og ho må dra målet inn i same transaksjonen. Orden åleine kallar ikkje på målet; ønsket gjer det.

Den pakka eininga for OpenVPN-klienten ber allereie begge. Handskrivne einingar ber vanlegvis éi eller inga, noko som er verdt å sjekka før du legg til noko.

[Service]
Restart=on-failure
RestartSec=15

Kvifor ein fast søvn er ei felle

Ein søvn i ExecStartPre kjennest som ein rekkjefølgjereparasjon og oppfører seg som ei forseinking med ekstra trinn. Han bremsar kvar oppstart, òg dei som var sunne, og han tapar framleis når sambandet tek lengre tid enn talet du valde.

Verre, han skjuler om ventetenesta verkar, så den neste feilen framstår som eit heilt nytt problem i staden for det same med ei anna timing. Ei kort omstartforsinking er det betre instrumentet: ho kostar ingenting ved ein sunn oppstart og gjer eit tapt kapplaup om til eit nytt forsøk. Hald intervallet beskjedent og lat eininga lukkast. Viss ho startar på nytt for alltid, er profilen øydelagd og inga mengd nye forsøk endrar det, så les loggen i staden for å auka intervallet.

Når rekkjefølgja er rett og namna likevel feilar

Ei aktiv eining med ein tunnelrute tyder at rekkjefølgja gjorde jobben sin, og at den attverande feilen sit eitt lag høgare oppe. Den vanlege forma er ei resolver-innstilling som up-skriptet til tunnelen brukar før sambandet eller resolveren var klar til å halda på henne. Samanlikn tilstanden til resolveren under feilen med tilstanden etter ein omstart av tunneleininga.

Viss omstarten rettar oppslag, har du ein oppstartsrekkjefølgjefeil og ikkje ein feil DNS-server, og dei to treng ulike rettingar. Prov deretter heile saka med ein kald oppstart i staden for ein tenesteomstart, fordi omstart køyrer mot eit netverk som allereie er oppe, og vil skjula nettopp den feilen du jagar. Gjenta det med sambandet medvite tregt, og handsam ei eining som berre verkar når netverket er snøgt, som framleis øydelagd.