Waarom je OpenVPN-client na één time-out blijft liggen

Maandagochtend: de tunnel die vrijdag opkwam is weg, de interface staat nog in de lijst en niets in het journaal zegt dat iemand het merkte. De host is online, het dashboard is groen en alles wat hij in het weekend verstuurde, ging via de fysieke interface naar buiten. Hier ontbreken twee onafhankelijke beslissingen: één over of het clientproces een tijdelijke fout overleeft en één over of iets erboven het proces na het afsluiten opnieuw start. Alleen één daarvan repareren laat het andere gat open.

Begin bij wat de unit werkelijk deed, niet bij wat de monitoring beweert. systemctl status openvpn-client@office en journalctl -u openvpn-client@office -n 50 tonen de reden van afsluiten en de laatste regel die de client schreef voordat hij wegging.

Het proces stopte voordat iemand het merkte

Een client die zonder fout verdwijnt, is meestal expres gestopt. Het profiel bepaalt dat gedrag, niet de servicemanager: ping-exit beëindigt het proces zodra de tegenpartij stopt met antwoorden, terwijl ping-restart het proces houdt en zich erbinnen opnieuw verbindt. Sessielimieten en inactiviteitstimers geven van buiten hetzelfde beeld: geen tunnel en geen alarm.

De twee ping-richtlijnen kunnen niet samen in één profiel staan, dus kies er één en leg de keuze vast. Kijk ook naar de server, want zijn eigen ping-exit sluit een sessie ongeacht wat de client vroeg, en alleen het serverlog legt vast wie die beslissing nam.

Kiezen tussen ping-exit en ping-restart

Kies ping-restart voor een laptop of een externe locatie die zichzelf moet genezen, en bewaar ping-exit voor gevallen waarin een dode tunnel het proces moet stoppen zodat iets anders erop kan reageren. De getallen zijn minder belangrijk dan de relatie: ping 10 met ping-restart 60 betekent tien seconden stilte voor een test en zestig voor de herstart, wat agressief is op een verliesrijke mobiele verbinding en redelijk op een bekabelde. Schrijf de reden naast de regel, anders gaat de volgende lezer ervan uit dat de standaardwaarden bewust waren.

Bevestig daarna dat het echt het proces is dat stopte. Een unit die actief meldt terwijl de tunnel dood is, is een andere storing, die verderop wordt behandeld.

Toezicht dat de unit echt herstart

Op een systemd-host is de kleinste blijvende wijziging één drop-in-bestand: Restart=on-failure en RestartSec=10 in /etc/systemd/system/[email protected]/restart.conf. Een drop-in wordt alleen gelezen wanneer systemd zijn eigen definities herlaadt, dus voer daarna systemctl daemon-reload uit. Controleer met systemctl show -p Restart -p ExecMainStatus openvpn-client@office in plaats van aan te nemen dat de waarde is aangekomen. De instantie in de bestandsnaam moet het profiel zijn dat de unit echt laadt, dus een bestand voor office doet niets voor openvpn-client@home.

on-failure negeert één geval: een schone afsluiting met status nul. Sommige afbouwpaden eindigen zo, dus lees de vastgelegde status in plaats van de formulering van een manpagina te vertrouwen. Als je client met een nul opgeeft, heb je Restart=always nodig, en de prijs is dat een echt kapot profiel steeds terugkomt tot de startlimiet ingrijpt en het journaal vol raakt.

Restart=always grijpt ook in na een bewuste stop. Gebruik systemctl stop voor onderhoud, en maskeer de unit als die omlaag moet blijven terwijl je werkt.

Vang het lek terwijl de tunnel omlaag is

Toezicht brengt de tunnel terug; het voorkomt niet dat verkeer naar buiten gaat terwijl de tunnel weg is. persist-tun houdt het apparaat en zijn routes over herverbindingen heen, wat handig is en een venster opent. Het apparaat overleeft, de routes wijzen er nog naar en pakketten lekken onbeschermd en ongemeld naar buiten. Dat is een beleidskeuze, geen neutrale standaard.

Wanneer een host helemaal geen onbeschermde pakketten mag uitsturen, kan alleen de firewall dat garanderen. Een uitvoerregel die de tunnelinterface en het adres van de VPN-server toestaat en al het andere laat vallen, geldt nog steeds nadat de client sterft, en niets in de configuratie van de client zelf kan verkeer filteren dat de client niet vervoert.

Test het door de client expres te stoppen. Voer systemctl stop openvpn-client@office uit, dan curl -m 5 https://example.com, dat via de fysieke verbinding hoort te mislukken in plaats van te slagen. Een succes betekent dat de firewallregel ontbreekt of te ruim is.

Verbind opnieuw, bevestig dat de tunnel weer verkeer vervoert en voeg pas dan de controle toe aan de monitoring. ip addr pollen vanuit cron voor een tun-apparaat is het toezicht dat het vaakst faalt, want met persist-tun overleeft het apparaat de sessie en meldt de test gezondheid terwijl er niets wordt vervoerd.