WireGuard sýnir enga nýjustu handstöðu: hvað á að athuga fyrst

Tómt reitur fyrir nýjustu handstöðu þýðir venjulega að viðmótið hefur ekki lokið handstöðu síðan það kom upp, sem segir minna um stillingarnar en virðist. WireGuard þegir þangað til pakki þarf að fara út um viðmótið, svo að aðgerðarlaus peer með ekkert til að senda skýrir frá nákvæmlega því. Komdu á hreint hvort eitthvað hafi í raun verið boðið áður en þú skoðar lyklana.

Prófið er leyfður pakki í átt að áfangastað sem peer á að bera. Allt annað á þeim stöðuskjá lýsir áformi en ekki virkni.

Aðgerðarlaust viðmót hefur ekkert að tilkynna

WireGuard framkvæmir handstöður letilega: fyrsti pakkinn sem þarf göngin kemur af stað skiptunum og viðmótið þegir þangað til. Peer sem var stillt og aldrei notað sýnir tóma handstöðu, núll móttekin bæti og vaxandi bil frá þeirri síðustu. Það ástand er heilbrigt fyrir aðgerðarlausan biðlara og áhyggjuefni aðeins ef þú bjóst við að umferð væri þegar farin að streyma. Athugaðu einnig flutningsteljarana, því þeir greina ekkert-sent frá reynt-og-mistókst.

Ef teljararnir standa á núlli beggja vegna er vandamálið ofan við göngin. Ekkert náði til viðmótsins til að kveikja á neinu.

Kveiktu á umferð sem peer má bera

Veldu vistfang innan leyfðra forskeyta peers á staðbundnu vélinni og staðfestu að leiðatöflan myndi senda það um viðmótið. Áfangastaður utan þessara forskeyta framleiðir venjulega leiðaða beiðni án nokkurrar þátttöku WireGuard. Notaðu þjónustu sem svarar fljótt, eins og ping eða stutta TCP-tengingu, svo tilraunin hafi sýnilegan upphaf og endi. Lestu síðan handstöðulínuna aftur í stað þess að horfa á skjáinn og bíða.

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

Leiðarbeiðnin skiptir meira máli en pingið. Ef hún nefnir líkamlega viðmótið kom pakkinn aldrei inn í göngin og tóma handstaðan er leiðarsvar en ekki dulmálssvar. Lagaðu leiðina áður en þú kembir peerinn.

Berðu saman lykilparið og endapunktinn

Þegar umferð er raunverulega boðin er auðkennið næsta athugun. Staðbundni einkalykillinn verður að svara til opinbera lykilsins sem hin hliðin heimilar, stillti fjarlykillinn verður að auðkenna fyrirhugaða peer og allur fyrirfram deildur lykill verður að passa á báðum endum. Eins stafs munur í base64-lykli framleiðir peer sem virðist stilltur og lýkur aldrei skiptum. Berðu saman við útvegunarskrá í stað þess að endurnýja lykla, því nýr lykill gerir hvern peer sem treysti þeim gamla ógildan.

Endapunkturinn krefst sömu skoðunar: hýsilnafn, vistfang, UDP-gátt og fjölskyldan sem notuð er til að ná til hans. Úrelt vistfang eða röng gátt veldur þögn í stað skilaboða.

Fylgstu með ytri UDP-slóðinni

Handstaðan ferðast sem UDP í átt að endapunktinum, svo ytri slóðin verður að bera hana. Skipanirnar hér að neðan athuga hvort hlustandi sé til staðar, hvort staðbundni stakkurinn sendi gagnagramið og hvaða endapunktur er stilltur. Keyrðu upptökuna meðan þú kveikir á umferð, ekki fyrir hana.

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

Upptaka sem sýnir upphafið án svars bendir út fyrir vélina, því fjarlægi endinn hlustar annaðhvort ekki, er síaður eða rangt vistfang. Upptaka sem sýnir ekkert þýðir að pakkinn fór aldrei út, sem færir þig aftur að leiðinni og að hvaða socket-merkingu sem er í gangi. Þegar þú stýrir báðum endum skaltu tengja tilraunina við tímaákvörðun með þröngri upptöku á þjóninum í stað almennrar. TCP-gáttarpróf sannar ekkert hér, því siðvenjan er eingöngu UDP.

Um leið og handstaða birtist, prófaðu forrit í gegnum göngin, því lokið skipti sanna auðkenni og aðgengi, ekki nothæfan afköst né rétt DNS. Geymdu stöðuúttakið fyrir og eftir breytinguna, og munurinn verður sönnun þín.