WireGuard nezobrazuje posledný handshake: čo skontrolovať najskôr

Prázdne pole posledného handshake zvyčajne znamená, že rozhranie od spustenia nedokončilo žiadny handshake, čo o konfigurácii hovorí menej, než sa zdá. WireGuard mlčí, kým paket nemusí odísť cez rozhranie, takže neaktívny peer bez čoho odoslať hlási presne to. Zistite, či bolo niečo skutočne ponúknuté, skôr než začnete skúmať kľúče.

Testom je povolený paket smerom k cieľu, ktorý má peer niesť. Všetko ostatné na tejto stavovej obrazovke opisuje zámer, nie aktivitu.

Neaktívne rozhranie nemá čo hlásiť

WireGuard vykonáva handshake lenivo: prvý paket, ktorý potrebuje tunel, spustí výmenu a rozhranie dovtedy mlčí. Peer, ktorý bol nakonfigurovaný a nikdy nepoužitý, zobrazuje prázdny handshake, nula prijatých bajtov a rastúcu medzeru od posledného. Taký stav je pre neaktívneho klienta zdravý a znepokojujúci len vtedy, ak ste čakali, že prevádzka už prešla. Skontrolujte aj počítadlá prenosu, pretože oddeľujú nič-odoslané od skúšané-a-zlyhalo.

Ak počítadlá na oboch stranách stoja na nule, problém je nad tunelom. Nič sa nedostalo k rozhraniu, aby niečo spustilo.

Vyvolajte prevádzku, ktorú peer smie niesť

Vyberte adresu v rámci povolených prefixov peeru na miestnom počítači a potvrďte, že by ju smerovacia tabuľka poslala cez rozhranie. Cieľ mimo týchto prefixov vytvára bežnú smerovanú požiadavku úplne bez účasti WireGuardu. Použite službu, ktorá odpovedá rýchlo, napríklad ping alebo krátke TCP spojenie, aby mal pokus viditeľný začiatok a koniec. Potom si znova prečítajte riadok handshake, namiesto toho aby ste hľadeli na obrazovku a č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

Dopyt na trasu je dôležitejší ako ping. Ak uvádza fyzické rozhranie, paket nikdy nevstúpil do tunela a prázdny handshake je odpoveď smerovania, nie kryptografická. Opravte trasu skôr, než začnete ladiť peer.

Porovnajte pár kľúčov a koncový bod

Keď je prevádzka skutočne ponúknutá, ďalšou kontrolou je identita. Miestny súkromný kľúč musí zodpovedať verejnému kľúču, ktorý autorizuje druhá strana, nakonfigurovaný vzdialený verejný kľúč musí identifikovať zamýšľaný peer a akýkoľvek vopred zdieľaný kľúč sa musí zhodovať na oboch koncoch. Rozdiel jediného znaku v kľúči base64 vytvorí peer, ktorý vyzerá nakonfigurovaný a nikdy nedokončí výmenu. Porovnávajte so záznamom zriadenia namiesto regenerovania kľúčov, pretože nový kľúč zneplatní každý peer, ktorý dôveroval starému.

Koncový bod vyžaduje rovnakú kontrolu: názov hostiteľa, adresu, port UDP a rodinu použitú na dosiahnutie. Zastaraná adresa alebo nesprávny port dávajú ticho namiesto správy.

Sledujte vonkajšiu cestu UDP

Handshake cestuje ako UDP ku koncovému bodu, takže vonkajšia cesta ho musí niesť. Nižšie uvedené príkazy kontrolujú, či existuje poslucháč, či miestny zásobník odoslal datagram a ktorý koncový bod je nakonfigurovaný. Spustite zachytávanie pri vyvolávaní prevádzky, nie pred ním.

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

Zachytávanie, ktoré ukazuje začatie bez odpovede, ukazuje mimo stroja, pretože vzdialený koniec buď nepočúva, je filtrovaný, alebo je nesprávne adresovaný. Zachytávanie, ktoré neukazuje nič, znamená, že paket nikdy neodišiel, čo vás vracia k trase a k akejkoľvek značke socketu v hre. Keď spravujete oba konce, korelujte pokus podľa časovej pečiatky s úzkym zachytávaním na serveri, nie so všeobecným. Test portu TCP tu nič nedokazuje, pretože protokol je iba UDP.

Hneď ako sa objaví handshake, otestujte aplikáciu cez tunel, pretože dokončená výmena dokazuje identitu a dosiahnuteľnosť, nie použiteľnú priepustnosť alebo správny DNS. Uložte výstup stavu pred zmenou a po nej, a rozdiel sa stane vaším dôkazom.