WireGuard saadab andmeid, kuid ei saa midagi tagasi: milline pool?

Saatmisloendurid, mis kasvavad, samal ajal kui vastuvõtuloendur jääb nulli, kirjeldavad suunda, mitte diagnoosi. Sama näit ilmub siis, kui partner ei lõpetanud kunagi kätlust, kui sihtkoht valis vale partneri, kui kaugemal poolel pole tagasiteed ja kui filter pillab vastuse teel koju. Igaüht neist parandatakse erinevas kohas.

Tööd lühendav võrdlus on kunagi tunnelist lahkunud päringu ja kunagi tagasi tulnud vastuse vahel. Üks salvestus õigel liidesel otsustab nende vahel.

Loendurid kirjeldavad mahtu, mitte rikke suunda

WireGuardi loendurid registreerivad, mida liides partnerile edastas ja mida temalt vastu võttis. Need ei ütle, milline sihtkoht, milline partner või milline vahetuse pool ebaõnnestus. Taustaliiklus muudab summad veelgi vähem informatiivseks, sest osa baite võivad olla ühenduse hoidmise signaalid või mitteseotud vood. Lugege neid märgina, et liides on aktiivne, ja lõpetage seejärel nende käsitlemine tõendina.

Kasulik esimene fakt on, kas kätlus on värske. Ilma selleta ei krüpteeritud selle partneri jaoks midagi ja vastuvõtuloenduril pole põhjust liikuda.

Partneri valik või vastuse tee: kaks seletust

Esimene seletus on, et pakett ei jõudnud kunagi kavatsetud partnerini, sest marsruut osutas mujale või partneri lubatud eesliited ei katnud sihtkohta. Teine on, et pakett jõudis kohale ja vastus ei saanud tagasi tulla, mis on marsruutimisprobleem kaugemas otsas. Tabel eraldab need selle järgi, mida te igas punktis jälgiksite.

Lugege tabelit ülalt. Puuduv kätlus suunab teid võtmete, lõpp-punktide ja välise tee juurde, sest muud pole veel uurida. Värske kätlus, mille puhul päring on serveril nähtav, viib probleemi tagasisuunda, kus otsustab sihtkoha enda marsruutimistabel. Päring, mis ei ilmu serveril kunagi, on valikuprobleem, ja mõlema partneri lubatud eesliited on esimene asi, mida võrrelda.

Neist neljast reast kaks parandatakse kliendis ja kaks serveris. Teadmine, millises paaris te olete, on suurem osa tööst.

Kus vastused kaovad

Vastus lahkub sihtkohast, jõuab serveri tunneliliidesele ja krüpteeritakse partneri jaoks, mille lubatud aadressid ühtivad kliendi sisemise aadressiga. Kui see vaste ebaõnnestub, visatakse vastus vaikselt ära, mis kliendi poolelt näeb täpselt välja nagu võrguühenduse rike. Kui vastus on krüpteeritud ja kliendi enda filter lükkab selle tagasi, on sümptom jälle identne. Mõlemal juhul on vaja salvestust, mitte loendurit.

Selle vea tugevaim vorm on server, mis edastab kliendile pakette, kuid millel pole tagasiteed kliendi sisemisse vahemikku. See võtab päringu vastu, saadab vastuse oma vaikelüüsile ja tunnel ei näe seda kunagi. Serverile lisatud lai tõlkereegel varjab selle rikke, selle asemel et marsruut parandada.

Testige ühte sihtkohta otsast lõpuni

Valige partneri vahemikus üks sihtkoht ja testige seda, kui kätlus on tõestatult värske. Allolevad käsud loevad partneri olekut, valitud marsruuti ja vahetuse mõlemat poolt. Käivitage salvestus liidesel, mida krüpteeritud paketid tegelikult kasutavad.

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

Salvestus, mis näitab päringut tunneliliidesel ilma millegi tagasitulekuta, on serveripoole vastus, ja sihtkoha marsruutimistabel on järgmine koht, kuhu vaadata. Kui ei ilmu üldse midagi, võttis pakett teise tee, seega on kahtlane kohalik marsruut. Mõlemas salvestuses nähtav vahetus ilma rakenduse edenemiseta viib küsimuse paketi suuruse või filtri juurde, mida liidese statistika kunagi ei näita. Hoidke testis üks sihtkoht ja üks klient, sest teine muutuja muudab tõendi taas muljeks.

Kui nimed ebaõnnestuvad, samal ajal kui lubatud aadress töötab, on vastus DNS-is, mitte tunnelis. Kui takerduvad ainult suured ülekanded, uurige paketi suurust eraldi.