Privátní DNS v Pritunlu nefunguje? Přidejte úzkou trasu resolveru

Privátní jména se překládají pro všechny v podnikové síti a vyprší pro všechny na VPN. Resolver odpovídá bráně, trasa k němu existuje, a dotaz přesto nikdy nedostane odpověď. Nechybí další veřejný resolver ani širší trasa: chybí zdrojová adresa, na kterou je privátní DNS server ochoten odpovědět.

Ověřte, že resolver odmítá váš klientský pool

Začněte důkazem, že selhání se týká zdroje, ne dosažitelnosti. Z připojeného klienta dotazujte privátní resolver přímo a sledujte, zda požadavek vyprší, nebo se vrátí jako odmítnutí. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 vyprší, zatímco stejný dotaz z brány uspěje, což ukazuje na přístupovou politiku na resolveru. Odpověď SERVFAIL ukazuje úplně jinam, obvykle na zónu nebo nadřazený forwarder.

Před testem si poznamenejte adresu klienta. ip -4 addr show tun0 na klientovi nebo lease zobrazený v konzoli vám řekne, který pool resolver vidí.

Potom ověřte, že cesta vůbec existuje. Trasa, která posílá adresu resolveru do tunelu, je předpoklad, ne řešení; pokud pakety nikdy nedorazí, zdrojová politika se vůbec neprojednává. Zkontrolujte to pomocí ip route get 10.40.0.53 na klientovi.

Přidejte jednu trasu k hostiteli místo překladu všeho

Pritunlova příručka pro privátní DNS popisuje úzké řešení: trasa /32 s povoleným NATem pro adresu resolveru, přičemž tato adresa je zvolena jako DNS server klientů. Trasa mění zdroj, který resolver vidí, pouze pro DNS provoz. Provoz aplikací si zachovává návrh se zachováním zdroje, který jste pro něj zvolili.

Nakonfigurujte ji přes podporovaného vlastníka tras na serveru, po zkontrolování stávajících tras kvůli překryvu. V příkladu výše je cílem 10.40.0.53/32 s povoleným NATem a klientský pool zůstává 10.90.0.0/24. Nepřekládejte celý privátní rozsah, abyste opravili jednu službu, protože každá navazující politika, která se spoléhá na skutečnou adresu klienta, začne místo ní vidět bránu. Ověřte adresu, kterou resolver skutečně dostává, sledováním jeho protokolu dotazů během testovacího vyhledání. Samotná trasa k hostiteli nic nedokazuje o překladu ani o povolení.

Resolver stále musí povolit přeložený zdroj na UDP a TCP a jeho odpovědi se musí umět vrátit. Změna zdroje nemůže vytvořit chybějící zónu nebo záznam.

Rozhodněte, zda dotaz posílá server nebo klient

Pritunl také dokumentuje uspořádání DNS proxy vázané na VPN Client DNS Mapping, kde server přeposílá nadřazené dotazy za klienty. V tomto modelu patří nadřazený zdroj vlastnímu síťovému kontextu serveru a výjimka na straně klienta je nesprávné řešení.

Než něco přidáte, určete, který model je aktivní. Tři překrývající se opravy, proxy, přepsání resolveru na klientovi a ruční skript NAT obvykle znamenají, že nikdo neustanovil: která komponenta má dotaz odesílat. Zkontrolujte také bootstrap: pouze privátní resolver nemůže být jediným způsobem, jak najít koncový bod před existencí tunelu, a trvalá úprava resolveru by neměla přežít připojení.

Testujte privátní vyhledání, ne veřejnou webovou stránku

Po použití změny a opětovném připojení zkontrolujte efektivní konfiguraci resolveru klienta a poté přeložte jméno, o kterém víte, že existuje jen v privátní zóně. dig intranet.example.net bez explicitního serveru ukazuje, co klient skutečně používá. Následujte požadavkem na adresu, kterou toto vyhledání vrátilo, protože překlad a přístup ke službě jsou samostatné kroky. Prohlížeč, který načítá veřejné stránky přes DNS-over-HTTPS, nic nedokazuje o cestě privátního resolveru operačního systému. Ani veřejný sekundární resolver není autoritou pro interní zónu.

Zaznamenejte adresu resolveru, trasu /32 a nastavení DNS klienta společně do poznámek serveru. Polovina této konfigurace obnovená samostatně reprodukuje původní selhání.

Nakonec ověřte, že tunel po úspěchu DNS stále směruje destinaci aplikace. Trasa, přístup ke službě a ověřování zůstávají nezávislé na překladu jmen a fungující vyhledání nic neříká o propustnosti. Pokud je privátní stránka pomalá, ale překládá se, resolver udělal svou práci a problém se přesunul na cestu.