Miksi VPN-yksikkö käynnistyy ennen verkkoa ja kuolee sitten
Yksikkö, joka käynnistyy ennen kuin yhteydellä on osoite, epäonnistuu tavalla, joka näyttää satunnaiselta. Todista järjestys lokista ja lisää sitten odotus ja uusi yritys.
Käynnistä kone, kirjaudu sisään ja huomaa, että tunneli nousi ja kuoli muutamaa sekuntia myöhemmin. Profiili oli kunnossa, varmenne oli kunnossa, ja ainoa jäljellä oleva jälki on tuon käynnistyksen loki. Yleensä tapahtui kilpailutilanne: yksikkö käynnistyi ennen kuin koneella oli osoite, ja järjestys, jonka se ilmoitti, ei tarkoittanut sitä, miltä se näyttää. Kaikki alla käsittelee sen kilpailun todistamista todisteista ja sen sulkemista kunnolla.
Kohde on kohtaamispaikka, ei hallitsija
network-online.target ei tiedä verkosta mitään. Se on koordinointipiste, joka kerää sen palvelun, jonka pitäisi viivyttää käynnistystä kunnes yhteys on käyttökelpoinen, ja se delegoi määritelmän sille verkkohallinnalle, joka omistaa koneen. Useimmilla työpöydillä ja palvelimilla se tarkoittaa odotuspalvelua, jonka NetworkManager tai systemd-networkd toimittaa. Jos et ota kumpaakaan käyttöön, kohteella ei ole mitään odottaa, joten se valmistuu heti, kun jokin vetää sen mukaan, ja se voi tapahtua kauan ennen kuin DHCP vastaa. Yksikkösi järjestysrivi oli rehellinen ja silti hyödytön.
Ensimmäinen kysymys ei siis ole, mitä yksikkösi ilmoittaa. Vaan se, tekeekö tällä koneella jokin todella odotuksen.
Lue viimeinen käynnistys yksikkötiedoston sijaan
Yksikkötiedostot kuvaavat aikomuksen, ja loki kuvaa mitä tapahtui. Pyydä vain tuo käynnistys, monotonisilla aikaleimoilla, jotta jokainen viesti istuu yhdellä kellolla. Etsi sitten kaksi riviä: hetki, jolloin tunneliyksikkö alkoi käynnistyä, ja hetki, jolloin osoite ilmestyi tai odotuspalvelu päättyi. Järjestä nämä kaksi lukua, ja kilpailu on joko vahvistettu tai suljettu pois.
Riippuvuusnäkymä vahvistaa sen. Jos tunneliyksikön kriittinen ketju ei sisällä odotuspalvelua, mikään tuolla polulla ei viivyttänyt käynnistystä, eikä kohde tehnyt sitä työtä, jota oletit. Kaksi näkymää, yksi johtopäätös.
systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office
Lisää odotus, sitten uusi yritys
Käytä drop-inia paketoidun yksikön muokkaamisen sijaan, jotta pakettipäivitys ei hävitä muutosta hiljaa. Kaksi direktiiviä on tärkeää: yksikkö on järjestettävä kohteen jälkeen, ja sen on vedettävä kohde samaan transaktioon. Järjestys yksin ei kutsu kohdetta; halu tekee sen.
OpenVPN-asiakkaan paketoitu yksikkö kantaa jo molemmat. Käsin kirjoitetut yksiköt kantavat yleensä yhden tai ei yhtään, mikä kannattaa tarkistaa ennen kuin lisäät mitään.
[Service]
Restart=on-failure
RestartSec=15
Miksi kiinteä uni on ansa
Uni ExecStartPre:ssa tuntuu järjestyskorjaukselta ja käyttäytyy viiveenä, jossa on ylimääräisiä vaiheita. Se hidastaa jokaista käynnistystä, myös niitä jotka olivat terveitä, ja häviää silti, kun yhteys kestää kauemmin kuin valitsemasi luku.
Pahempaa, se kätkee, toimiiko odotuspalvelu, joten seuraava vika näyttää aivan uudelta ongelmalta eikä samalta eri ajoituksella. Lyhyt uudelleenkäynnistyksen viive on parempi väline: se ei maksa terveellä käynnistyksellä mitään ja muuttaa hävityn kilpailun uudeksi yritykseksi. Pidä väli maltillisena ja anna yksikön onnistua. Jos se käynnistyy uudelleen ikuisesti, profiili on rikki eikä mikään määrä uusia yrityksiä muuta sitä, joten lue loki sen sijaan että nostat väliä.
Kun järjestys on oikein ja nimet silti epäonnistuvat
Aktiivinen yksikkö, jolla on tunnelireitti, tarkoittaa, että järjestys teki tehtävänsä ja jäljellä oleva vika on kerrosta ylempänä. Tavallinen muoto on resolverin asetus, jonka tunnelin up-skripti soveltaa ennen kuin yhteys tai resolveri oli valmis pitämään sitä. Vertaa resolverin tilaa vian aikana tilaan tunneliyksikön uudelleenkäynnistyksen jälkeen.
Jos uudelleenkäynnistys korjaa haut, sinulla on käynnistysjärjestyksen vika eikä väärä DNS-palvelin, ja ne kaksi tarvitsevat eri korjaukset. Todista sitten koko asia kylmällä käynnistyksellä palvelun uudelleenkäynnistyksen sijaan, koska uudelleenkäynnistys toimii verkkoa vasten, joka on jo ylhäällä, ja kätkee juuri sen vian, jota jahtaat. Toista se tahallaan hitaalla yhteydellä, ja pidä yksikköä, joka toimii vain nopeassa verkossa, edelleen rikkinäisenä.