OpenVPN posílá DNS, ale resolver ho možná nikdy neuvidí

Klientský log ukazuje odeslaný DNS server, tunel je připojený a interní název se přesto nerozřeší. Na samotném odeslání není nic rozbité. Volba dorazila, ale resolver operačního systému ji nikdy nepoužil, protože OpenVPN u většiny unixových klientů hodnotu předá a aplikaci nechá na platformě.

Příznak: log ukazuje DNS a názvy stále selhávají

OpenVPN dhcp-option přenáší informace o DNS a doméně a klient si zaznamená, co dostal. V některých implementacích klient tato nastavení použije interně, v jiných je vyexportuje pro integrační skript nebo síťovou službu. Řádek v logu popisuje jen první polovinu příběhu. Druhá polovina se odehrává tam, kde klient nic neřídí. Právě tam obvykle selhání sídlí.

Proto se připojený tunel a nefunkční interní název tak často vyskytují spolu. Hodnota je k dispozici, konzument chybí nebo je špatně nastavený a resolver tiše dál používá veřejný server, který používal před připojením.

Přijato neznamená použito

Klient může zalogovat odeslanou hodnotu DNS, zatímco systémový resolver patří jiné službě. Prohlížeč může mít také vlastní politiku šifrovaného DNS, která systémový resolver úplně obejde, což vytváří ten pamětihodný stav, kdy jedna aplikace interní názvy přeloží a jiná ne.

Prověřte podporovanou integraci dané implementace, místo abyste předpokládali, že každý unixový klient přepisuje stejný soubor. Právě tento předpoklad je důvod, proč lidé upravují konfiguraci resolveru, kterou nic nečte.

Najděte vlastníka resolveru podle platformy

Ve Windows může tabulka zásad překladu názvů směrovat určité přípony na určité servery a klient VPN tam může instalovat pravidla. Zkontrolujte zásadu, ne jen seznam DNS adaptéru. V Linuxu může konfiguraci vlastnit NetworkManager nebo systemd-resolved a to, který z nich ji vlastní, určuje, co opětovné připojení zachová.

Přečtěte si skutečný stav nástrojem, který opravdu odpovídá na dotazy: resolvectl query internal.example.net na hostiteli se systemd-resolved, nebo ekvivalentem platformy. Pak tento výsledek porovnejte s DNS serverem, který klientský log tvrdí, že odeslal.

Nespouštějte několik služeb, které bez koordinace přepisují nastavení resolveru. Dva vlastníci vytvářejí výsledek, který vypadá přerušovaně, a každé opětovné připojení to prý náhodně opraví nebo rozbije.

Skripty a foreign_option

OpenVPN exportuje odeslané volby do skriptů přes proměnné nazvané foreign_option_N a skript je může převést na příkazy resolveru. Toto uspořádání je podporovaná integrace, ne automatické chování, a musí se na klientovi nainstalovat a vyvolat.

Pokud se spoléháte na skript, logujte jeho spuštění a návratový stav. Skript, který běží, ale tiše selže, zanechává stejný příznak jako žádný skript a je těžší si ho všimnout, protože konfigurace vypadá kompletní. Kontrolujte výstup skriptu, ne soubor skriptu. Existující soubor není skript, který běžel.

Testujte název, ne log

Po připojení se z klienta zeptejte na hostitelský název dostupný jen interně, potom na veřejný název a pak zjistěte, který server odpověděl. Ve funkčním nastavení pocházejí obě odpovědi z různých míst a obě by měly odpovídat návrhu.

Pokud se název přeloží, ale služba selže, přejděte k směrování a přístupu aplikací, místo abyste znovu měnili DNS. Příručka OpenVPN dokumentuje dhcp-option a skriptové prostředí; použijte ji k ověření, co má váš klient používat, než upravíte další soubor resolveru.