Hvorfor din OpenVPN-klient bliver nede efter en enkelt timeout

Mandag morgen: tunnelen, der kom op i fredags, er væk, grænsefladen står stadig på listen, og der står intet i journalen om, at nogen har bemærket det. Værten er online, dashboardet er grønt, og alt, hvad den sendte i weekenden, gik ud gennem den fysiske grænseflade i stedet. Der mangler to uafhængige beslutninger her: en om, hvorvidt klientprocessen overlever en forbigående fejl, og en om, hvorvidt noget oven over den starter processen igen, efter den er afsluttet. Retter man kun den ene, står den anden åbning tilbage.

Begynd med, hvad enheden faktisk gjorde, ikke med hvad overvågningen påstår. systemctl status openvpn-client@office og journalctl -u openvpn-client@office -n 50 viser årsagen til afslutningen og den sidste linje, klienten skrev, før den forsvandt.

Processen afsluttede, før nogen bemærkede det

En klient, der forsvinder uden fejl, er som regel afsluttet med vilje. Profilen bestemmer denne adfærd, ikke servicestyringen: ping-exit afslutter processen, så snart modparten holder op med at svare, mens ping-restart beholder processen og genopretter forbindelsen inde i den. Sessionsgrænser og inaktivitets timere giver det samme billede udefra: ingen tunnel og ingen alarm.

De to ping-direktiver kan ikke stå i samme profil, så vælg ét og notér valget. Se også på serveren, for dens egen ping-exit lukker en session uanset, hvad klienten bad om, og kun serverloggen registrerer, hvem der traf den beslutning.

Vælg mellem ping-exit og ping-restart

Vælg ping-restart til en laptop eller et fjernsted, der skal hele sig selv, og gem ping-exit til tilfælde, hvor en død tunnel skal stoppe processen, så noget andet kan reagere på den. Tallene betyder mindre end sammenhængen: ping 10 med ping-restart 60 betyder ti sekunders tavshed før en sonde og tres før genstarten, hvilket er aggressivt på et tabende mobilt link og rimeligt på et kablet. Skriv begrundelsen ved linjen, for den næste læser vil ellers antage, at standardværdierne var bevidste.

Bekræft derefter, at det virkelig er processen, der er afsluttet. En enhed, der rapporterer aktiv, mens tunnelen er død, er en anden fejl, som behandles længere nede.

Overvågning, der faktisk genstarter enheden

På en systemd-vært er den mindste varige ændring én drop-in-fil: Restart=on-failure og RestartSec=10 i /etc/systemd/system/[email protected]/restart.conf. En drop-in læses kun, når systemd genindlæser sine egne definitioner, så kør systemctl daemon-reload bagefter. Bekræft med systemctl show -p Restart -p ExecMainStatus openvpn-client@office i stedet for at antage, at værdien landede. Instansen i filnavnet skal være den profil, enheden faktisk indlæser, så en fil skrevet til office gør intet for openvpn-client@home.

on-failure ignorerer ét tilfælde: en ren afslutning med status nul. Nogle nedrivningsveje ender sådan, så læs den registrerede status i stedet for at tro på ordlyden i en manualsida. Hvis din klient giver op med et nul, har du brug for Restart=always, og prisen er, at en virkelig ødelagt profil bliver ved med at vende tilbage, indtil hastighedsgrænsen for start slår til, og journalen fyldes.

Restart=always udløses også efter et bevidst stop. Brug systemctl stop til vedligeholdelse, og maskér enheden, hvis den skal blive nede, mens du arbejder.

Fang lækagen, mens tunnelen er nede

Overvågning får tunnelen tilbage; den forhindrer ikke trafik i at forlade værten, mens tunnelen er væk. persist-tun beholder enheden og dens ruter gennem genopkoblinger, hvilket er bekvemt og åbner et vindue. Enheden overlever, ruterne peger stadig på den, og pakker siver ud ubeskyttet og urapporteret. Det er et politisk valg, ikke en neutral standard.

Når en vært slet ikke må udsende ubeskyttede pakker, kan kun firewalling garantere det. En udgangsregel, der tillader tunnelgrænsefladen og VPN-serverens adresse og dropper alt andet, holder stadig efter klientens død, og intet i klientens egen konfiguration kan filtrere trafik, som klienten ikke bærer.

Test det ved at stoppe klienten med vilje. Kør systemctl stop openvpn-client@office, derefter curl -m 5 https://example.com, som bør fejle i stedet for at lykkes over det fysiske link. En succes betyder, at firewallreglen mangler eller er for eftergivende.

Genopret forbindelsen, bekræft at tunnelen igen bærer trafik, og tilføj først derefter kontrollen til overvågningen. At polle ip addr fra cron efter en tun-enhed er den overvågning, der oftest fejler, fordi enheden med persist-tun lever længere end sessionen, og sonden rapporterer sundhed, mens intet bæres.