WireGuard odesílá data, ale nic nedostává zpět: která strana?

Počítadla odesílání, která rostou, zatímco počítadlo příjmu zůstává na nule, popisují směr, nikoli diagnózu. Stejný údaj se objeví, když protějšek nikdy nedokončil handshake, když cílový bod zvolil špatný protějšek, když vzdálená strana nemá cestu zpět a když filtr zahodí odpověď na cestě domů. Každý z těchto případů se opravuje na jiném místě.

Srovnání, které práci zkracuje, je mezi požadavkem, který nikdy neopustil tunel, a odpovědí, která se nikdy nevrátila. Jeden záznam na správném rozhraní rozhodne mezi nimi.

Počítadla popisují objem, ne směr závady

Počítadla WireGuardu zaznamenávají, co rozhraní předalo protějšku a co od něj přijalo. Neříkají, který cíl, který protějšek nebo která polovina výměny selhala. Provoz na pozadí dělá součty ještě méně výmluvnými, protože některé bajty mohou být zprávy pro udržení spojení nebo nesouvisející toky. Čtěte je jako ukazatel, že rozhraní je aktivní, a pak je přestaňte brát jako důkaz.

Užitečný první údaj je, zda je handshake aktuální. Bez něj nebylo pro tento protějšek nic zašifrováno a počítadlo příjmu nemá důvod se hýbat.

Volba protějšku nebo cesta odpovědi: dvě vysvětlení

První vysvětlení je, že paket nikdy nedorazil k zamýšlenému protějšku, protože trasa ukazovala jinam nebo povolené prefixy protějšku nepokrývaly cíl. Druhé je, že paket dorazil a odpověď se nemohla vrátit, což je problém směrování na vzdáleném konci. Tabulka je odděluje podle toho, co byste v každém bodě pozorovali.

Čtěte tabulku shora. Chybějící handshake vás pošle ke klíčům, koncovým bodům a vnější cestě, protože zatím neexistuje nic jiného ke zkoumání. Aktuální handshake s požadavkem viditelným na serveru přesouvá problém do směru návratu, kde rozhoduje vlastní směrovací tabulka cíle. Požadavek, který se na serveru nikdy neobjeví, je problém volby a povolené prefixy na obou protějšcích jsou první věc, kterou je třeba srovnat.

Dva z těchto čtyř řádků se opravují na klientovi a dva na serveru. Vědět, ve které dvojici jste, je většina práce.

Kde odpovědi mizí

Odpověď opustí cíl, dorazí na tunelové rozhraní serveru a zašifruje se pro protějšek, jehož povolené adresy odpovídají vnitřní adrese klienta. Pokud toto srovnání selže, odpověď se tiše zahodí, což z pohledu klienta vypadá přesně jako síťová závada. Pokud je odpověď zašifrovaná a vlastní filtr klienta ji odmítne, příznak je opět stejný. Oba případy potřebují záznam, ne počítadlo.

Nejsilnější podoba této chyby je server, který přeposílá pakety za klienta, ale nemá cestu zpět do vnitřního rozsahu klienta. Přijme požadavek, pošle odpověď ke své výchozí bráně a tunel ji nikdy nevidí. Široké pravidlo překladu přidané na server tuto závadu skrývá, místo aby opravilo trasu.

Otestujte jeden cíl od začátku do konce

Vyberte jediný cíl uvnitř rozsahu protějšku a otestujte ho, dokud je handshake prokazatelně aktuální. Níže uvedené příkazy čtou stav protějšku, zvolenou trasu a obě strany výměny. Spusťte záznam na rozhraní, které šifrované pakety skutečně používají.

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

Záznam, který ukazuje požadavek na tunelovém rozhraní a nic se nevrací, je odpověď ze strany serveru a směrovací tabulka cíle je místo, kam se podívat dál. Pokud se neobjeví vůbec nic, paket šel jinou cestou, takže podezřelá je místní trasa. Výměna viditelná v obou záznamech bez pokroku v aplikaci přesouvá otázku k velikosti paketu nebo k filtru, který statistiky rozhraní nikdy neukážou. V testu udržujte jeden cíl a jednoho klienta, protože druhá proměnná mění důkaz zpět na dojem.

Pokud názvy selhávají, zatímco povolená adresa funguje, odpověď je v DNS, ne v tunelu. Pokud se zasekávají jen velké přenosy, prozkoumejte velikost paketu samostatně.