FreeBind vastaan After=: systemd-socketin sitominen VPN-osoitteeseen

Käynnistyksessä socket-yksikkö, joka sitoo kiinteän VPN-osoitteen, voi epäonnistua ennen kuin tunneli on antanut sen, eikä sen takana oleva palvelu käynnisty koskaan. Kaksi kytkintä näyttävät korjauksilta ja ratkaisevat ongelman eri puolikkaat. FreeBind antaa systemd:n luoda kuuntelijan, kun osoite vielä puuttuu. After= vain järjestää työt, joten se muuttaa sitä, milloin asiat käynnistyvät, saamatta osoitetta saapumaan aikaisemmin.

Kaksi eri ongelmaa, kaksi eri kytkintä

Ensimmäinen ongelma on sitomisen epäonnistuminen: ydin kieltäytyy kuuntelemasta osoitteessa, jota isäntä ei omista, joten socket-yksikkö epäonnistuu heti eikä palvelua aktivoida koskaan. Toinen ongelma on valmiuden epäonnistuminen: osoite on lopulta olemassa, mutta jokin yrittää käyttää sitä ennen kuin tunneli kuljettaa liikennettä. FreeBind ratkaisee ensimmäisen eikä tee toiselle mitään. Järjestyskäskyt eivät ratkaise kumpaakaan suoraan, koska ne päättävät vain, mikä käynnistyy missä järjestyksessä. Sen epäonnistumisen nimeäminen, joka sinulla todella on, on koko päätös.

Varmista lokista, kumpi sinulla on, älä palvelun kuvauksesta. Sitomisen epäonnistuminen nimeää osoitteen ja ilmoittaa, ettei sitä voi antaa. Valmiuden epäonnistuminen näkyy yleensä myöhemmin aikakatkaisuna tai vastapuolelta nähtynä hylättynä yhteytenä, kun lokeissa on täysin terve socket-yksikkö.

FreeBind: kuuntelija on olemassa ennen osoitetta

FreeBind käskee ydintä sallimaan sitomisen ei-paikalliseen osoitteeseen, jotta systemd voi luoda kuuntelevan socketin käynnistyksessä ja antaa sen sovellukselle aina, kun sovellus käynnistyy. Se on socket-aktivoinnin idea ja syy siihen, miksi socket voi elää pidempään kuin sen takana oleva palvelu.

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

Tyhjä määritys poistaa toimittajan yksiköltä perityt kuuntelumerkinnät ennen uuden lisäämistä, mikä estää jäljelle jäänyttä wildcard-kuuntelijaa vastaamasta kaikilla liitäntöillä. Korvaa osoite ja portti omillasi ja tarkista tehokas yksikkö, älä vain drop-in-tiedostoa. Käytä drop-in-tiedostoa yksikön nimellä sen sijaan, että muokkaat pakettitiedostoa paikallaan, koska seuraava pakettipäivitys korvaa muokkauksen eikä jätä mitään jälkeä aikomuksesta. Ota se sitten käyttöön uudelleenlataus- ja uudelleenkäynnistysmenettelyllä, jota socket-yksikkö odottaa.

systemd-socket-viite dokumentoi valinnan takana olevan IPv4- ja IPv6-käyttäytymisen, ja tärkeä yksityiskohta on, että se koskee sitomista eikä reititystä. Mikään siinä ei anna osoitetta tai käynnistä VPN:ää. FreeBind on kuuntelijalle myönnetty lupa, ei liitännän korvike.

After= ja Wants=: järjestys ei ole valmiutta

Järjestys ja vaatimus ovat erillisiä akseleita, ja niiden sekoittaminen tuottaa yksiköitä, jotka käynnistyvät oikeassa järjestyksessä ja epäonnistuvat silti. After=vpn-client.service tarkoittaa vain, että jos molemmat työt käynnistetään, tämä odottaa toisen käynnistymistä. Se ei vedä VPN:ää mukaan eikä odota, että VPN lopettaa yhdistämisen.

Vaatimuskäskyt kuten Wants= ja Requires= hoitavat aktivoinnin ja eroavat siinä, mitä tapahtuu, kun riippuvuus epäonnistuu: toinen jatkaa, toinen pysähtyy. Kumpikaan ei tiedä, mitä yhdistetty tunneli tarkoittaa. VPN-prosessi voi olla aktiivinen ilman annettua osoitetta tai annetulla osoitteella ja ilman reittiä vastapuolelle, ja molemmat tilat täyttävät riippuvuuden. Jos sovellus tarvitsee osoitteen olemassaoloa, mallinna se ehto eksplisiittisesti sen sijaan, että pitäisit prosessin käynnistymistä todisteena valmiudesta.

Tarkista, mitä yksikkö todella ilmoittaa komennoilla systemctl cat ja systemctl show -p After -p Wants -p Requires. Kolmen eri hakemiston drop-in-tiedostot voivat lisätä käskyjä, joita et koskaan kirjoittanut, ja systemd lukee vain tehokkaan yksikön.

Mitä network-online.target ei tee

network-online.target:n jälkeen järjestetty yksikkö odottaa, että verkonhallinta julistaa verkon käyttökelpoiseksi, mikä on käynnistyksen synkronointipiste eikä jatkuva ehto. Se ei kerro mitään siitä, onko tietty tunneli ylhäällä, eikä laukea uudelleen, kun VPN yhdistää uudelleen iltapäivällä. Sen pitäminen uudelleenyhdistämisen valvojana on tuon kohteen yleisin väärinluku.

systemd-projekti dokumentoi tuon eron suoraan, ja käytännön seuraus on, että kaiken tunneliosoitetta tarvitsevan on omistettava riippuvuus itse. Yksikkö, joka odottaa network-onlinea ja sitoo sitten tunneliosoitteen, on oikein vain silloin, kun tunneli sattuu nousemaan ensin, ja se on sattuma eikä suunnittelu.

Testaa elinkaari, jonka todella valitsit

Testaa puhdas käynnistys, pyyntö osoitteen ilmestymisen jälkeen ja käyttäytyminen, kun VPN putoaa ja palaa. Nämä kolme tapausta erottavat toimivan kuuntelijan toimivasta palvelusta.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

Ensimmäinen komento nappaa yksikkötiedoston virheet ennen uudelleenkäynnistystä, toinen näyttää yhdistetyn yksikön ja kolmas todistaa, onko kuuntelija olemassa ja millä osoitteella. Kuuntelija wildcard-osoitteessa siellä, missä odotit tunneliosoitetta, on täsmälleen se jäänne, jonka tyhjä ListenStream oli tarkoitus poistaa. Toista kolmas komento VPN:n uudelleenyhdistämisen jälkeen nähdäksesi, siirtyikö osoite.

Valitse elinkaari tietoisesti: joko vapaasti sidottu kuuntelija, joka odottaa vakaan osoitteen paluuta, tai palvelu, joka pysähtyy tunnelin mukana ja käynnistyy uudelleen palautuessa. Ne ovat eri suunnitelmia ja ne epäonnistuvat eri tavoin. Pidä sitten käyttöoikeuskäytäntö sidottuna niihin lähteisiin ja polkuihin, jotka tarkoitit, koska kohdeosoitteen sitominen ei vaadi, että hyväksytyt paketit saapuivat luotetun liitännän kautta.