Miksi OpenVPN-asiakkaasi jää alas yhden aikakatkaisun jälkeen

Maanantaiaamu: perjantaina noussut tunneli on poissa, liitäntä on yhä listattu, eikä lokissa sanota kenenkään huomanneen sitä. Isäntä on verkossa, kojelauta on vihreä, ja kaikki, mitä se lähetti viikonloppuna, meni fyysisen liitännän kautta. Tässä puuttuu kaksi riippumatonta päätöstä: toinen siitä, selviääkö asiakasprosessi tilapäisestä viasta, ja toinen siitä, käynnistääkö jokin sen yläpuolella prosessin uudelleen sen poistuttua. Vain toisen korjaaminen jättää toisen aukon avoimeksi.

Aloita siitä, mitä yksikkö todella teki, ei siitä, mitä valvonta väittää. systemctl status openvpn-client@office ja journalctl -u openvpn-client@office -n 50 näyttävät poistumisen syyn ja viimeisen rivin, jonka asiakas kirjoitti ennen lähtöään.

Prosessi poistui ennen kuin kukaan huomasi

Ilman virhettä katoava asiakas on yleensä poistunut tarkoituksella. Profiili päättää tästä käyttäytymisestä, ei palvelunhallinta: ping-exit lopettaa prosessin heti, kun vastapuoli lakkaa vastaamasta, kun taas ping-restart pitää prosessin ja yhdistää uudelleen sen sisällä. Istuntorajat ja passiivisuusajastimet tuottavat ulkopuolelta saman kuvan: ei tunnelia eikä hälytystä.

Kaksi ping-direktiiviä ei voi olla samassa profiilissa yhtä aikaa, joten valitse yksi ja kirjaa valinta. Katso myös palvelinta, sillä sen oma ping-exit sulkee istunnon riippumatta siitä, mitä asiakas pyysi, ja vain palvelimen loki kirjaa, kuka sen päätöksen teki.

Valinta ping-exit ja ping-restart välillä

Valitse ping-restart kannettavalle tai etäkohteelle, jonka pitää parantaa itsensä, ja säästä ping-exit tapauksiin, joissa kuolleen tunnelin on pysäytettävä prosessi, jotta jokin muu voi reagoida siihen. Numerot ovat vähemmän tärkeitä kuin suhde: ping 10 yhdessä ping-restart 60 tarkoittaa kymmenen sekunnin hiljaisuutta ennen koetusta ja kuuttakymmentä ennen uudelleenkäynnistystä, mikä on aggressiivista häviöisellä mobiiliyhteydellä ja järkevää kaapeliyhteydellä. Kirjoita perustelu rivin viereen, muuten seuraava lukija olettaa, että oletusarvot olivat tarkoituksellisia.

Vahvista sitten, että poistui todella prosessi. Yksikkö, joka ilmoittaa olevansa aktiivinen tunnelin ollessa kuollut, on eri vika, jota käsitellään alempana.

Valvonta, joka todella käynnistää yksikön uudelleen

systemd-isännässä pienin pysyvä muutos on yksi drop-in-tiedosto: Restart=on-failure ja RestartSec=10 tiedostossa /etc/systemd/system/[email protected]/restart.conf. Drop-in luetaan vain, kun systemd lataa omat määritelmänsä uudelleen, joten aja sen jälkeen systemctl daemon-reload. Vahvista systemctl show -p Restart -p ExecMainStatus openvpn-client@office komennolla sen sijaan, että olettaisit arvon saapuneen. Tiedostonimen instanssin on oltava profiili, jonka yksikkö todella lataa, joten office kohteelle kirjoitettu tiedosto ei tee mitään openvpn-client@home kohteelle.

on-failure jättää huomiotta yhden tapauksen: puhtaan poistumisen, jonka tila on nolla. Eräät purkuvaiheet päättyvät niin, joten lue tallennettu tila sen sijaan, että luottaisit käsikirjasivun sanamuotoon. Jos asiakkaasi antaa periksi nollalla, tarvitset Restart=always, ja hinta on, että todella rikkinäinen profiili palaa yhä uudelleen, kunnes käynnistystahtiraja aktivoituu ja loki täyttyy.

Restart=always laukeaa myös tarkoituksellisen pysäytyksen jälkeen. Käytä huoltoa varten systemctl stop komentoa ja peitä yksikkö, jos sen on pysyttävä alas työskennellessäsi.

Nappaa vuoto, kun tunneli on alhaalla

Valvonta tuo tunnelin takaisin; se ei estä liikennettä lähtemästä, kun tunneli on poissa. persist-tun pitää laitteen ja sen reitit uudelleenyhdistysten yli, mikä on kätevää ja avaa ikkunan. Laite säilyy, reitit osoittavat yhä siihen, ja paketit valuvat ulos suojaamattomina ja raportoimattomina. Se on käytäntövalinta, ei neutraali oletusarvo.

Kun isäntä ei saa lainkaan lähettää suojaamattomia paketteja, vain palomuuri voi taata sen. Lähtösääntö, joka sallii tunneliliitännän ja VPN-palvelimen osoitteen ja pudottaa kaiken muun, pitää yhä asiakkaan kuoltua, eikä mikään asiakkaan omassa kokoonpanossa voi suodattaa liikennettä, jota asiakas ei kanna.

Testaa se pysäyttämällä asiakas tarkoituksella. Aja systemctl stop openvpn-client@office, sitten curl -m 5 https://example.com, jonka pitäisi epäonnistua fyysisen yhteyden yli sen sijaan, että onnistuisi. Onnistuminen tarkoittaa, että palomuurisääntö puuttuu tai on liian salliva.

Yhdistä uudelleen, vahvista että tunneli kantaa liikennettä taas, ja lisää tarkistus valvontaan vasta sitten. ip addr komennon kysely cronista tun laitteelle on valvonta, joka epäonnistuu useimmin, koska persist-tun asetuksella laite elää istuntoa pidempään ja koetin ilmoittaa terveydestä, kun mitään ei kanneta.