WireGuard montras neniun plej lastan manpremon: kion kontroli unue

Malplena kampo de la lasta manpremo kutime signifas, ke la interfaco ne kompletigis manpremon de kiam ĝi ekfunkciis, kio diras malpli pri la agordo ol ĝi ŝajnas. WireGuard restas silenta ĝis paketo devas eliri tra la interfaco, do senaktiva peer sen io sendebla raportas ĝuste tion. Klarigu, ĉu io efektive estis proponita, antaŭ ol vi ekzamenu la ŝlosilojn.

La testo estas permesita paketo al celo, kiun la peer devus porti. Ĉio alia sur tiu stata ekrano priskribas intencon, ne agadon.

Senaktiva interfaco havas nenion raportebla

WireGuard faras manpremojn mallaboreme: la unua paketo, kiu bezonas la tunelon, ekigas la interŝanĝon, kaj la interfaco restas silenta ĝis tiam. Peer, kiu estis agordita kaj neniam uzita, montras malplenan manpremon, nulon da ricevitaj bitokoj kaj kreskantan interspacon de la lasta. Tiu stato estas sana por senaktiva kliento kaj alarms nur se vi atendis, ke trafiko jam fluis. Kontrolu ankaŭ la transdonajn nombrilojn, ĉar ili apartigas nenio-sendita de provita-kaj-malsukcesinta.

Se la nombriloj staras je nulo ambaŭflanke, la problemo estas supre de la tunelo. Nenio atingis la interfacon por ekigi ion.

Ekigu trafikon, kiun la peer rajtas porti

Elektu adreson ene de la permesitaj prefiksoj de la peer, sur la loka maŝino, kaj konfirmu, ke la enkursiga tabelo sendus ĝin tra la interfaco. Celo ekster tiuj prefiksoj produktas ordinaran enkursigitan peton tute sen partopreno de WireGuard. Uzu servon, kiu respondas rapide, ekzemple ping aŭ mallongan TCP-ligon, por ke la provo havu videblan komencon kaj finon. Poste relegu la manpreman linion anstataŭ rigardi la ekranon kaj atendi.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

La itinera demando gravas pli ol la ping. Se ĝi nomas la fizikan interfacon, la paketo neniam eniris la tunelon kaj la malplena manpremo estas enkursiga respondo, ne kriptografia. Riparu la itineron antaŭ ol sencimigi la peer.

Komparu la ŝlosilparon kaj la finpunkton

Post kiam trafiko estas vere proponita, identeco estas la sekva kontrolo. La loka privata ŝlosilo devas korespondi al la publika ŝlosilo, kiun la alia flanko rajtigas, la agordita fora publika ŝlosilo devas identigi la celitan peer, kaj ajna antaŭe dividita ŝlosilo devas kongrui ambaŭflanke. Unuopa signa diferenco en base64-ŝlosilo produktas peer, kiu aspektas agordita kaj neniam kompletigas interŝanĝon. Komparu kun la proviza registro anstataŭ regeneri ŝlosilojn, ĉar nova ŝlosilo nuligas ĉiun peer, kiu fidis la malnovan.

La finpunkto bezonas la saman ekzamenon: gastnomo, adreso, UDP-pordo kaj la familio uzata por atingi ĝin. Malnova adreso aŭ malĝusta pordo produktas silenton anstataŭ mesaĝon.

Observu la eksteran UDP-vojon

La manpremo vojaĝas kiel UDP al la finpunkto, do la ekstera vojo devas porti ĝin. La subaj komandoj kontrolas, ĉu ekzistas aŭskultanto, ĉu la loka stako elsendis la datagramon kaj kiu finpunkto estas agordita. Rulu la kaptadon dum vi ekigas trafikon, ne antaŭe.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

Kaptado, kiu montras la iniciaton sen respondo, montras ekster la maŝinon, ĉar la fora flanko aŭ ne aŭskultas, aŭ estas filtrita, aŭ malĝuste adresita. Kaptado, kiu montras nenion, signifas, ke la paketo neniam eliris, kio revenigas vin al la itinero kaj al ajna soketa marko en ludo. Se vi administras ambaŭ flankojn, korelaciu la provon laŭ tempindiko kun mallarĝa kaptado sur la servilo anstataŭ ĝenerala. TCP-porda testo pruvas nenion ĉi tie, ĉar la protokolo estas nur UDP.

Kiam manpremo aperas, testu aplikaĵon tra la tunelo, ĉar kompletigita interŝanĝo pruvas identecon kaj atingeblon, ne uzeblan trafkapton aŭ ĝustan DNS. Konservu la statan eligon antaŭ kaj post la ŝanĝo, kaj la diferenco fariĝos via pruvo.