OpenVPN se plaaslike binding misluk tydens opstart: wag of probeer weer

Twee oplossings word aangebied vir 'n OpenVPN-bediener wat nie tydens opstart wil begin nie: wag vir die adres, of laat die diens weer probeer totdat die binding slaag. Hulle spreek dieselfde simptoom aan met verskillende foutgedrag. Wag kodifiseer 'n spesifieke voorvereiste en misluk luidkeels wanneer dit ontbreek; herprobeer verberg die voorvereiste en hou aan probeer. Watter een in jou eenheid hoort, hang daarvan af of daardie adres 'n ontwerpte afhanklikheid is of 'n toevalligheid van tydsberekening.

Albei is beter as 'n vaste slaap, wat nêrens op wag nie en ook nie rapporteer waarop dit gewag het nie.

Wat die opsie local werklik vereis

local benoem die adres waaraan die daemon sy soket bind, en om aan 'n adres te bind wat nog nie bestaan nie, misluk dadelik met 'n fout oor die versoekte adres. Wanneer die opsie afwesig is, luister die daemon op alle adresse, en daarom werk dieselfde profiel op 'n masjien wie se koppelvlak nog nie op is nie: dit luister oral in plaas van op die een adres wat jy genoem het. Daardie verskil is die hele fout, en dit bly onsigbaar tot 'n herbegin.

Die vereiste is nie dat die koppelvlak in 'n algemene sin op is nie. Die adres moet op die oomblik van die binding aan die regte koppelvlak toegewys wees, en dit moet die onderliggende koppelvlak wees eerder as 'n tonnel wat dieselfde daemon later sou skep. 'n Kontrole wat minute na aanmelding uitgevoer word, bewys niks oor die opstartvolgorde nie.

Wag vir die adres teenoor weer probeer van die binding

Wag beteken 'n ExecStartPre wat rondvra totdat die adres verskyn, met 'n begrensde aantal pogings en 'n nie-nul uitgang wanneer die tyd om is. Herprobeer beteken om die hoofproses te laat misluk en die diensbestuurder te vra om dit weer te begin, byvoorbeeld Restart=on-failure met RestartSec=5. Die eerste rapporteer 'n ontbrekende voorvereiste as 'n mislukte eenheid, terwyl die tweede dit rapporteer as 'n reeks herstarts wat uiteindelik stop, wat lawaaieriger in die joernaal is maar 'n adres oorleef wat laat opdaag om redes wat jy nie kan voorspel nie.

Verkies wag wanneer die adres 'n ontwerpte afhanklikheid is, en verkies herprobeer wanneer die adres gewoonlik verskyn maar die tydsberekening wissel. Om hulle te kombineer is redelik: 'n begrensde wag dek die algemene geval en 'n herbeginbeleid dek die uitskieter. Wat nie een van hulle moet doen nie, is om vir ewig te loop, want 'n eenheid wat onbepaald herprobeer, verberg 'n verkeerde instelling in plaas daarvan om dit te rapporteer.

Waarom network-online.target nie genoeg is nie

network-online.target belowe wat die aktiewe netwerkimplementering ook al met aanlyn bedoel, en niks meer nie. Met systemd-networkd besluit systemd-networkd-wait-online wanneer daardie teiken bereik is, en sy verstekbegrip van aanlyn kan bevredig word voordat jou spesifieke adres bestaan. Onder NetworkManager pas die wait-online-diens sy eie reëls toe. Om na die teiken te orden is 'n goeie basislyn, nie 'n waarborg dat een adres, DNS-antwoord of afgeleë eweknie gereed is nie.

Dieselfde redenasie sluit die gewone alternatiewe uit. 'n Outostart-inskrywing vir 'n rekenaar wag vir 'n gebruikersessie wat op 'n bediener dalk nooit oopgaan nie, en 'n vertraagde cron-opdrag voeg verstreke tyd by sonder om die hulpbron te noem wat dit gehoop het sou verskyn. Albei kan maande lank suksesvol lyk en dan misluk op die een herbegin wat saak maak.

Kontroleer die binding ná 'n koue herbegin

Verifieer met 'n werklike koue herbegin eerder as 'n diensherbegin, want 'n herbegin erf 'n adres wat die opstartvolgorde moes geskep het. Ná die opstart wys ss -lntp of ss -lunp die plaaslike adres wat elke luisteraar werklik gebind het, en journalctl -b -u openvpn-server@server wys of die eerste poging misluk het. Vergelyk die gebonde adres met die een in die profiel, en herhaal dan die vergelyking ná 'n netwerkherverbinding.

As die profiel nooit 'n vaste adres nodig gehad het nie, is die verwydering van local 'n wettige vereenvoudiging, maar maak dit 'n sekuriteitsbesluit eerder as 'n gewoonte vir foutopsporing.

Die verbreding van die luisteraar verander wie dit kan bereik, so pas daardie verandering saam met die firewallbeleid toe wat dit moes beperk het. 'n Diens wat betroubaar op elke koppelvlak begin, het nie die oorspronklike probleem opgelos nie; dit het die probleem na die netwerkrand verskuif.