Klienti v LAN překládají přes tunel a vlastní dotazy routeru tiše nikoli. Aktualizace balíčků, synchronizace času a dynamický DNS odcházejí běžným uplinkem, zatímco každý předávaný dotaz jde přes VPN, a nic v rozhraní nenaznačuje, že existují dvě různé cesty. Vysvětlení není chyba v politice, ale otázka který háček paket vidí. Dva toky, jedna adresa překladače a jen jeden z nich prochází routerem. Jejich oddělení je celá oprava.

Dva toky, jedna adresa překladače

První tok je ten, který si lidé představují. Klient se ptá překladače routeru, překladač předává nahoru a tento předávaný paket prochází routerem na cestě ven. Tento paket je viditelný pro vše, co sleduje předávaný provoz.

Druhý tok nikdy nepřichází odnikud. Vytváří ho router, takže neexistuje příchozí paket ani krok předávání, který by se dal porovnat.

Oba mohou mířit na stejnou adresu překladače, a právě proto je snadné rozdíl přehlédnout. Stejné místo určení, jiný původ, jiný řetěz. Jakmile uvidíte původ, zbytek diagnózy následuje.

Předávané a lokálně vytvářené pakety vstupují jinak

Předávaný provoz se vyhodnocuje, když dorazí z jiného rozhraní. Balíčky politického směrování to vystavují jako řetěz prerouting a pravidlo tam umístěné vidí každý paket procházející routerem. Proto se klientské dotazy chovají přesně tak, jak politika popisuje, a proto je router ignoruje. Pravidlo není špatné, je jen připojené k háčku, ke kterému se router nikdy nedostane. Přesuňte ho a stejná shoda začne fungovat.

Lokálně vytvářený provoz vytváří proces na routeru a vstupuje místo toho do výstupní cesty. Směruje ho vlastní rozhodnutí routeru a setká se s politikou jen tehdy, pokud politika tento řetěz pokrývá. Neexistuje žádné příchozí rozhraní k porovnání ani rozhodnutí o předávání ke sledování.

To je vlastnost místa, kde se pakety rodí, nikoli nějakého konkrétního balíčku. Pravidlo napsané pro jeden řetěz prostě nemá názor na ten druhý. Žádné ladění pravidel to nezmění.

Vyberte výstupní řetěz a potom zúžte shodu

Oprava spočívá v připojení stejného záměru i k výstupnímu řetězu, nebo v přesunutí pravidla tam, když vám jde o vlastní dotazy routeru. V instalaci OpenWrt postavené na balíčku politického směrování to znamená zvolit output místo prerouting v nastavení řetězu pravidla. Ponechte obě pravidla, pokud obě populace potřebují pokrytí.

Potom zúžte, čemu pravidlo odpovídá. Cílové adresy překladače na portu, který překladač skutečně používá, jsou mnohem menší rozhodnutí než posílat vše, co router vytváří, do tunelu.

Držte obě pravidla explicitní, místo abyste se snažili napsat jedno, které pokryje oba řetězy. Oddělená pravidla se čtou snadněji a umožňují vám vypnout cestu routeru, aniž byste při ladění rušili klientský provoz. Také dělají počítadla smysluplnými jedno po druhém.

Držte vlastní transport tunelu mimo pravidlo

Vnější spojení tunelu také vytváří router. Pravidlo, které posílá veškerý lokálně vytvářený provoz do tunelu, povede tunel skrze sebe a ten vůbec nevstane.

Druhou obětí je přístup pro správu. Administrativní relace vzniklé na routeru nebo odpovědi na ně může příliš široké místní pravidlo vtáhnout do tunelu a stanou se z LAN nedostupnými.

Vylučte koncový bod tunelu ze shody a držte pravidlo omezené na adresy překladače. To pro požadavek DNS stačí a je dost malé na to, aby se o něm dalo uvažovat.

Testujte obě populace, ne jednu

Sledujte, jak router vytváří vlastní dotaz, a poznamenejte, které rozhraní ho neslo. Zopakujte dotaz z hostitele v LAN a poznamenejte cestu, kterou se vydal. Počítadla na pravidlech politiky ukážou obě odpovědi bez hádání.

Berte výsledky jako dvě zjištění. Klient, který překládá přes tunel, nic neříká o routeru, a router, který překládá správně, nic neříká o klientu na jiném posluchači. Zapište je jako samostatné řádky do záznamu změny.

Zkontrolujte i port: pravidlo odpovídající cílovému portu 53 mine překladač dosažený přes DNS over TLS na 853 nebo přes koncový bod HTTPS. Porovnejte transport, který nakonfigurovaný upstream skutečně používá, a únik se uzavře ze správného důvodu.

Související články