Proč dotazy dnsmasq unikají z VPN po přesměrování DNS

Klient v LAN se ke své VPN dostane správně, a přesto se jeho dotazy DNS objevují na špatném vzestupném spoji. To není únik v obvyklém smyslu; je to to, co se stane, když router přestane dotaz předávat a odpoví na něj sám. Zachycení přepíše cíl na lokální socket a resolver pak otevře druhou, nesouvisející konverzaci s vlastní zdrojovou adresou a vlastním rozhodnutím o směrování. Značky použité na tok klienta popisují první konverzaci a o druhé neříkají vůbec nic.

Značka necestuje spolu s dotazem

Značky paketů žijí v záznamu conntrack a v paketu na cestě. Pravidlo REDIRECT ten let ukončí: datová část se předá lokálnímu socketu a původní záznam už svou práci udělal. To, co potom opustí router, je čerstvý socket vytvořený procesem resolveru se zdrojovou adresou samotného routeru.

Proto se politická trasa vázaná na adresu klienta v LAN nikdy neshoduje se vzestupným dotazem. Nový socket patří dnsmasq, nikoli klientovi, a jádro trasu vyhodnocuje pro provoz samotného routeru. Pravidla zdroje, pravidla rozhraní i pravidla značek vidí jinou n-tici. Předpoklad, že se značka přenáší, je v tomto uspořádání nejčastější chybou a v zachycení na straně klienta není vidět.

Obě konverzace skutečně sdílejí jméno i časování, a právě proto vypadají jako jeden tok, když zachycením jen prolétnete.

Kde se předávání mění v lokální překlad

Začněte tím, že zjistíte, zda je port 53 přesměrován, přeložen na jiný hostitel, nebo ponechán být, protože všechny tři případy se chovají jinak. Přesměrování na lokální port předávání ukončí, zatímco překlad na jiný stroj drží paket v pohybu a udržuje n-tici klienta smysluplnou.

Podívejte se na oba protokoly. Resolver dostupný přes UDP i TCP bude testován přes oba a sada pravidel pokrývající jen UDP nechává tichou díru pro velké odpovědi. Pravidla generovaná vlastním správcem konfigurace routeru se také počítají a úprava generovaného souboru obvykle prohraje s dalším načtením.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Tyto výstupy odpovídají na tři otázky v pořadí: co dotaz přepisuje, co jej přijímá a který proces vlastní naslouchající socket. Jakmile je vlastník znám, má politika vůči upstreamu kde žít.

Dejte resolveru vlastní výstupní politiku

Upstream specifický pro doménu je nejčistší nástroj, když tunel potřebují jen některá jména. dnsmasq přijímá řádek server omezený na doménu, s volitelným rozhraním nebo zdrojovou adresou, která vede dotaz zvoleným zařízením. Právě toto vedení způsobuje, že druhá konverzace následuje VPN.

server=/corp.example/10.30.0.53@tun_work
log-queries

Doména, adresa a rozhraní výše jsou zástupné hodnoty pro vaše vlastní. Volba domény a řízení výstupu zůstávají oddělenými rozhodnutími: trasa musí existovat, zdrojovou adresu musí povolit upstream resolver a firewall musí povolit odpověď. Samotné vedení rozhraním není fail-closed, protože zmizelý tunel může nechat resolver spadnout na jinou cestu. Držte každou veřejnou zálohu daleko od jmenného prostoru, který musí zůstat soukromý.

Vložte řádek do vlastníka konfigurace, který router podporuje, ne do generovaného souboru, jinak další načtení opravu smaže.

Co sdílená cache nedokáže zachovat

Jeden přeposílač s jednou cache obsluhuje každého klienta v LAN, a to bourá rozlišení, které některé sítě potřebují. Pokud dva klienti musí přeložit stejné jméno různě, sdílený socket nemá jak zjistit, který klient se ptal. Politika pro jednotlivé klienty musí žít v oddělených instancích resolveru nebo ve funkci předávání, která zachovává identitu.

Uložená odpověď také není důkazem o nové cestě. Odpověď může přijít z paměti, zatímco vzestupná trasa zůstává rozbitá.

Pravidla pro port 53 neříkají nic o aplikacích, které mluví DNS přes HTTPS nebo přes TLS. Tyto dotazy se k přesměrování nikdy nedostanou, takže politika postavená jen na portu 53 popisuje podmnožinu provozu a měla by být dokumentována jako podmnožina.

Ověřte druhou konverzaci, ne první

Testujte s jedním jménem, které ovládáte, a sledujte obě strany. Zachycení na straně klienta dokazuje, že dotaz opustil LAN; jen strana routeru dokazuje, kam šel dál.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Před každým pokusem vyprázdněte cache, protože teplá odpověď skrývá rozbitý upstream. Zopakujte přes TCP, pak zopakujte s vypnutým tunelem, abyste viděli, co resolver dělá, když jeho preferovaná cesta zmizí. Právě toto poslední chování rozhoduje, zda je návrh fail-closed, nebo jen šťastný.