Miks VPN-üksus käivitub enne võrku ja sureb seejärel

Käivitage masin, logige sisse ja avastage, et tunnel tuli üles ja suri mõni sekund hiljem. Profiil oli korras, sertifikaat oli korras, ja ainus allesjäänud jälg on selle buudi journal. Tavaliselt juhtus võidujooks: üksus käivitus enne, kui masinal oli aadress, ja järjekord, mida see deklareeris, ei tähendanud seda, mille moodi see välja näeb. Kõik alljärgnev räägib sellest, kuidas seda võidujooksu tõenditest tõestada ja korralikult sulgeda.

Sihtmärk on kohtumispaik, mitte haldur

network-online.target ei tea võrgust midagi. See on koordineerimispunkt, mis kogub selle teenuse, mis peaks käivitumist edasi lükkama, kuni link on kasutatav, ja delegeerib määratluse sellele võrguhaldurile, kellele masin kuulub. Enamikul töölaudadel ja serveritel tähendab see ootamisteenust, mille tarnib NetworkManager või systemd-networkd. Kui te ei luba kumbagi, pole sihtmärgil millelegi oodata, nii et see lõpeb hetkel, mil miski selle sisse tõmbab, mis võib juhtuda tublisti enne, kui DHCP vastab. Järjekorrarida teie üksuses oli aus ja ikkagi kasutu.

Esimene küsimus pole seega see, mida teie üksus deklareerib. Vaid see, kas midagi selles masinas tegelikult ootamist teeb.

Lugege viimast buudi, mitte üksuse faili

Üksusefailid kirjeldavad kavatsust ja journal kirjeldab, mis juhtus. Küsige ainult seda buudi, monotooniliste ajatemplitega, et iga sõnum istuks ühel kellal. Seejärel leidke kaks rida: hetk, mil tunneli üksus hakkas käivituma, ja hetk, mil aadress ilmus või ootamisteenus lõppes. Järjestage need kaks arvu ja võidujooks on kas kinnitatud või välistatud.

Sõltuvuste vaade kinnitab seda. Kui tunneli üksuse jaoks kriitiline ahel ei sisalda ootamisteenust, ei lükanud miski sellel teel käivitumist edasi ja sihtmärk ei teinud tööd, mida te eeldasite. Kaks vaadet, üks järeldus.

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

Lisage ootamine, seejärel korduskatse

Kasutage drop-in'i, mitte pakendatud üksuse muutmist, et pakendi uuendus ei viskaks muudatust vaikselt välja. Tähtsad on kaks direktiivi: üksus peab olema sihtmärgi järel järjestatud ja see peab sihtmärgi samasse tehingusse tõmbama. Järjestus üksi ei kutsu sihtmärki; seda teeb soov.

OpenVPN-i kliendi pakendatud üksus kannab juba mõlemat. Käsitsi kirjutatud üksused kannavad tavaliselt ühte või mitte ühtegi, mida tasub enne millegi lisamist kontrollida.

[Service]
Restart=on-failure
RestartSec=15

Miks fikseeritud uni on lõks

Uni ExecStartPre sees tundub järjekorraparandusena ja käitub edasilükkamisena lisasammudega. See aeglustab iga buudi, ka neid, mis olid terved, ja kaotab ikkagi, kui link võtab kauem aega kui number, mille valisite.

Hullem, see varjab, kas ootamisteenus töötab, nii et järgmine tõrge ilmub täiesti uue probleemina, mitte sama probleemina teise ajastusega. Lühike taaskäivituse viivitus on parem vahend: see ei maksa terviklikul buudil midagi ja muudab kaotatud võidujooksu veel üheks katseks. Hoidke intervall tagasihoidlik ja laske üksusel õnnestuda. Kui see taaskäivitub igavesti, on profiil katki ja ükski korduskatsete hulk ei muuda seda, seega lugege logi, selle asemel et intervalli tõsta.

Kui järjekord on õige ja nimed ikka ebaõnnestuvad

Aktiivne üksus koos tunnelimarsruudiga tähendab, et järjestus tegi oma töö ja allesjäänud viga asub ühe kihi võrra kõrgemal. Tavaline kuju on resolveri seade, mille tunneli up-skript rakendab enne, kui link või resolver oli valmis seda hoidma. Võrrelge resolveri olekut tõrke ajal olekuga pärast tunneli üksuse taaskäivitamist.

Kui taaskäivitamine parandab otsingud, on teil käivitumisjärjekorra defekt, mitte vale DNS-server, ja need kaks vajavad erinevaid parandusi. Seejärel tõestage kogu asi külma buudiga, mitte teenuse taaskäivitamisega, sest taaskäivitamine jookseb võrgu vastu, mis on juba üleval, ja varjab täpselt selle defekti, mida te taga ajate. Korrake seda teadlikult aeglase lingiga ja pidage üksust, mis töötab ainult siis, kui võrk on kiire, endiselt katkiseks.