Lokal bindning i OpenVPN misslyckas vid start: vänta eller försöka igen
När den lokala adressen ännu inte är uppe kan OpenVPN inte binda. Jämför en tidsbegränsad väntan med en omstartsprincip och se varför network-online.target inte är någon garanti.
För en OpenVPN-server som inte startar vid uppstart erbjuds två lösningar: vänta på adressen eller låt tjänsten försöka igen tills bindningen lyckas. De åtgärdar samma symptom men beter sig olika vid fel. Väntan kodar ett bestämt förkrav och misslyckas högljutt när det saknas; upprepade försök döljer förkravet och fortsätter försöka. Vilken som hör hemma i din unit beror på om adressen är ett avsiktligt beroende eller en slump i tidsordningen.
Båda är bättre än en fast sömn, som varken väntar på något eller redovisar vad den väntade på.
Vad alternativet local egentligen kräver
local anger den adress som daemonen binder sin socket till, och bindning till en adress som ännu inte finns misslyckas direkt med ett fel om den begärda adressen. När alternativet saknas lyssnar daemonen på alla adresser, och därför fungerar samma profil på en maskin vars gränssnitt inte kommit upp: den lyssnar överallt i stället för på den enda adress du angav. Den skillnaden är hela felet, och den förblir osynlig till en omstart.
Kravet är inte att gränssnittet är uppe i någon allmän mening. Adressen måste vara tilldelad rätt gränssnitt i själva bindningsögonblicket, och det måste vara underliggande gränssnitt, inte en tunnel som samma daemon skulle skapa senare. En kontroll som körs minuter efter inloggning säger ingenting om startsekvensen.
Vänta på adressen eller försöka binda igen
Väntan innebär en ExecStartPre som pollar tills adressen dyker upp, med ett begränsat antal försök och en nollskild utgång när tiden tar slut. Upprepade försök innebär att låta huvudprocessen misslyckas och be tjänstehanteraren starta den igen, till exempel Restart=on-failure med RestartSec=5. Det första rapporterar ett saknat förkrav som en misslyckad unit, medan det andra rapporterar det som en serie omstarter som till slut upphör; det låter mer i journalen men klarar en adress som kommer sent av skäl du inte kan förutse.
Föredra väntan när adressen är ett avsiktligt beroende, och föredra upprepade försök när adressen vanligen dyker upp men tidpunkten varierar. Att kombinera dem är rimligt: en tidsbegränsad väntan täcker det vanliga fallet och en omstartsprincip täcker undantaget. Ingendera bör köra för evigt, eftersom en unit som försöker oändligt döljer en felkonfiguration i stället för att rapportera den.
Varför network-online.target inte räcker
network-online.target lovar precis vad den aktiva nätverksimplementationen menar med online, och inget mer. Med systemd-networkd avgör systemd-networkd-wait-online när målet nås, och dess förvalda syn på online kan vara uppfylld innan din specifika adress finns. Under NetworkManager tillämpar wait-online-tjänsten sina egna regler. Att ordna sig efter målet är en sund grundval, inte en garanti för att en adress, ett DNS-svar eller en fjärrpeer är klar.
Samma resonemang utesluter de vanliga alternativen. En autostartpost på skrivbordet väntar på en användarsession som kanske aldrig öppnas på en server, och ett fördröjt cron-kommando lägger till förfluten tid utan att namnge resursen det hoppades skulle dyka upp. Båda kan se framgångsrika ut i månader och sedan misslyckas vid den enda uppstart som betyder något.
Kontrollera bindningen efter en kallstart
Verifiera med en riktig kallstart i stället för en omstart av tjänsten, eftersom en omstart ärver en adress som startsekvensen måste skapa. Efter uppstarten visar ss -lntp eller ss -lunp den lokala adress som varje lyssnare faktiskt band till, och journalctl -b -u openvpn-server@server visar om det första försöket misslyckades. Jämför den bundna adressen med den i profilen och upprepa jämförelsen efter en återanslutning till nätet.
Om profilen aldrig behövde en fast adress är det en legitim förenkling att ta bort local, men gör det till ett säkerhetsbeslut och inte till en felsökningsvana.
Att vidga lyssnaren ändrar vem som kan nå den, så para ihop ändringen med brandväggsprincipen som borde ha begränsat den. En tjänst som startar tillförlitligt på varje gränssnitt har inte löst det ursprungliga problemet; den har flyttat problemet till nätets kant.