OpenVPN: loka ligado malsukcesas ĉe ekŝargo — atendi aŭ reprovi

Por OpenVPN-servilo, kiu ne ekstartas ĉe ekŝargo, oni proponas du solvojn: atendi la adreson, aŭ lasi la servon reprovi ĝis la ligado sukcesos. Ambaŭ traktas la saman simptomon per malsama fiaska konduto. Atendado kodigas specifan antaŭkondiĉon kaj laŭte fiaskas kiam ĝi mankas; reprovado kaŝas la antaŭkondiĉon kaj daŭre provas. Kiu el ili apartenas al via unuo dependas de tio, ĉu tiu adreso estas projektita dependeco aŭ hazardo de tempo.

Ambaŭ pli bonas ol fiksa dormo, kiu nek atendas ion nek raportas, kion ĝi atendis.

Kion la opcio local efektive postulas

local nomas la adreson, al kiu la demono ligas sian soketon, kaj ligado al adreso, kiu ankoraŭ ne ekzistas, tuj fiaskas per eraro pri la petita adreso. Kiam la opcio mankas, la demono aŭskultas ĉiujn adresojn, tial la sama profilo funkcias sur maŝino, kies interfaco ankoraŭ ne supreniris: ĝi aŭskultas ĉie anstataŭ ĉe la sola adreso, kiun vi nomis. Tiu diferenco estas la tuta fiasko, kaj ĝi restas nevidebla ĝis restartigo.

La postulo ne estas, ke la interfaco estu supren en iu ĝenerala senco. La adreso devas esti atribuita al la ĝusta interfaco en la momento de la ligado, kaj ĝi devas esti la baza interfaco, ne tunelo, kiun la sama demono kreus poste. Kontrolo farita kelkajn minutojn post ensaluto pruvas nenion pri la ekŝarga sinsekvo.

Atendi la adreson kontraŭ reprovi la ligadon

Atendado signifas ExecStartPre, kiu demandas ĝis la adreso aperos, kun limigita nombro da provoj kaj nenula eliro kiam la tempo finiĝos. Reprovado signifas lasi la ĉefan procezon fiaski kaj peti la servadministrilon restartigi ĝin, ekzemple Restart=on-failure kun RestartSec=5. La unua raportas mankantan antaŭkondiĉon kiel fiaskintan unuon, dum la dua raportas ĝin kiel vicon da restartigoj, kiu fine haltas; tio estas pli brua en la ĵurnalo sed postvivas adreson, kiu alvenas malfrue pro kialoj, kiujn vi ne povas antaŭvidi.

Preferu atendadon kiam la adreso estas projektita dependeco, kaj reprovadon kiam la adreso kutime aperas sed ĝia tempo varias. Kombini ilin estas racia: limigita atendado kovras la ordinaran kazon kaj restariga politiko la escepton. Kion nek unu nek la alia devus fari estas ruliĝi eterne, ĉar unuo, kiu reprovas senfine, kaŝas misagordon anstataŭ raporti ĝin.

Kial network-online.target ne sufiĉas

network-online.target promesas tion, kion la aktiva reta efektivigo komprenas per online, kaj nenion pli. Kun systemd-networkd, systemd-networkd-wait-online decidas kiam tiu celo estas atingita, kaj ĝia implicita kompreno de online povas esti plenumita antaŭ ol via specifa adreso ekzistas. Sub NetworkManager, la servo wait-online aplikas siajn proprajn regulojn. Ordigo post la celo estas solida bazlinio, ne garantio, ke unu adreso, DNS-respondo aŭ fora partnero pretas.

La sama rezonado ekskludas la kutimajn alternativojn. Labortabla aŭtomata starta ero atendas uzantan sesion, kiu eble neniam malfermiĝos sur servilo, kaj prokrastita cron-komando aldonas pasintan tempon sen nomi la rimedon, kies aperon ĝi esperis. Ambaŭ povas ŝajni sukcesaj dum monatoj kaj poste fiaski ĉe la sola ekŝargo, kiu gravas.

Kontrolu la ligadon post malvarma ekŝargo

Kontrolu per reala malvarma ekŝargo anstataŭ per serva restartigo, ĉar restartigo heredas adreson, kiun la ekŝarga sinsekvo devis krei. Post ekŝargo, ss -lntp aŭ ss -lunp montras la lokan adreson, al kiu ĉiu aŭskultanto efektive ligiĝis, kaj journalctl -b -u openvpn-server@server montras, ĉu la unua provo fiaskis. Komparu la ligitan adreson kun tiu en la profilo, poste ripetu la komparon post reta rekonekto.

Se la profilo neniam bezonis fiksan adreson, forigi local estas legitima simpligo, sed faru tion sekureca decido anstataŭ solvada kutimo.

Larĝigo de la aŭskultanto ŝanĝas, kiu povas atingi ĝin, do kunigu tiun ŝanĝon kun la fajroŝirma politiko, kiu devintus limigi ĝin. Servo, kiu fidinde ekstartas sur ĉiu interfaco, ne solvis la originan problemon; ĝi movis la problemon al la reta rando.