WireGuard funkcias nur post kiam la servilo unue sendas: scio pri la finpunkto

La tunelo ŝajnas funkcii nur post kiam la servilo unue sendas ion. Komencu de la kliento kaj nenio okazas, atendu kelkajn sekundojn, provu denove kaj ĝi sukcesas. La kutima diagnozo estas rompita NAT, kaj la kutima diagnozo estas malĝusta. Kio ŝanĝiĝis estas, ke unu samtavolano lernis, kie loĝas la alia.

Scio pri la finpunkto, ne atingeblo

WireGuard-samtavolano ne komencos manpremon ĝis ĝi scias, kien sendi ĝin. La agordo liveras tion kiel finpunkton el adreso kaj pordo, kaj la kuranta stato spuras la finpunkton, kiun ĝi nuntempe kredas.

wg show presas ambaŭ flankojn de tiu bildo, kaj samtavolano sen finpunkto en la eligo povas komenci nenion, kiom ajn ĝustaj estas ĝia publika ŝlosilo kaj permesitaj prefiksoj. Komparu la vidon de la kliento kun tiu de la servilo antaŭ ol ŝanĝi ajnan regulon, ĉar la du ofte malkonsentas pri tio, kiu scias kion.

Kiel samtavolano lernas finpunkton

WireGuard estas intence silenta. Kiam ĝuste aŭtentigita paketo alvenas de adreso, kiun la samtavolano ne atendis, la efektivigo ĝisdatigas la finpunkton de tiu samtavolano al la nova fonto, kaj tiel funkcias migrado sur tekkomputilo, kiu ŝanĝas retojn. Tiu konduto klarigas la direkto-dependecon: se la servilo sendas unue kaj ĝia paketo atingas la klienton, la kliento lernas la nunan adreson de la servilo kaj povas respondi. Ĝis tiam ĝi havas nenie por sendi. La mekanismo estas aŭtentigita migrado, ne limpado de fido ĉe unua uzo, ĉar la paketo devis esti valida antaŭ ol la finpunkto moviĝis.

La ila dokumentaro por wg priskribas tiun ĝisdatigon, kaj indas legi ĝin unufoje, se vi projektos ĉirkaŭ ĝi.

Stathava traduko aldonas sian propran direkton

Kie UDP pasas tra traduka enirejo, la enirejo kreas staton por la unua paketo, kiun ĝi vidas. RFC 4787 priskribas tiun konduton kaj la tempolimojn, kiuj finfine forigas la mapadon. Neaktiva mapado eksvalidiĝas, kaj envenanta paketo de la malproksima flanko tiam estas forĵetata de la enirejo antaŭ ol ĝi atingas la gastiganton. Tunelo, kiu funkciis la tutan matenon, ĉesas respondi posttagmeze ĝuste pro tiu kaŭzo.

Ĉi tio estas dua kaj sendependa mekanismo, kiu produktas la saman direkto-simptomon. Kaj la scio pri la finpunkto kaj la traduka stato devas esti ĝustaj, kaj ripari unu ne riparas la alian.

Agordi la direkton, kiun vi vere volas

Por kliento, kiu devas komenci la konekton, metu la finpunkton de la servilo en la samtavolan sekcion de la kliento kaj lasu ĝin tie. Fidi, ke la servilo sendos unue, estas fidi hazardan ordon de trafiko, kiu ŝanĝiĝos en kvieta reto. La agordo devus deklari la celatan direkton, ne malkovri ĝin.

Por samtavolano malantaŭ traduko, kiu devas resti atingebla, ŝaltu daŭran keepalive ĉe tiu flanko. Keepalive ĉiun 25 sekundojn estas la kutima komenca valoro, kaj ĝia celo estas teni la mapadon malfermita, ne testi la tunelon. Elektu unu flankon por porti ĝin, ĉar ŝalti ĝin ĉe ambaŭ duobligas la trafikon kaj la bruon de la protokolo sen plibonigi la rezulton.

Komparu la staton antaŭ kaj post la ekigilo

Kaptu la du vidojn en la momento, kiam ĝi malsukcesas, poste denove post kiam la servilo sendas. La unua komando montras finpunktojn kaj la aĝon de la manpremo. La dua montras, ĉu ekzistas traduka enskribo por la pordo. La kaptaĵo montras, kiu direkto vere transiris la draton, kaj la voja kontrolo konfirmas, ke la kliento ne sendas tiun trafikon tute aliloken.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Notu la kolumnon de la finpunkto kaj la tradukan enskribon kune. Samtavolano sen finpunkto kaj enirejo sen mapado estas du malsamaj difektoj. Nur unu el ili estas riparata per keepalive.