OpenVPN: lokal binding mislykkes ved opstart — vent eller prøv igen

For en OpenVPN-server, der ikke starter ved opstart, tilbydes to løsninger: vent på adressen, eller lad tjenesten prøve igen, indtil bindingen lykkes. Begge behandler det samme symptom med forskellig adfærd ved fejl. Ventetid koder en bestemt forudsætning og fejler højlydt, når den mangler; genforsøg skjuler forudsætningen og bliver ved med at prøve. Hvilken der hører i din unit afhænger af, om den adresse er en designet afhængighed eller et tilfælde af timing.

Begge er bedre end en fast søvn, som hverken venter på noget eller rapporterer, hvad den ventede på.

Hvad local-indstillingen egentlig kræver

local angiver den adresse, som dæmonen binder sin socket til, og binding til en adresse, der ikke findes endnu, fejler straks med en fejl om den ønskede adresse. Når indstillingen mangler, lytter dæmonen på alle adresser, og derfor virker samme profil på en maskine, hvis interface ikke er kommet op: den lytter overalt i stedet for på den ene adresse, du angav. Den forskel er hele fejlen, og den forbliver usynlig indtil en genstart.

Kravet er ikke, at interfacet er oppe i en generel forstand. Adressen skal være tildelt det rigtige interface i det øjeblik, bindingen sker, og det skal være underlagsinterfacet frem for en tunnel, som den samme dæmon ville oprette senere. En kontrol, der køres minutter efter login, beviser intet om opstartsforløbet.

Vent på adressen kontra genforsøg på bindingen

Ventetid betyder en ExecStartPre, der poller, indtil adressen dukker op, med et begrænset antal forsøg og en ikke-nul afslutning, når tiden løber ud. Genforsøg betyder at lade hovedprocessen fejle og bede tjenestestyringen om at starte den igen, for eksempel Restart=on-failure med RestartSec=5. Den første rapporterer en manglende forudsætning som en fejlet unit, mens den anden rapporterer den som en række genstarter, der til sidst stopper; det er mere støjende i journalen, men overlever en adresse, der ankommer sent af grunde, du ikke kan forudsige.

Foretræk ventetid, når adressen er en designet afhængighed, og genforsøg, når adressen normalt dukker op, men dens timing varierer. At kombinere dem er rimeligt: en begrænset ventetid dækker det almindelige tilfælde, og en genstartsprofil dækker undtagelsen. Det, ingen af dem bør gøre, er at køre for evigt, fordi en unit, der genforsøger i det uendelige, skjuler en fejlkonfiguration i stedet for at rapportere den.

Hvorfor network-online.target ikke er nok

network-online.target lover, hvad den aktive netværksimplementering mener med online, og intet derudover. Med systemd-networkd afgør systemd-networkd-wait-online, hvornår målet er nået, og dens standardopfattelse af online kan være opfyldt, før din specifikke adresse findes. Under NetworkManager anvender wait-online-tjenesten sine egne regler. At sortere efter målet er en solid basislinje, ikke en garanti for, at én adresse, DNS-svar eller fjernpeer er klar.

Samme ræsonnement udelukker de sædvanlige alternativer. En autostart-post på skrivebordet venter på en brugersession, som måske aldrig åbnes på en server, og en forsinket cron-kommando tilføjer forløbet tid uden at nævne den ressource, den håbede ville dukke op. Begge kan se succesfulde ud i månedsvis og derefter fejle ved den ene opstart, der betyder noget.

Kontroller bindingen efter en kold opstart

Verificer med en rigtig kold opstart i stedet for en tjenestegenstart, fordi en genstart arver en adresse, som opstartsforløbet måtte skabe. Efter opstart viser ss -lntp eller ss -lunp den lokale adresse, som hver lytter faktisk bandt til, og journalctl -b -u openvpn-server@server viser, om det første forsøg fejlede. Sammenlign den bundne adresse med den i profilen, og gentag derefter sammenligningen efter en netværksgenopkobling.

Hvis profilen aldrig havde brug for en fast adresse, er fjernelse af local en legitim forenkling, men gør det til en sikkerhedsbeslutning i stedet for en fejlfindingsvane.

Udviddelse af lytteren ændrer, hvem der kan nå den, så par den ændring med den firewallpolitik, der burde have begrænset den. En tjeneste, der starter pålideligt på hvert interface, har ikke løst det oprindelige problem; den har flyttet problemet til netværkets kant.