Handshake funkcias, adreso mankas: tri statoj de WireGuard

WireGuard povas havi freŝan handshake kaj samtempe neniun adreson, kaj tiu stato estas kohera, ne kontraŭdira. La handshake estas okazaĵo de la peer, la adreso apartenas al la interfaco, kaj la vojo decidas, per kiu suprenligo paketo eliras. Tri tavoloj, tri posedantoj, kaj ĉiu povas fiaski dum la aliaj du aspektas sanaj.

Legi ilin kiel unu statuson estas tio, kio transformas duminutan diagnozon en tutan posttagmezon da restarigado de servoj.

Handshake estas okazaĵo de la peer, ne okazaĵo de adresado

La handshake de WireGuard pruvas, ke la agordita peer respondis per valida ŝlosilo kaj ke la sesiaj ŝlosiloj estas aktualaj. Ĝi diras nenion pri la loka adreso sur la interfaco, nek pri tio, ĉu iu vojo montras tien. Helpeto aŭ reta administrilo atribuas la adreson, dum la protokola agordo nur nomas peer-ojn kaj ŝlosilojn. Konfuzi la du estas kiel sana handshake estas legata kiel funkcianta tunelo.

Tial wg show povas raporti kelksekundan handshake sur interfaco, kiu ne povas akcepti eĉ unu paketon de aplikaĵo.

Administrilo, kiu rekreas la interfacon, povas forigi la adreson sen tuŝi la peer-agordon, kaj la sekva handshake sukcesas tuj ĉar la ŝlosiloj neniam ŝanĝiĝis. La protokola linio pri sukcesa handshake estas preciza kaj nerelevanta por la fiasko.

La adreso de la interfaco havas sian propran posedanton

Adreso sur la tunela aparato povas veni el la Address linio de helpeto, el DHCP-kliento kuranta sur la interfaco, aŭ el administra demono, kiu kreas ĝin ĉe konektiĝo. Kio ajn ĝi estas, tiu komponanto posedas la adreson kaj restarigos ĝin aŭ ne laŭ sia propra logiko. Legi la adreson sen nomi ĝian posedanton lasas vin sen klarigo, kial ĝi malaperis.

Du posedantoj sur unu interfaco estas la klasika fiasko. Lanĉi helpeton kaj surtablan retan administrilon super la sama aparato kreas konkuradon, en kiu unu forigas tion, kion la alia ĵus agordis, kaj la finpunkto daŭre respondas la tutan tempon.

Elektu unu posedanton kaj lasu la alian ilon observi anstataŭ administri. Tiu decido indas skribiĝi, ĉar la simptomo aperas semajnojn poste kaj aspektas kiel hazarda adresa perdo.

Vojo elektas suprenligon, ne la interfaco

Interna vojo montranta al wg0 decidas, ke trafiko eniras la tunelon. Aparta decido sendas la ĉifritajn eksterajn paketojn al la peer, kaj sur gastiganto kun pluraj suprenligoj tiu decido venas el la plusenda tabelo kaj la politikaj reguloj. Wi-Fi-vojaĝado povas ŝanĝi la eksteran vojon sen tuŝi la internan adreson.

Do funkcianta tunelo kaj neatingebla peer estas kongruaj statoj, kaj same ĝusta peer kun rompita interna vojo. La tri observoj devas esti prenitaj kune, en la sama momento, alie la komparo estas sensenca.

Komparu la tri statojn en unu paŝo

Tri nurlegaj komandoj respondas la tri demandojn en la ordo, kiu izolas la fiaskon plej rapide. Rulu ilin sen ŝanĝi ion inter ili.

ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer

La unua montras, ĉu la interfaco entute havas adreson, kaj la dua montras, kiun aparaton specifa celo uzus nun. La tria raportas la horon de la lasta handshake kaj la bajtajn nombrilojn, kaj ĝi estas la sola el la tri, kiu priskribas la peer anstataŭ la lokan gastiganton.

Legu la nombrilojn same kiel la tempostampon. Handshake, kiu daŭre refreŝiĝas dum la transigo restas ebena, signifas, ke la peer respondas sed nenio utila trapasas, kio montras al enkursigo aŭ ACL anstataŭ al ŝlosiloj. Tempostampo, kiu ĉesas antaŭeniri dum adreso ĉeestas, montras supre anstataŭe. Ambaŭ legadoj venas el la sama eliga linio, kaj neniu estas videbla se vi nur kontrolas, ĉu handshake ekzistas.

Korektu la specifan staton, kiu estas malĝusta, poste retestu la aplikaĵon anstataŭ la tunelon. Freŝa handshake estas pruvo pri la peer, kaj pruvo pri la peer ne estas pruvo, ke la sekva peto de via retumilo trovos adreson, vojon kaj funkciantan suprenligon. La manlibro de wg-quick eksplicite diras, kiujn el tiuj la helpeto starigas kaj kiuj apartenas al la protokolo.