Peer WireGuardu vychází přes špatný WAN: pět kontrol v pořadí

Na bráně s více uplinky mohou handshake a předávaný tok jít různými cestami. Projděte pravidlo, značku, překlad a odpověď přesně v tomto pořadí.

Dva uplinky, jedna brána a peer WireGuardu, jehož provoz se stále objevuje na záložní lince. Handshake zůstává celou dobu v pořádku. Proto je snadné symptom mylně číst jako závadu WireGuardu, a ne jako problém směrování.

Proveďte níže uvedené kontroly v pořadí. Každá má podmínku zastavení a přeskočení dopředu obvykle dává sebevědomou špatnou odpověď.

Oddělte handshake od předávaného toku

Šifrovaná výměna s peerem má trasu k veřejné adrese serveru. Předávaný klientský provoz má jiné cíle a může být vybrán značkami nebo pravidly zásad. Jsou to dvě rozhodnutí směrování, která sdílejí jedno rozhraní. Považovat jedno za důkaz o druhém je první chyba.

Zastavte se, jakmile se přistihnete, že usuzujete z handshake. Je to důkaz jen o cestě ke koncovému bodu.

Čtěte pravidlo zásad, ne výchozí tabulku

Výchozí tabulka ukazuje, co se stane, když neodpovídá žádné pravidlo zásad. Na bráně, která směruje podle zdroje, značky nebo cíle, žije rozhodující pravidlo jinde. Obyčejná tabulka může vypadat naprosto rozumně, zatímco skutečná volba se dělá nad ní.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Přečtěte pravidla zásad a tabulky, na které odkazují. Pak ověřte, které pravidlo odpovídá vašemu testovacímu toku. Pravidlo, které odkazuje na rozhraní, jež už nese zamýšlený uplink, je zjištění, ne detail. Vyhledání trasy na konci ukáže odpověď mnohem rychleji než čtení tabulky a hádání.

Zkontrolujte značku a překlad společně

Směrování podle zásad se opírá o značku paketu nastavenou dříve v řetězci. Pokud pravidlo značení váš provoz mine, tok propadne do hlavní tabulky a odejde přes to, co je tam výchozí. Předávané pakety často přeskakují řetězce napsané pro lokálně generovaný provoz.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

Překlad musí souhlasit s uplinkem, který tok nese. Pravidlo, které překládá na primární adresu, zatímco paket odchází záložní linkou, vytváří odpovědi adresované rozhraní, které tok nikdy nepoužil. Zkontrolujte vlastní podmínku rozhraní daného pravidla překladu. Bezpodmínečné pravidlo funguje, dokud se nepoužije druhý uplink, a pak selže způsobem, který vypadá přerušovaně.

Sledujte, které rozhraní nese odpověď

Zachyťte provoz na obou uplincích, zatímco běží jeden požadavek. Poznamenejte, které rozhraní nese požadavek a které odpověď. Asymetrické cesty je mnohem snazší vidět než předpovídat.

Pokud odpověď dorazí špatným uplinkem, problém se přesunul z WireGuardu na sledování spojení nebo překlad. Žádná změna konfigurace peeru to nespraví.

Změňte jednu věc s cestou zpět

Před úpravou pravidel zásad na bráně si ponechte konzolový nebo mimopásmový přístup. Udělejte jednu změnu, otestujte stejný povolený cíl, poté se znovu připojte a ověřte, že handshake stále používá zamýšlenou cestu ke koncovému bodu. Přidejte číselný test pro druhou rodinu adres, protože zásada jen pro v4 nechává stejnou chybu dostupnou.

Zaznamenejte, který uplink každý tok použil. Tento záznam promění příští hlášení v dvouminutovou kontrolu místo celého odpoledne. poznámky WireGuardu o jmenných prostorech a směrování popisují, jak záměrně oddělit cestu ke koncovému bodu od tunelovaného provozu, což je obvykle čistší než kopírovat obchvat s výchozí trasou.

Související články