Rekurzivní směrování: když tunel zachytí vlastní pakety

Tunel se zvedne, protokol ukáže dokončený handshake a o sekundu později stejná relace zemře a znovu se připojí ve smyčce. Tento vzorec má konkrétní příčinu: trasa k serveru nyní ukazuje dovnitř tunelu, takže pakety, které tunel nesou, se posílají tunelem. Na ověřování se nic nezměnilo, proto opětovné zadání přihlašovacích údajů nic nevyřeší. Porovnejte vnější cestu před změnou trasy a po ní a rekurze se stane viditelnou.

Nejprve zkontrolujte vnější cestu

Ve hře jsou dva pakety, ne jeden. Vnitřní paket patří aplikaci a měl by být šifrovaný, zatímco vnější paket je adresován serveru a musí se k němu dostat cestou, která na tunelu nezávisí.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Po zvednutí tunelu se zeptejte jádra na trasu k adrese serveru a znovu poté, co se změní výchozí trasa. Další skok, který skončí na zařízení tunelu, je právě ta rekurze a je vidět bez jakéhokoli zachytávání paketů. Vazba na rozhraní, značky nebo síťový jmenný prostor mohou běžné hledání znekompletit, proto použijte kontext, který používá sám klient. Když odpověď vypadá správně, ale relace stále cykluje, čtěte pravidla směrovací politiky, ne jen hlavní tabulku.

Proč relace chvíli přežije

Handshake se dokončí dřív, než se nainstaluje nová trasa, takže první sekundy vypadají zdravě. Jakmile klient přidá výchozí trasu, následující vnější paket ji následuje do rozhraní, kterým tento vnější paket musí projít. Server nic nevidí, klient znovu odesílá a pokus buď vyprší, nebo relaci zabije a začne znovu.

Toto pořadí vysvětluje, proč tunel může fungovat na notebooku a selhat na routeru a proč porucha často začíná se startem provozu, a ne při připojení. Vysvětluje také smyčku: každý restart obnoví relaci dřív, než ji trasa udělá nemožnou.

Zjistěte, kdo vlastní výjimku pro koncový bod

Podporovaní klienti si svou výjimku zařizují sami: trasu k hostiteli serveru přes původní bránu, nebo značku, která drží vnější socket mimo tunel. Otázkou je, zda ji něco jiného neodstranilo nebo nepřebilo.

U IPsec založeného na trasách prohlédněte selektory zásad, které rozhodují, které pakety vstoupí do tunelu, a potvrďte, že adresa protistrany je z nich vyloučena. U WireGuard drží značka firewallu rozhraní a jeho pravidla zásad transportní pakety mimo tunel, takže ručně přidaná výchozí trasa může toto uspořádání rozbít. Druhý profil VPN nebo správcovský skript, který přepisuje výchozí trasu, bývá častým viníkem. Široká pravidla obcházení přidávaná jedno po druhém jsou obvyklým výsledkem a mění chybu směrování v tabulku, kterou nikdo nedokáže udržovat.

Po změně sítě zkontrolujte znovu

Trasa k hostiteli přes Wi-Fi bránu je správná, dokud se stroj nepřesune do jiné sítě. Pak se stejný příznak vrátí bez jakékoli změny konfigurace.

Zapište adresu koncového bodu, trasu před připojením a po něm a rozhraní, které každá z nich použila. Tyto tři skutečnosti obvykle oddělí chybu klienta od přebití a přežijí i toho, kdo je sesbíral.

Připojte se znovu v nové síti a čtení zopakujte. Pokud výjimka znovu chybí, oprava patří profilu, který ji vlastní, ne jednorázovému příkazu napsanému během výpadku.