WireGuard ankoraŭ uzas la malnovan finpunkton post DNS-ŝanĝoj

La tunelo ĉesis pasigi trafikon post kiam la DNS-rikordo de la servilo moviĝis, kaj la nomo solviĝas ĝuste de la sama maŝino. Tiuj du faktoj ne kontraŭas unu la alian. WireGuard-agordo enhavas finpunkton, kaj la ilo solvas la nomon en la momento, kiam ĝi aplikas tiun agordon, do la kuranta interfaco povas daŭre uzi la adreson, kiun ĝi prenis antaŭ horoj. Kontrolu, kion la interfaco uzas, antaŭ ol vi anstataŭigos ŝlosilojn aŭ tuŝos la tunelan gamon.

La nomo solviĝas unufoje, ne kontinue

Baza WireGuard-agordo prenas finpunkton kiel adreson kaj pordon, kaj la ilo, kiu levas interfacon, solvas gastigantan nomon en tiu momento. Nenio en la baza protokolo demandas DNS laŭ horaro, kaj klienta aplikaĵo povas aldoni sian propran refreŝigan konduton supre. Registri la solvitan adreson, la familion kaj la pordon apud la nomo igas la breĉon videbla. Sen tiu registro la agordo aspektas ĝusta, dum la interfaco parolas kun io alia.

Estas unu vera aŭtomata ĝisdatigo, kaj indas scii ĝin, ĉar ĝi similas DNS-refreŝigon sen esti tio. Kunula finpunkto povas moviĝi, kiam ĝuste aŭtentikigita trafiko alvenas de nova adreso, kio estas movado prefere ol nomsolvado. Ĝi sekvas la kunulon, do ĝi ne povas malkovri nerilatan novan servilon, kiun la malnova finpunkto neniam kontaktis.

Komparu la registron kun la uzata adreso

Demandu la dokumentitan nomon per la solvilo, kiun la kliento uzas, poste demandu la interfacon, kiun finpunkton ĝi tenas. La du respondoj estas la komparo, kiu decidas la reston de ĉi tiu paĝo:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

La manlibro pri wg(8) dokumentas la subkomandojn show, kiujn uzas tiuj linioj. Komparu ankaŭ la adresan familion, ne nur la adreson, ĉar registro, kiu akiris IPv6-eron, estas alia komparo ol tiu, kies IPv4-adreso ŝanĝiĝis. Se la finpunkto diferencas de la registro, la interfaco funkcias per eksdata informo kaj la nomo neniam estis la problemo. Se ili kongruas kaj la tunelo ankoraŭ malsukcesas, iru al la aŭskultanto kaj la reguloj, ne al la profilo.

La tempindiko de la manpremo estas en tiu bloko, ĉar la finpunkto sola ne diras, ĉu la kunulo estas atingebla. Eksdata tempindiko apud ĝusta finpunkto estas voja problemo, ne solva problemo, kaj tiu distingo ŝanĝas, kion vi tuŝos poste.

Restartigu per la administrilo de la interfaco

Post kiam la finpunkto konfirmiĝis eksdata, ĝisdatigu ĝin per la mekanismo, kiu posedas la interfacon anstataŭ redakti la vivan agordon. Por interfaco startigita de wg-quick tio estas malsupren kaj supren, por systemd-unuo tio estas restartigo, kaj por interfaco posedata de administrilo tio estas ŝanĝo farita en tiu administrilo, ĉar redakto dum funkciado estas anstataŭigita ĉe la sekva apliko:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Poste konfirmu, ke la anstataŭa aŭskultanto kaj ĝia identeco estas la servo, kiun vi intencis. DNS-movo ne estas identecŝanĝo, do ĝi neniam devus esti la okazo fidi ŝlosilon, kiun vi ne kontrolis. Se la interfaco nun raportas la novan adreson kaj ankoraŭ ne produktas manpremon, la fuŝo moviĝis al la nova reta vojo aŭ aŭskultanto, kio estas progreso, ne la sama fuŝo dufoje.

Unue la manpremo, poste la datena vojo

Apartigu la du rezultojn antaŭ ol elekti kontrol-liston. Manpremo, kiu sukcesas sub aplikaĵo, kiu malsukcesas, estas problemo de la datena vojo: vojoj, permesitaj prefiksoj aŭ DNS ene de la tunelo. Manpremo, kiu neniam okazas, estas problemo de atingeblo aŭ identeco ĉe la finpunkto. Miksi la du produktas raporton, kiun neniu povas ripeti, kaj ŝanĝoprotokolon kun tri nerilataj redaktoj.

Registru la nomon, la solvitan adreson, la uzatan finpunkton kaj ĉu la manpremo finiĝis. Tiuj kvar faktoj respondas la demandon, kiun ĉi tiu fuŝo senĉese starigas, kaj ili igas la sekvan okazon duminuta kontrolo. Nomprizorgo kaj klienta adoptado restas apartaj taskoj: korekti la registron ne faras la adoptadon, kaj restartigi la interfacon ne riparas registron, kiu ankoraŭ estas malĝusta.