A WireGuard nem mutat legutóbbi kézfogást: mit ellenőrizzünk először

Az üres legutóbbi kézfogás mező általában azt jelenti, hogy a felület a felállása óta nem fejezett be kézfogást, ami kevesebbet mond a konfigurációról, mint látszik. A WireGuard addig hallgat, amíg egy csomagnak el kell hagynia a felületet, így a tétlen, küldenivaló nélküli peer pontosan ezt jelenti. Állapítsa meg, történt-e tényleges ajánlat, mielőtt a kulcsokat vizsgálná.

A teszt egy engedélyezett csomag a peer által hordozandó cél felé. A statuszképernyő minden más eleme szándékot ír le, nem tevékenységet.

A tétlen felületnek nincs mit jelentenie

A WireGuard lustán kézfog: az első, alagutat igénylő csomag indítja a cserét, és a felület addig csendben marad. A beállított és soha nem használt peer üres kézfogást, nulla fogadott bájtot és az utolsó óta növekvő rést mutat. Ez az állapot tétlen kliensnél egészséges, és csak akkor aggasztó, ha már várt forgalomra számított. Ellenőrizze az átviteli számlálókat is, mert elválasztják a semmi-sem-ment-ki állapotot a megpróbált-és-meghiúsult állapottól.

Ha a számlálók mindkét oldalon nullán állnak, a probléma az alagút felett van. Semmi nem ért el a felületig, hogy bármit elindítson.

Indítson olyan forgalmat, amelyet a peer hordozhat

Válasszon egy címet a peer engedélyezett előtagjain belül a helyi gépen, és erősítse meg, hogy az útválasztási tábla a felületen keresztül küldené. Az előtagokon kívüli cél hétköznapi útválasztott kérést hoz létre minden WireGuard-részvétel nélkül. Használjon gyorsan válaszoló szolgáltatást, például pinget vagy rövid TCP-kapcsolatot, hogy a kísérletnek látható eleje és vége legyen. Utána olvassa újra a kézfogás sort, ahelyett hogy a képernyőt bámulná és várna.

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

Az útvonal-lekérdezés fontosabb a pingnél. Ha a fizikai felületet nevezi meg, a csomag soha nem lépett be az alagútba, és az üres kézfogás útválasztási válasz, nem kriptográfiai. Javítsa az útvonalat, mielőtt a peert hibakeresné.

Hasonlítsa össze a kulcspárt és a végpontot

Amikor a forgalom valóban felajánlott, a következő ellenőrzés az identitás. A helyi privát kulcsnak meg kell felelnie a túloldal által engedélyezett nyilvános kulcsnak, a beállított távoli nyilvános kulcsnak azonosítania kell a kívánt peert, és minden előre megosztott kulcsnak egyeznie kell mindkét végén. Egyetlen karakter eltérése egy base64 kulcsban olyan peert hoz létre, amely beállítottnak látszik, és soha nem fejez be cserét. Hasonlítsa össze a kiépítési nyilvántartással ahelyett, hogy újragenerálná a kulcsokat, mert az új kulcs érvényteleníti minden peert, amely a régiben bízott.

A végpont ugyanilyen vizsgálatot igényel: gazdanév, cím, UDP-port és az eléréséhez használt család. Az elavult cím vagy a rossz port csendet eredményez üzenet helyett.

Figyelje a külső UDP-útvonalat

A kézfogás UDP-ként utazik a végpont felé, ezért a külső útvonalnak hordoznia kell. Az alábbi parancsok ellenőrzik, létezik-e hallgató, elküldte-e a helyi verem az adatgramot, és melyik végpont van beállítva. A rögzítést a forgalom indítása közben futtassa, ne előtte.

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

Az a rögzítés, amely a kezdeményezést válasz nélkül mutatja, a gépen kívülre mutat, mert a túloldal vagy nem hallgat, vagy szűrt, vagy rossz a címe. Az a rögzítés, amely semmit nem mutat, azt jelenti, hogy a csomag soha nem indult el, ami visszavezet az útvonalhoz és bármely érvényes socket-jelöléshez. Ha mindkét végét Ön kezeli, a kísérletet időbélyeg alapján korrelálja egy szűk szerveroldali rögzítéssel, nem egy általánossal. A TCP-portteszt itt semmit nem bizonyít, mert a protokoll csak UDP.

Amint megjelenik egy kézfogás, teszteljen egy alkalmazást az alagúton, mert a befejezett csere identitást és elérhetőséget bizonyít, nem használható átviteli sebességet vagy helyes DNS-t. Őrizze meg a státuszkimenetet a változás előtt és után, és a különbség lesz a bizonyítéka.