WireGuard ei näytä viimeisintä kättelyä: mitä tarkistaa ensin

Tyhjä viimeisimmän kättelyn kenttä tarkoittaa yleensä, että liitäntä ei ole suorittanut kättelyä käynnistymisensä jälkeen, mikä kertoo kokoonpanosta vähemmän kuin näyttää. WireGuard on hiljaa, kunnes paketin on poistuttava liitännän kautta, joten joutilas peer, jolla ei ole mitään lähetettävää, raportoi juuri sen. Selvitä, tarjottiinko jotain todella, ennen kuin tutkit avaimia.

Testi on sallittu paketti kohti kohdetta, jonka peerin pitäisi kuljettaa. Kaikki muu tuolla tilanäytöllä kuvaa aikomusta, ei toimintaa.

Joutilaalla liitännällä ei ole mitään raportoitavaa

WireGuard tekee kättelyt laiskasti: ensimmäinen tunnelia tarvitseva paketti käynnistää vaihdon, ja liitäntä on hiljainen siihen asti. Peer, joka määritettiin eikä koskaan ollut käytössä, näyttää tyhjän kättelyn, nolla vastaanotettua tavua ja kasvavan välin viimeisimmästä. Tila on terve joutilaalle asiakkaalle ja huolestuttava vain, jos odotit liikenteen jo virranneen. Tarkista myös siirtolaskurit, sillä ne erottavat ei-mitään-lähetetty -tilan yritetty-ja-epäonnistuttu -tilasta.

Jos laskurit ovat nollassa molemmilla puolilla, ongelma on tunnelin yläpuolella. Mikään ei saavuttanut liitäntää laukaistakseen mitään.

Laukaise liikenne, jonka peer saa kuljettaa

Valitse osoite peerin sallittujen etuliitteiden sisältä paikallisella koneella ja varmista, että reititystaulu lähettäisi sen liitännän kautta. Näiden etuliitteiden ulkopuolinen kohde tuottaa tavallisen reititetyn pyynnön ilman minkäänlaista WireGuardin osuutta. Käytä palvelua, joka vastaa nopeasti, kuten pingiä tai lyhyttä TCP-yhteyttä, jotta yrityksellä on näkyvä alku ja loppu. Lue sitten kättelyrivi uudelleen sen sijaan, että katsoisit näyttöä ja odottaisit.

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

Reittikysely on tärkeämpi kuin ping. Jos se nimeää fyysisen liitännän, paketti ei koskaan päätynyt tunneliin ja tyhjä kättely on reititysvastaus, ei salakirjoituksellinen. Korjaa reitti ennen peerin virheenjäljitystä.

Vertaa avainparia ja päätepistettä

Kun liikennettä todella tarjotaan, identiteetti on seuraava tarkistus. Paikallisen yksityisen avaimen on vastattava julkista avainta, jonka toinen puoli valtuuttaa, määritetyn etäjulkisen avaimen on tunnistettava aiottu peer ja jaetun avaimen on täsmättävä molemmissa päissä. Yhden merkin ero base64-avaimessa tuottaa peerin, joka näyttää määritetyltä eikä koskaan suorita vaihtoa. Vertaa valmistelutietueeseen sen sijaan, että loisit avaimet uudelleen, sillä uusi avain mitätöi jokaisen peerin, joka luotti vanhaan.

Päätepiste vaatii saman tarkastelun: isäntänimi, osoite, UDP-portti ja perhe, jota käytetään sen saavuttamiseen. Vanhentunut osoite tai väärä portti tuottaa hiljaisuuden viestin sijaan.

Seuraa ulompaa UDP-polkua

Kättely kulkee UDP:nä kohti päätepistettä, joten ulomman polun on kuljetettava se. Alla olevat komennot tarkistavat, onko kuuntelija olemassa, lähettikö paikallinen pino datagrammin ja mikä päätepiste on määritetty. Suorita kaappaus liikennettä laukaistessasi, ei ennen sitä.

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

Kaappaus, joka näyttää aloituksen ilman vastausta, osoittaa koneen ulkopuolelle, koska toinen pää joko ei kuuntele, on suodatettu tai on osoitettu väärin. Kaappaus, joka ei näytä mitään, tarkoittaa, ettei paketti koskaan lähtenyt, mikä palauttaa sinut reittiin ja mahdolliseen socket-merkintään. Kun hallitset molempia päitä, korreloi yritys aikaleiman perusteella kapealla kaappauksella palvelimella yleisen sijaan. TCP-portin testi ei todista tässä mitään, koska protokolla on vain UDP.

Kun kättely ilmestyy, testaa sovellusta tunnelin läpi, koska suoritettu vaihto todistaa identiteetin ja tavoitettavuuden, ei käyttökelpoista läpäisyä tai oikeaa DNS:ää. Säilytä tilatuloste ennen muutosta ja sen jälkeen, ja ero tulee todisteesi.