Vaše VPN doména v dnsmasqu není přenos zóny

Hledáte firemní zónu v konfiguraci dnsmasq klienta, nenajdete ji a usoudíte, že VPN svou doménu neposlala. To, co bylo odesláno, je náznak směrování, ne zóna. Klient zaznamená doménu a resolver, který za ni má odpovídat, a spravovaný backend z toho udělá podmíněné předávání. Hledání na špatném místě dává sebejistou a zcela falešnou diagnózu.

To, co klient přijal, není to, co brána nabídla

Brána může nabídnout resolver, doménu a trasu potřebnou k dosažení tohoto resolveru, a klient může přijmout všechny tři nebo žádný z nich. Importovaný profil, pomocný skript nebo zásada, která ignoruje odeslané volby, mohou nechat přijatou množinu prázdnou, zatímco strana serveru vypadá správně. Začněte u zaznamenaného stavu klienta, nikoli u konfigurace serveru, protože tento stav je to, co resolver skutečně dostává. Pokud přijatá doména chybí, nic dalšího už nebude záležet. Než prozkoumáte jakoukoli mezipaměť, zkontrolujte vlastnosti DNS připojení.

Tento rozdíl vysvětluje většinu hlášení o doméně, která nikdy nedorazila. Byla nabídnuta a nebyla použita.

Dva druhy položek domény

Připojení může nést běžné vyhledávací domény a domény pouze pro směrování, přičemž druhý druh začíná vlnovkou. Vyhledávací doména směruje dotazy a umožňuje rozbalování krátkých jmen, což je pohodlné na pracovní stanici a překvapivé na serveru. Doména pouze pro směrování říká, že dotazy na tuto příponu mají jít na určité servery, aniž by se měnilo, jak se krátká jména překládají. Psát stejnou doménu oběma způsoby není nadbytečné, protože obě položky dělají různé věci.

Pro soukromý jmenný prostor je obvykle žádoucí forma pouze pro směrování. Udržuje firemní příponu nasměrovanou na firemní resolver a všechno ostatní nechává být.

localhost v resolv.conf není chyba

Když se používá místní kešující resolver, systémový soubor ukazuje na adresu loopback a nic jiného. Tato položka označuje místního naslouchajícího, nikoli upstream servery, které mu správce předal. Firemní adresa bude v souboru oprávněně chybět.

Nahradit tuto položku veřejným resolverem je klasická chybná oprava. Obnoví veřejné překládání jmen a ve stejné úpravě zahodí podmíněnou zásadu.

Nezaměňujte backendy

Spravovaná instance dnsmasq a systémový resolver jsou různé programy s různou konfigurací a různými pohledy na stav. Stavový příkaz pro jeden neříká nic užitečného o druhém.

Zjistěte, který backend má správce používat, a potom čtěte vygenerovanou konfiguraci tohoto backendu, nikoli distribuční soubor, který náhodou existuje. Správce zapisuje vlastní konfiguraci instance a podporuje vlastní volby pro tuto instanci, takže úprava nesouvisejícího globálního souboru nic nezmění a vypadá jako změna bez účinku. Spuštění druhého daemona na portu 53 je horší než zbytečné, protože nyní se dva programy neshodnou, komu port patří. Nejprve určete vlastníka, potom upravujte tam, kde tento vlastník čte.

Testujte jmenný prostor, nejen odpověď

Dotazujte se na jedno povolené soukromé jméno a jedno veřejné kontrolní jméno běžnou cestou aplikace. Přímý dotaz na firemní server dokazuje, že záznam existuje; nedokazuje, že klient tento server vybral. Druhý dotaz je ten, který testuje zásadu.

Poté to zopakujte po opětovném připojení a po odpojení. Přidružení by mělo sledovat životní cyklus připojení a soukromá jména by se měla přestat překládat, když tunel zmizí, místo aby se vrátila k veřejnému resolveru, který odpovídá za stejnou příponu. Pokud se přesto vrátí, našli jste únik, což je jiná závada než rozbité vyhledávání. Zapište, který backend běžel, které domény byly použity a co každý dotaz vrátil.