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

For ein OpenVPN-server som ikkje startar ved oppstart, blir to løysingar tilbodne: vente på adressa, eller la tenesta prøve på nytt til bindinga lykkast. Begge handsamar same symptomet med ulik åtferd ved feil. Vente kodar ein bestemd føresetnad og feilar høgt når han manglar; nytt forsøk løyner føresetnaden og held fram med å prøve. Kva som høyrer heime i eininga di, kjem an på om adressa er ein designa avhengnad eller eit tilfelle av timing.

Begge er betre enn ein fast svevn, som korkje ventar på noko eller rapporterer kva han venta på.

Kva valet local faktisk krev

local namngir adressa dæmonen bind socketen sin til, og binding til ei adresse som ikkje finst enno feilar straks med ein feil om den førespurde adressa. Når valet manglar, lyttar dæmonen på alle adresser, og difor fungerer same profil på ei maskin der grensesnittet ikkje er kome opp: han lyttar overalt i staden for på den eine adressa du namngav. Den skilnaden er heile feilen, og han blir verande usynleg til ein omstart.

Kravet er ikkje at grensesnittet er oppe i ei generell meining. Adressa må vere tildelt rett grensesnitt i det augneblinken bindinga skjer, og det må vere underlagsgrensesnittet og ikkje ein tunnel som same dæmonen ville oppretta seinare. Ein kontroll som blir køyrd minutt etter innlogging provar ingenting om oppstartssekvensen.

Vente på adressa eller prøve bindinga på nytt

Venting tyder ein ExecStartPre som spør til adressa dukkar opp, med eit avgrensa tal forsøk og ein exit som ikkje er null når tida renn ut. Nytt forsøk tyder å la hovudprosessen feile og be tenestebehandlaren starte han igjen, til dømes Restart=on-failure med RestartSec=5. Den første rapporterer ein manglande føresetnad som ei feila eining, medan den andre rapporterer han som ei rekkje omstartar som til slutt stoppar, noko som er meir støyande i journalen men overlever ei adresse som kjem seint av grunnar du ikkje kan føresjå.

Føretrekk venting når adressa er ein designa avhengnad, og nytt forsøk når adressa vanlegvis dukkar opp men timinga varierer. Å kombinere dei er rimeleg: ei avgrensa venting dekkjer det vanlege tilfellet og ein omstartspolicy unntaket. Det ingen av dei bør gjere er å køyre for alltid, fordi ei eining som prøver på nytt i det uendelege løyner ein feilkonfigurasjon i staden for å rapportere han.

Kvifor network-online.target ikkje er nok

network-online.target lovar det den aktive nettverksimplementasjonen meiner med online, og ingenting utover det. Med systemd-networkd avgjer systemd-networkd-wait-online når målet er nådd, og standardoppfatninga av online kan vere oppfylt før den spesifikke adressa di finst. Under NetworkManager brukar wait-online-tenesta sine eigne reglar. Å sortere etter målet er ei solid grunnlinje, ikkje ein garanti for at éi adresse, DNS-svar eller ekstern part er klar.

Same resonnementet utelukkar dei vanlege alternativa. Ein autostart-oppføring på skrivebordet ventar på ei brukarøkt som kanskje aldri blir opna på ein server, og ein forseinka cron-kommando legg til forlopen tid utan å namngi ressursen han håpa skulle dukke opp. Begge kan sjå vellukka ut i månadsvis og deretter feile ved den eine oppstarten som betyr noko.

Kontroller bindinga etter ein kald oppstart

Verifiser med ein ekte kald oppstart i staden for ein tenesteomstart, fordi ein omstart arvar ei adresse som oppstartssekvensen måtte skape. Etter oppstart viser ss -lntp eller ss -lunp den lokale adressa kvar lyttar faktisk batt til, og journalctl -b -u openvpn-server@server viser om det første forsøket feila. Samanlikn den bundne adressa med den i profilen, og gjenta deretter samanlikninga etter ei nettverksgjenoppkopling.

Viss profilen aldri trong ei fast adresse, er det å fjerne local ei legitim forenkling, men gjer det til ei tryggleiksavgjerd i staden for ein feilsøkingsvane.

Å utvide lyttaren endrar kven som kan nå han, så kople den endringa til brannmurpolicyen som burde ha avgrensa han. Ei teneste som startar påliteleg på kvart grensesnitt har ikkje løyst det opphavlege problemet; ho har flytta problemet til nettverkskanten.