OpenVPN: lokale binding mislukt bij het opstarten — wachten of opnieuw proberen

Voor een OpenVPN-server die bij het opstarten niet start, worden twee oplossingen aangeboden: wachten op het adres, of de service laten herproberen tot de binding slaagt. Beide pakken hetzelfde symptoom aan met ander faalgedrag. Wachten codeert een specifieke voorwaarde en faalt luid wanneer die ontbreekt; opnieuw proberen verbergt de voorwaarde en blijft proberen. Welke in je unit hoort, hangt ervan af of dat adres een ontworpen afhankelijkheid is of een toeval van timing.

Beide zijn beter dan een vaste slaap, die nergens op wacht en ook niet meldt waarop hij wachtte.

Wat de optie local werkelijk vereist

local benoemt het adres waaraan de daemon zijn socket bindt, en binden aan een adres dat nog niet bestaat mislukt onmiddellijk met een fout over het gevraagde adres. Als de optie ontbreekt, luistert de daemon op alle adressen, daarom werkt hetzelfde profiel op een machine waarvan de interface nog niet omhoog is: hij luistert overal in plaats van op het ene adres dat je noemde. Dat verschil is de hele fout, en het blijft onzichtbaar tot een herstart.

De eis is niet dat de interface in algemene zin omhoog is. Het adres moet op het moment van de binding aan de juiste interface zijn toegewezen, en het moet de onderliggende interface zijn en niet een tunnel die dezelfde daemon later zou maken. Een controle enkele minuten na het inloggen bewijst niets over de opstartvolgorde.

Wachten op het adres versus de binding herproberen

Wachten betekent een ExecStartPre die pollt tot het adres verschijnt, met een begrensd aantal pogingen en een exit die niet nul is wanneer de tijd om is. Opnieuw proberen betekent het hoofdproces laten falen en de servicemanager vragen het opnieuw te starten, bijvoorbeeld Restart=on-failure met RestartSec=5. Het eerste rapporteert een ontbrekende voorwaarde als een mislukte unit, terwijl het tweede die rapporteert als een reeks herstarts die uiteindelijk stopt, wat lawaaiiger is in het journal maar een adres overleeft dat te laat komt om redenen die je niet kunt voorspellen.

Geef de voorkeur aan wachten wanneer het adres een ontworpen afhankelijkheid is, en aan opnieuw proberen wanneer het adres meestal verschijnt maar de timing varieert. Ze combineren is redelijk: een begrensd wachten dekt het gewone geval en een herstartbeleid de uitzondering. Wat geen van beide moet doen is eeuwig draaien, want een unit die eindeloos herprobeert verbergt een verkeerde configuratie in plaats van die te rapporteren.

Waarom network-online.target niet genoeg is

network-online.target belooft wat de actieve netwerkimplementatie onder online verstaat, en niets meer. Met systemd-networkd bepaalt systemd-networkd-wait-online wanneer dat doel is bereikt, en de standaardopvatting van online kan al vervuld zijn voordat jouw specifieke adres bestaat. Onder NetworkManager past de wait-online-service zijn eigen regels toe. Na het doel ordenen is een gezonde basislijn, geen garantie dat één adres, DNS-antwoord of externe peer klaar is.

Dezelfde redenering sluit de gebruikelijke alternatieven uit. Een autostart-item op de desktop wacht op een gebruikerssessie die op een server misschien nooit opent, en een vertraagd cron-commando voegt verstreken tijd toe zonder de resource te noemen waarvan het hoopte dat die zou verschijnen. Beide kunnen maandenlang succesvol lijken en dan falen bij de ene boot die ertoe doet.

Controleer de binding na een koude start

Verifieer met een echte koude start in plaats van een serviceherstart, want een herstart erft een adres dat de opstartvolgorde moest creëren. Na het opstarten toont ss -lntp of ss -lunp het lokale adres waaraan elke listener zich werkelijk bond, en journalctl -b -u openvpn-server@server toont of de eerste poging mislukte. Vergelijk het gebonden adres met dat in het profiel en herhaal de vergelijking na een netwerkherverbinding.

Als het profiel nooit een vast adres nodig had, is het verwijderen van local een legitieme vereenvoudiging, maar maak er een beveiligingsbeslissing van in plaats van een gewoonte bij probleemoplossing.

Het verbreden van de listener verandert wie hem kan bereiken, dus koppel die wijziging aan het firewallbeleid dat hem had moeten beperken. Een service die op elke interface betrouwbaar start, heeft het oorspronkelijke probleem niet opgelost; hij heeft het probleem naar de rand van het netwerk verplaatst.