OpenVPN DNS na bráně: dnsmasq a rozsah firewallu

Spusťte dnsmasq na adrese tunelu, povolte DNS jen z fondu klientů, protlačte resolver a potom otestujte přímé dotazy i vlastní vyhledávání aplikace.

Klienti v tunelu dosáhnou na bránu a brána dosáhne na interní resolver, takže DNS by měl fungovat. Nefunguje, protože to jsou dvě různá oprávnění a funkční služba DNS je třetí věc. Posluchač musí existovat na adrese, na kterou klienti dosáhnou, firewall musí povolit dotazy na tuto adresu a klientovi se musí říct, aby ji používal. Otevření tunelu oběma směry vyřeší první dvě náhodou a třetí nechá nedokončené.

Posluchač je lokální služba se dvěma směry

Směrem dovnitř klient posílá dotaz na adresu tunelu brány na portu 53. Směrem ven démon předává tento dotaz svému nakonfigurovanému nadřazenému serveru. Obě poloviny musí fungovat a selhávají různým způsobem.

Časový limit hlášený klientem a časový limit viděný na bráně nejsou stejná závada.

Připoutejte adresu tunelu, ne každou adresu

Vyhrazená instance dnsmasq pro tuto práci potřebuje explicitní adresu pro naslouchání, režim připoutání, který snese objevení tunelu po startu, a jeden jasný nadřazený server. Toto je nejmenší verze, kterou používám:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic připoutá jednotlivé adresy a zvládá, když se tun0 objeví později, což je důležité na hostiteli, kde se služba VPN restartuje. Uvedení loopbacku udrží místní nástroje v chodu, aniž by přidalo veřejného posluchače. no-resolv zabrání démonovi zdědit nadřazené servery z konfigurace resolveru hostitele a no-hosts zabrání této instanci publikovat soubor hosts brány. Žádná z těchto voleb nedává nikomu oprávnění dotazovat se služby.

Zkontrolujte, zda už neexistuje existující posluchač na portu 53 než spustíte druhého démona, a použijte vlastníka konfigurace distribuce místo zatoulaného souboru ve špatném adresáři.

Povolte vstup DNS, ne tranzit tunelu

Pravidla firewallu, která to umožňují, jsou pravidla lokálního vstupu omezená na rozhraní tunelu, fond klientů, adresu brány a port 53. Dvě pravidla, jedno na protokol, stačí:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS běží přes TCP i UDP, takže pravidlo jen pro UDP nechává velké odpovědi selhávat způsobem, který vypadá občasně. Tohle nejsou ufw route oprávnění a nesmí se stát širokým povolením na tun0. Pořadí je stejně důležité jako obsah: dřívější pravidlo, které zahodí veškerý vstup z tun0 stále vyhrává, a přidání povolení pod koncové zahození nic nevytvoří.

Pokud je DNS brány teď součástí návrhu, záměrně tu dřívější politiku upravte a poznamenejte proč.

Nadřazená polovina je samostatná cesta

Dotazy opouštějí bránu z její vlastní adresy směrem k nadřazenému resolveru, takže směrování brány a výstupní politika vůči tomuto resolveru musí výměnu povolit. To je jiné pravidlo než to, které pouští klienty k posluchači, a selhává s jiným příznakem.

Nepřidávejte neomezený výstup tunelu, aby odpovědi fungovaly; sledované odpovědi to nepotřebují.

Protlačte volbu a pak zkontrolujte předání

Server může klientům ohlásit resolver protlačenou volbou. To je volba, ne příkaz, který musí operační systém poslechnout:

push "dhcp-option DNS 10.90.0.1"

Klient Linuxu z příkazové řádky může potřebovat integraci resolveru ve svém správci připojení a spravované zařízení může potřebovat aktualizovaný profil správy. Po připojení ověřte aktivní resolver na klientovi, místo abyste předpokládali, že protlačení bylo použito. Když se dva mechanismy snaží nastavit DNS současně, vznikne závod, který vypadá jako kmitající překlad.

Cílem je jeden vlastník konfigurace resolveru klienta a protlačení je tím vlastníkem obvykle jen tehdy, když platforma klienta souhlasí.

Otestujte, co jste skutečně postavili

Dotazujte se na jedno soukromé plně kvalifikované jméno a jedno povolené externí jméno přímo proti adrese tunelu, přes UDP i TCP. Potom to zopakujte běžnou cestou vyhledávání aplikace.

Pokud přímé dotazy fungují a aplikace stále selhává, závada je v předání, ne na serveru:

  • Klient nikdy nepoužil protlačenou volbu.
  • Později byl nastaven jiný resolver a vyhrál závod.
  • Aplikace používá vlastní knihovnu resolveru nebo uloženou odpověď.

Skončete ověřením, že zdroj mimo schválenou cestu VPN nemůže posluchače vůbec použít. Úspěšný překlad neopravňuje adresu, kterou vrátil, takže ty dvě otázky držte oddělené.

Související články