WireGuard trimite date dar nu primește nimic înapoi: care parte?

Contoarele de trimitere care cresc în timp ce contorul de recepție rămâne la zero descriu o direcție, nu un diagnostic. Aceeași citire apare când partenerul nu a finalizat niciodată un handshake, când destinația a ales partenerul greșit, când partea îndepărtată nu are rută de întoarcere și când un filtru aruncă răspunsul pe drumul spre casă. Fiecare dintre acestea se repară într-un loc diferit.

Comparația care scurtează munca este între o cerere care nu a părăsit niciodată tunelul și un răspuns care nu s-a întors niciodată. O singură captură pe interfața corectă decide între ele.

Contoarele descriu volumul, nu direcția defecțiunii

Contoarele WireGuard înregistrează ce a predat interfața partenerului și ce a primit de la acesta. Ele nu spun care destinație, care partener sau care jumătate a unui schimb a eșuat. Traficul de fundal face totalurile și mai puțin informative, deoarece unii octeți pot fi mesaje de menținere sau fluxuri fără legătură. Citiți-le ca indiciu că interfața este activă, apoi încetați să le tratați drept dovadă.

Primul fapt util este dacă handshake-ul este actual. Fără el nu s-a criptat nimic pentru acest partener și contorul de recepție nu are niciun motiv să se miște.

Selectarea partenerului sau calea răspunsului: două explicații

Prima explicație este că pachetul nu a ajuns niciodată la partenerul dorit, pentru că ruta indica în altă parte sau pentru că prefixele permise ale partenerului nu acopereau destinația. A doua este că pachetul a ajuns, dar răspunsul nu a putut reveni, ceea ce este o problemă de rutare la capătul îndepărtat. Tabelul le separă după ceea ce ați observa în fiecare punct.

Citiți tabelul de sus. Un handshake lipsă vă trimite la chei, puncte finale și calea exterioară, pentru că încă nu există nimic altceva de examinat. Un handshake actual cu cererea vizibilă pe server mută problema în direcția de întoarcere, unde decide propria tabelă de rutare a destinației. O cerere care nu apare niciodată pe server este o problemă de selecție, iar prefixele permise pe ambii parteneri sunt primul lucru de comparat.

Două dintre aceste patru rânduri se repară pe client și două pe server. Să știți în ce pereche vă aflați este cea mai mare parte a muncii.

Unde dispar răspunsurile

Un răspuns părăsește destinația, ajunge la interfața de tunel a serverului și este criptat pentru partenerul ale cărui adrese permise corespund adresei interne a clientului. Dacă această potrivire eșuează, răspunsul este aruncat în tăcere, ceea ce din partea clientului arată exact ca o defecțiune de rețea. Dacă răspunsul este criptat și filtrul propriu al clientului îl respinge, simptomul este din nou identic. Ambele cazuri au nevoie de captură, nu de contor.

Cea mai puternică formă a acestei greșeli este un server care redirecționează pachete pentru client, dar nu are rută de întoarcere către intervalul intern al clientului. Acceptă cererea, trimite răspunsul spre gateway-ul său implicit, iar tunelul nu îl vede niciodată. O regulă de traducere largă adăugată pe server ascunde acea defecțiune în loc să repare ruta.

Testați o singură destinație de la un capăt la altul

Alegeți o singură destinație din intervalul partenerului și testați-o cât timp handshake-ul este în mod evident actual. Comenzile de mai jos citesc starea partenerului, ruta aleasă și ambele părți ale schimbului. Rulați captura pe interfața pe care pachetele criptate o folosesc efectiv.

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

O captură care arată cererea pe interfața de tunel fără ca nimic să se întoarcă este un răspuns din partea serverului, iar tabela de rutare a destinației este următorul loc de privit. Dacă nu apare absolut nimic, pachetul a luat altă cale, deci ruta locală este suspectă. Un schimb vizibil în ambele capturi fără progres în aplicație mută întrebarea spre dimensiunea pachetelor sau spre un filtru pe care statisticile interfeței nu îl arată niciodată. Păstrați o singură destinație și un singur client în test, pentru că o a doua variabilă transformă dovada din nou într-o impresie.

Dacă numele eșuează în timp ce o adresă permisă funcționează, răspunsul este în DNS și nu în tunel. Dacă doar transferurile mari se blochează, examinați dimensiunea pachetelor separat.