WireGuard ne prikaže zadnjega rokovanja: kaj preveriti najprej

Prazno polje zadnjega handshake običajno pomeni, da vmesnik od zagona ni dokončal nobenega rokovanja, kar o konfiguraciji pove manj, kot se zdi. WireGuard molči, dokler mora paket zapustiti vmesnik, zato nedejaven peer brez česa poslati poroča točno to. Ugotovite, ali je bilo kaj res ponujeno, preden pregledate ključe.

Preizkus je dovoljen paket proti cilju, ki naj bi ga peer prenašal. Vse ostalo na tem zaslonu stanja opisuje namero, ne dejavnosti.

Nedejaven vmesnik nima česa poročati

WireGuard izvaja rokovanja lenobno: prvi paket, ki potrebuje tunel, sproži izmenjavo, vmesnik pa do takrat molči. Peer, ki je bil nastavljen in nikoli uporabljen, prikazuje prazen handshake, nič prejetih bajtov in naraščajočo vrzel od zadnjega. To stanje je zdravo za nedejavnega odjemalca in zaskrbljujoče le, če ste pričakovali, da je promet že stekel. Preverite tudi števce prenosa, saj ločujejo nič-poslano od poskušeno-in-spodletelo.

Če števci na obeh straneh stojijo na nič, je težava nad tunelom. Nič ni prišlo do vmesnika, da bi kaj sprožilo.

Sprožite promet, ki ga peer sme prenašati

Izberite naslov znotraj dovoljenih predpon peera na lokalnem računalniku in potrdite, da bi ga usmerjevalna tabela poslala skozi vmesnik. Cilj zunaj teh predpon ustvari običajno usmerjeno zahtevo brez kakršne koli udeležbe WireGuarda. Uporabite storitev, ki hitro odgovori, na primer ping ali kratko povezavo TCP, da ima poskus viden začetek in konec. Nato znova preberite vrstico handshake, namesto da bi strmeli v zaslon in čakali.

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

Poizvedba poti je pomembnejša od pinga. Če navaja fizični vmesnik, paket ni nikoli vstopil v tunel in prazen handshake je odgovor usmerjanja, ne kriptografski. Popravite pot, preden odpravljate napake na peeru.

Primerjajte par ključev in končno točko

Ko je promet res ponujen, je naslednja preveritev identiteta. Lokalni zasebni ključ se mora ujemati z javnim ključem, ki ga odobri druga stran, nastavljeni oddaljeni javni ključ mora identificirati predvideni peer, morebitni vnaprej deljeni ključ pa se mora ujemati na obeh koncih. Ena sama razlika znaka v ključu base64 ustvari peer, ki je videti nastavljen in nikoli ne dokonča izmenjave. Primerjajte z evidenco oskrbe, namesto da bi znova ustvarili ključe, saj nov ključ razveljavi vsak peer, ki je zaupal staremu.

Končna točka zahteva enak pregled: ime gostitelja, naslov, vrata UDP in družino, uporabljeno za dosego. Zastarel naslov ali napačna vrata dajo tišino namesto sporočila.

Opazujte zunanjo pot UDP

Handshake potuje kot UDP proti končni točki, zato ga mora zunanja pot prenašati. Spodnji ukazi preverijo, ali obstaja poslušalec, ali je lokalni sklad oddal datagram in katera končna točka je nastavljena. Zaženite zajem med sprožanjem prometa, ne pred njim.

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

Zajem, ki prikazuje začetek brez odgovora, kaže izven stroja, ker oddaljeni konec bodisi ne posluša, bodisi je filtriran, bodisi je napačno naslovljen. Zajem, ki ne prikaže ničesar, pomeni, da paket ni nikoli odšel, kar vas vrne k poti in k morebitni oznaki vtičnice v igri. Ko upravljate oba konca, povežite poskus po časovnem žigu z ozkim zajemom na strežniku, ne s splošnim. Preizkus vrat TCP tu ničesar ne dokaže, ker je protokol samo UDP.

Takoj ko se pojavi handshake, preizkusite aplikacijo skozi tunel, ker dokončana izmenjava dokazuje identiteto in dosegljivost, ne uporabne prepustnosti ali pravilnega DNS. Shranite izhod stanja pred spremembo in po njej, in razlika bo postala vaš dokaz.