Waarom jou OpenVPN-kliënt ná een enkele tydsverstryking uitval

Maandagoggend: die tonnel wat Vrydag opgekom het, is weg, die koppelvlak word nog gelys, en niks in die joernaal sê dat iemand dit opgemerk het nie. Die gasheer is aanlyn, die paneelbord is groen, en wat hy oor die naweek gestuur het, het eerder deur die fisiese koppelvlak uitgegaan. Twee onafhanklike besluite ontbreek hier: een daaroor of die kliëntproses 'n verbygaande fout oorleef, en een daaroor of iets bokant hom die proses weer begin nadat dit uitgaan. Om net een van die twee te herstel, laat die ander gaping oop.

Begin by wat die eenheid werklik gedoen het, nie by wat die monitering beweer nie. systemctl status openvpn-client@office en journalctl -u openvpn-client@office -n 50 wys die rede vir die uitgang en die laaste reël wat die kliënt geskryf het voordat hy weg is.

Die proses het uitgegaan voordat iemand dit opgemerk het

'n Kliënt wat sonder 'n fout verdwyn, het gewoonlik opsetlik uitgegaan. Die profiel besluit oor hierdie gedrag, nie die diensbestuurder nie: ping-exit beëindig die proses sodra die eweknie ophou antwoord, terwyl ping-restart die proses hou en binne hom weer verbind. Sessieperke en onaktiwiteitstyders lewer van buite dieselfde prentjie: geen tonnel en geen alarm nie.

Die twee ping-direktiewe kan nie saam in een profiel staan nie, kies dus een en teken die keuse aan. Kyk ook na die bediener, want sy eie ping-exit sluit 'n sessie ongeag wat die kliënt aangevra het, en net die bedienerjoernaal teken aan wie daardie besluit geneem het.

Kies tussen ping-exit en ping-restart

Kies ping-restart vir 'n skootrekenaar of 'n afgeleë terrein wat homself moet genees, en hou ping-exit terug vir gevalle waar 'n dooie tonnel die proses moet stop sodat iets anders daarop kan reageer. Die syfers is minder belangrik as die verband: ping 10 met ping-restart 60 beteken tien sekondes stilte voor 'n toets en sestig voor die herbegin, wat aggressief is op 'n verliesryke mobiele skakel en redelik op 'n bedrade een. Skryf die rede langs die reël, want die volgende leser sal andersins aanneem die verstekwaardes was opsetlik.

Bevestig dan dat dit werklik die proses is wat uitgegaan het. 'n Eenheid wat aktief rapporteer terwyl die tonnel dood is, is 'n ander fout wat verder hieronder hanteer word.

Toesig wat die eenheid werklik herbegin

Op 'n systemd-gasheer is die kleinste blywende verandering een drop-in-lêer: Restart=on-failure en RestartSec=10 in /etc/systemd/system/[email protected]/restart.conf. 'n Drop-in word net gelees wanneer systemd sy eie definisies herlaai, voer dus daarna systemctl daemon-reload uit. Verifieer met systemctl show -p Restart -p ExecMainStatus openvpn-client@office eerder as om aan te neem die waarde het aangekom. Die instansie in die lêernaam moet die profiel wees wat die eenheid werklik laai, so 'n lêer wat vir office geskryf is, doen niks vir openvpn-client@home nie.

on-failure ignoreer een geval: 'n skoon uitgang met status nul. Sommige afbreekroetes eindig so, lees dus die aangetekende status eerder as om die bewoording van 'n man-bladsy te vertrou. As jou kliënt met 'n nul opgee, het jy Restart=always nodig, en die koste is dat 'n werklik stukkende profiel aanhou terugkom totdat die begintempo-limiet trap en die joernaal vol raak.

Restart=always vuur ook ná 'n doelbewuste stop. Gebruik systemctl stop vir instandhouding, en maskeer die eenheid as dit ondertoe moet bly terwyl jy werk.

Vang die lek terwyl die tonnel af is

Toesig hou die tonnel aan die terugkom; dit keer nie dat verkeer uitgaan terwyl die tonnel weg is nie. persist-tun hou die toestel en sy roetes oor herverbindings heen, wat gerieflik is en 'n venster oopmaak. Die toestel oorleef, die roetes mik steeds daarop, en pakkette dreineer onbeskermd en ongerapporteer uit. Dit is 'n beleidskeuse, nie 'n neutrale verstek nie.

Wanneer 'n gasheer glad nie onbeskermde pakkette mag uitstuur nie, kan net die vuurmuur dit waarborg. 'n Uitvoerreël wat die tonnelkoppelvlak en die VPN-bediener se adres toelaat en alles anders laat val, hou steeds na die kliënt sterf, en niks in die kliënt se eie konfigurasie kan verkeer filter wat die kliënt nie dra nie.

Toets dit deur die kliënt doelbewus te stop. Voer systemctl stop openvpn-client@office uit, dan curl -m 5 https://example.com, wat oor die fisiese skakel moet misluk eerder as slaag. 'n Sukses beteken die vuurmuurreël ontbreek of is te toegeeflik.

Verbind weer, bevestig dat die tonnel weer verkeer dra, en voeg eers dan die kontrole by monitering. Om ip addr per cron te peil vir 'n tun-toestel is die toesig wat die meeste misluk, want met persist-tun oorleef die toestel die sessie en rapporteer die peiling gesond terwyl niks gedra word nie.