WireGuard pošilja podatke, a ne prejme ničesar nazaj: katera stran?

Števci pošiljanja, ki naraščajo, medtem ko števec prejemanja ostane na ničli, opisujejo smer, ne diagnoze. Enak odčitek se pojavi, ko partner nikoli ni dokončal rokovanja, ko je cilj izbral napačnega partnerja, ko oddaljena stran nima poti nazaj in ko filter zavrže odgovor na poti domov. Vsak od teh se popravi na drugem mestu.

Primerjava, ki skrajša delo, je med zahtevo, ki nikoli ni zapustila tunela, in odgovorom, ki se nikoli ni vrnil. En posnetek na pravi vmesnik odloči med njima.

Števci opisujejo količino, ne smeri okvare

Števci WireGuarda beležijo, kaj je vmesnik izročil partnerju in kaj je od njega prejel. Ne povedo, kateri cilj, kateri partner ali katera polovica izmenjave je spodletela. Promet v ozadju naredi vsote še manj povedne, saj so nekateri bajti lahko sporočila za vzdrževanje povezave ali nepovezani tokovi. Berite jih kot pokazatelj, da je vmesnik aktiven, nato pa jih prenehajte obravnavati kot dokaz.

Prvo koristno dejstvo je, ali je rokovanje aktualno. Brez njega za tega partnerja ni bilo nič šifrirano in števec prejemanja se nima razloga premakniti.

Izbira partnerja ali pot odgovora: dve razlagi

Prva razlaga je, da paket nikoli ni dosegel predvidenega partnerja, ker je pot kazala drugam ali dovoljene predpone partnerja niso pokrivale cilja. Druga je, da je paket prispel in odgovor se ni mogel vrniti, kar je problem usmerjanja na oddaljenem koncu. Tabela jih loči po tem, kaj bi opazili na vsaki točki.

Berite tabelo od zgoraj. Manjkajoče rokovanje vas pošlje h ključem, končnim točkam in zunanji poti, ker za pregled še ni ničesar drugega. Aktualno rokovanje z zahtevo, vidno na strežniku, premakne težavo v smer vrnitve, kjer odloča lastna usmerjevalna tabela cilja. Zahteva, ki se na strežniku nikoli ne pojavi, je problem izbire, dovoljene predpone na obeh partnerjih pa so prva stvar, ki jo je treba primerjati.

Dve od teh štirih vrstic se popravita na odjemalcu in dve na strežniku. Vedeti, v katerem paru ste, je večina dela.

Kje odgovori izginejo

Odgovor zapusti cilj, doseže tunelski vmesnik strežnika in se šifrira za partnerja, katerega dovoljeni naslovi se ujemajo z notranjim naslovom odjemalca. Če se to ujemanje ne izide, se odgovor tiho zavrže, kar z odjemalčeve strani izgleda natanko kot omrežna okvara. Če je odgovor šifriran in ga lastni filter odjemalca zavrne, je simptom spet enak. Oba primera potrebujeta posnetek, ne števca.

Najmočnejša oblika te napake je strežnik, ki posreduje pakete za odjemalca, a nima poti nazaj v notranji obseg odjemalca. Zahtevo sprejme, odgovor pošlje proti svojemu privzetemu prehodu in tunel ga nikoli ne vidi. Široko pravilo prevajanja, dodano na strežniku, to okvaro skrije, namesto da bi popravilo pot.

Preizkusite en cilj od začetka do konca

Izberite en sam cilj znotraj obsega partnerja in ga preizkusite, medtem ko je rokovanje dokazljivo aktualno. Spodnji ukazi berejo stanje partnerja, izbrano pot in obe strani izmenjave. Zaženite posnetek na vmesniku, ki ga šifrirani paketi dejansko uporabljajo.

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

Posnetek, ki prikazuje zahtevo na tunelskem vmesniku brez česar koli v odgovor, je odgovor s strani strežnika in usmerjevalna tabela cilja je naslednje mesto za pogled. Če se ne pojavi prav nič, je paket šel po drugi poti, zato je sumljiva lokalna pot. Izmenjava, vidna v obeh posnetkih brez napredka v aplikaciji, premakne vprašanje na velikost paketa ali na filter, ki ga statistika vmesnika nikoli ne pokaže. V preizkusu obdržite en cilj in enega odjemalca, ker druga spremenljivka dokaz spet spremeni v vtis.

Če imena spodletijo, medtem kot dovoljeni naslov deluje, je odgovor v DNS in ne v tunelu. Če se ustavljajo le veliki prenosi, preglejte velikost paketa ločeno.