WireGuard nezobrazuje poslední handshake: co zkontrolovat nejdřív

Prázdné pole posledního handshake obvykle znamená, že rozhraní od svého spuštění nedokončilo žádný handshake, což o konfiguraci říká méně, než se zdá. WireGuard mlčí, dokud paket nemusí odejít přes rozhraní, takže nečinný peer, který nemá co odeslat, hlásí přesně to. Zjistěte, zda bylo něco skutečně nabídnuto, dříve než začnete zkoumat klíče.

Testem je povolený paket směrem k cíli, který má peer nést. Všechno ostatní na této stavové obrazovce popisuje záměr, ne aktivitu.

Nečinné rozhraní nemá co hlásit

WireGuard provádí handshake líně: první paket, který potřebuje tunel, spustí výměnu a rozhraní do té doby mlčí. Peer, který byl nakonfigurován a nikdy nepoužit, ukazuje prázdný handshake, nula přijatých bajtů a rostoucí mezeru od posledního. Takový stav je pro nečinného klienta zdravý a znepokojivý jen tehdy, pokud jste čekali, že provoz už protekl. Zkontrolujte také počítadla přenosu, protože oddělují nic-odesláno od zkoušeno-a-selhalo.

Pokud jsou počítadla na obou stranách na nule, problém je výše než tunel. Nic se nedostalo k rozhraní, aby něco spustilo.

Vyvolejte provoz, který smí peer nést

Vyberte adresu uvnitř povolených prefixů peeru na místním stroji a potvrďte, že by ji směrovací tabulka poslala přes rozhraní. Cíl mimo tyto prefixy vytváří běžný směrovaný požadavek zcela bez účasti WireGuardu. Použijte službu, která odpovídá rychle, například ping nebo krátké TCP spojení, aby pokus měl viditelný začátek a konec. Potom si přečtěte řádek handshake znovu, místo abyste sledovali obrazovku a čekali.

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

Dotaz na trasu je důležitější než ping. Pokud uvádí fyzické rozhraní, paket nikdy nevstoupil do tunelu a prázdný handshake je odpověď směrování, nikoli kryptografická. Opravte trasu dřív, než začnete ladit peer.

Porovnejte pár klíčů a koncový bod

Jakmile je provoz skutečně nabídnut, další kontrolou je identita. Místní soukromý klíč musí odpovídat veřejnému klíči, který druhá strana autorizuje, nakonfigurovaný vzdálený veřejný klíč musí identifikovat zamýšlený peer a případný předem sdílený klíč se musí shodovat na obou stranách. Rozdíl jediného znaku v klíči base64 vytvoří peer, který vypadá nakonfigurovaně a nikdy nedokončí výměnu. Porovnávejte se záznamem zřizování místo regenerování klíčů, protože nový klíč zneplatní každý peer, který důvěřoval starému.

Koncový bod vyžaduje stejnou pozornost: název hostitele, adresu, port UDP a rodinu použitou k dosažení. Zastaralá adresa nebo špatný port dává ticho místo zprávy.

Sledujte vnější cestu UDP

Handshake cestuje jako UDP k koncovému bodu, takže vnější cesta ho musí nést. Níže uvedené příkazy kontrolují, zda existuje posluchač, zda místní zásobník odeslal datagram a který koncový bod je nakonfigurován. Spusťte zachytávání při vyvolávání provozu, ne před ním.

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

Zachcení, které ukazuje zahájení bez odpovědi, ukazuje mimo stroj, protože vzdálený konec buď neposlouchá, je filtrován, nebo je adresován nesprávně. Zachycení, které neukazuje nic, znamená, že paket nikdy neodešel, což vás vrací k trase a k jakékoli značce socketu ve hře. Když spravujete oba konce, korelujte pokus podle časového razítka s úzkým zachycením na serveru, ne s obecným. Test portu TCP zde nic nedokazuje, protože protokol je pouze UDP.

Jakmile se handshake objeví, otestujte aplikaci přes tunel, protože dokončená výměna dokazuje identitu a dosažitelnost, ne použitelnou propustnost nebo správný DNS. Uložte výstup stavu před změnou a po ní a rozdíl se stane vaším důkazem.