OpenVPN: lokal binding feiler ved oppstart — vente eller prøve på nytt

For en OpenVPN-server som ikke starter ved oppstart, tilbys to løsninger: vent på adressen, eller la tjenesten prøve på nytt til bindingen lykkes. Begge håndterer samme symptom med ulik oppførsel ved feil. Venting koder en bestemt forutsetning og feiler høyt når den mangler; nytt forsøk skjuler forutsetningen og fortsetter å prøve. Hvilken som hører hjemme i din unit avhenger av om adressen er en designet avhengighet eller et tilfelle av timing.

Begge er bedre enn en fast søvn, som verken venter på noe eller rapporterer hva den ventet på.

Hva local-valget faktisk krever

local navngir adressen dæmonen binder socketen sin til, og binding til en adresse som ikke finnes ennå feiler straks med en feil om den forespurte adressen. Når valget mangler, lytter dæmonen på alle adresser, og derfor fungerer samme profil på en maskin der grensesnittet ikke er kommet opp: den lytter overalt i stedet for på den ene adressen du navnga. Den forskjellen er hele feilen, og den forblir usynlig til en omstart.

Kravet er ikke at grensesnittet er oppe i en generell forstand. Adressen må være tildelt riktig grensesnitt i det øyeblikket bindingen skjer, og det må være underlagsgrensesnittet og ikke en tunnel som samme dæmon ville opprette senere. En kontroll som kjøres minutter etter innlogging beviser ingenting om oppstartssekvensen.

Vente på adressen eller prøve bindingen på nytt

Venting betyr en ExecStartPre som spør til adressen dukker opp, med et begrenset antall forsøk og en exit som ikke er null når tiden renner ut. Nytt forsøk betyr å la hovedprosessen feile og be tjenestebehandleren starte den igjen, for eksempel Restart=on-failure med RestartSec=5. Den første rapporterer en manglende forutsetning som en feilet unit, mens den andre rapporterer den som en serie omstarter som til slutt stopper, noe som er mer støyende i journalen men overlever en adresse som kommer sent av grunner du ikke kan forutse.

Foretrekk venting når adressen er en designet avhengighet, og nytt forsøk når adressen vanligvis dukker opp men timingen varierer. Å kombinere dem er rimelig: en begrenset venting dekker det vanlige tilfellet og en omstartspolicy unntaket. Det ingen av dem bør gjøre er å kjøre for alltid, fordi en unit som prøver på nytt i det uendelige skjuler en feilkonfigurasjon i stedet for å rapportere den.

Hvorfor network-online.target ikke er nok

network-online.target lover det den aktive nettverksimplementasjonen mener med online, og ingenting utover det. Med systemd-networkd avgjør systemd-networkd-wait-online når målet er nådd, og standardoppfatningen av online kan være oppfylt før din spesifikke adresse finnes. Under NetworkManager bruker wait-online-tjenesten sine egne regler. Å sortere etter målet er en solid grunnlinje, ikke en garanti for at én adresse, DNS-svar eller ekstern part er klar.

Samme resonnement utelukker de vanlige alternativene. En autostart-oppføring på skrivebordet venter på en brukerøkt som kanskje aldri åpnes på en server, og en forsinket cron-kommando legger til forløpt tid uten å navngi ressursen den håpet skulle dukke opp. Begge kan se vellykkede ut i månedsvis og deretter feile ved den ene oppstarten som betyr noe.

Kontroller bindingen etter en kald oppstart

Verifiser med en ekte kald oppstart i stedet for en tjenesteomstart, fordi en omstart arver en adresse som oppstartssekvensen måtte skape. Etter oppstart viser ss -lntp eller ss -lunp den lokale adressen hver lytter faktisk bandt til, og journalctl -b -u openvpn-server@server viser om det første forsøket feilet. Sammenlign den bundne adressen med den i profilen, og gjenta deretter sammenligningen etter en nettverksgjenoppkobling.

Hvis profilen aldri trengte en fast adresse, er det å fjerne local en legitim forenkling, men gjør det til en sikkerhetsbeslutning i stedet for en feilsøkingsvane.

Å utvide lytteren endrer hvem som kan nå den, så koble den endringen til brannmurpolicyen som burde ha begrenset den. En tjeneste som starter pålitelig på hvert grensesnitt har ikke løst det opprinnelige problemet; den har flyttet problemet til nettverkskanten.