Miks teie OpenVPN-klient jääb pärast ühte ajalõppu seisma
Klient, mis väljub esimese ajalõpu järel, jätab hosti, mis näib võrgus olevat ja ei kanna midagi. Parandage profiili valik ja taaskäivituse poliitika eraldi.
Esmaspäeva hommik: reedel tõusnud tunnel on kadunud, liides on veel nimekirjas ja logis ei ole midagi selle kohta, et keegi seda märkas. Host on võrgus, armatuurlaud on roheline ja kõik, mis nädalavahetusel saadeti, väljus hoopis füüsilise liidese kaudu. Siin puudub kaks sõltumatut otsust: üks selle kohta, kas kliendi protsess jääb üleajalise tõrke üle elama, ja teine selle kohta, kas midagi selle kohal käivitab protsessi pärast väljumist uuesti. Ainult ühe parandamine jätab teise augu lahti.
Alustage sellest, mida üksus tegelikult tegi, mitte sellest, mida seire väidab. systemctl status openvpn-client@office ja journalctl -u openvpn-client@office -n 50 näitavad väljumise põhjust ja viimast rida, mille klient enne lahkumist kirjutas.
Protsess väljus enne, kui keegi märkas
Ilma veata kaduv klient on tavaliselt väljunud meelega. Selle käitumise otsustab profiil, mitte teenusehaldur: ping-exit lõpetab protsessi kohe, kui vastaspool lakkab vastamast, samas kui ping-restart hoiab protsessi alles ja taasühendub selle sees. Sessioonipiirid ja passiivsustaimerid annavad väljastpoolt sama pildi: tunnelit ega häiret pole.
Kaks ping-direktiivi ei saa olla ühes profiilis korraga, seega valige üks ja kirjutage valik üles. Vaadake ka serverit, sest selle enda ping-exit sulgeb sessiooni olenemata sellest, mida klient palus, ja ainult serveri logi fikseerib, kes selle otsuse tegi.
Valik ping-exit ja ping-restart vahel
Valige ping-restart sülearvuti või kaugkoha jaoks, mis peaks ise paranema, ja hoidke ping-exit juhtudeks, kus surnud tunnel peab protsessi peatama, et miski muu saaks sellele reageerida. Numbrid on vähem olulised kui seos: ping 10 koos ping-restart 60 tähendab kümmet sekundit vaikust enne sondi ja kuuskümmend enne taaskäivitust, mis on kadudega mobiililingil agressiivne ja kaablil mõistlik. Kirjutage põhjus rea kõrvale, muidu eeldab järgmine lugeja, et vaikeväärtused olid meelega valitud.
Seejärel kinnitage, et väljus tõepoolest protsess. Üksus, mis teatab aktiivsusest, kui tunnel on surnud, on teine rike, mida käsitletakse allpool.
Järelevalve, mis tõesti üksust taaskäivitab
systemd-hostis on väikseim püsiv muudatus üks drop-in-fail: Restart=on-failure ja RestartSec=10 failis /etc/systemd/system/[email protected]/restart.conf. Drop-in'i loetakse ainult siis, kui systemd oma definitsioonid uuesti laadib, seega käivitage seejärel systemctl daemon-reload. Kontrollige systemctl show -p Restart -p ExecMainStatus openvpn-client@office abil, selle asemel et eeldada, et väärtus kohale jõudis. Failinimes olev eksemplar peab olema profiil, mille üksus tegelikult laadib, seega office jaoks kirjutatud fail ei tee openvpn-client@home jaoks midagi.
on-failure eirab ühte juhtu: puhas väljumine staatusega null. Mõned lammutusteed lõpevad nii, seega lugege salvestatud staatust, mitte ärge usaldage manuaalilehekülje sõnastust. Kui teie klient annab nulliga alla, vajate Restart=always, ja hind on see, et tõeliselt katkine profiil tuleb ikka ja jälle tagasi, kuni käivitussageduse piir rakendub ja logi täitub.
Restart=always rakendub ka pärast meelega peatamist. Kasutage hoolduseks systemctl stop ja maskeerige üksus, kui see peab teie töö ajal maas püsima.
Püüdke leke kinni, kui tunnel on maas
Järelevalve toob tunneli tagasi; see ei takista liiklust väljumast, kui tunnelit pole. persist-tun hoiab seadet ja selle marsruute ühenduste vahel alles, mis on mugav ja avab akna. Seade jääb alles, marsruudid sihivad endiselt seda ja paketid voolavad välja kaitsmata ning teavitamata. See on poliitika valik, mitte neutraalne vaikeväärtus.
Kui host ei tohi üldse kaitsmata pakette välja saata, saab seda tagada ainult tulemüür. Väljundreegel, mis lubab tunneli liidest ja VPN-serveri aadressi ning viskab kõik muu kõrvale, kehtib ka pärast kliendi surma ja miski kliendi enda konfiguratsioonis ei suuda filtreerida liiklust, mida klient ei kanna.
Testige seda kliendi meelega peatamisega. Käivitage systemctl stop openvpn-client@office, seejärel curl -m 5 https://example.com, mis peaks füüsilise lingi kaudu ebaõnnestuma, mitte õnnestuma. Edukus tähendab, et tulemüürireegel puudub või on liiga lubav.
Ühendage uuesti, kinnitage, et tunnel kannab jälle liiklust, ja alles siis lisage kontroll seiresse. ip addr küsitlemine croni kaudu tun seadme jaoks on järelevalve, mis kõige sagedamini ebaõnnestub, sest persist-tun korral elab seade kauem kui sessioon ja sond teatab tervisest, kui midagi ei kanta.