OpenVPN DNS na bráne: dnsmasq a rozsah firewallu

Spustite dnsmasq na adrese tunela, povoľte DNS len z fondu klientov, pretlačte resolver a potom otestujte priame dopyty aj vlastné vyhľadávanie aplikácie.

Klienti v tuneli dosiahnu bránu a brána dosiahne interný resolver, takže DNS by mal fungovať. Nefunguje, pretože to sú dve rôzne oprávnenia a fungujúca služba DNS je tretia vec. Prijímač musí existovať na adrese, na ktorú klienti dosiahnu, firewall musí povoliť dopyty na tú adresu a klientovi sa musí povedať, aby ju používal. Otvorenie tunela oboma smermi vyrieši prvé dve náhodou a tretiu nechá nedokončenú.

Prijímač je lokálna služba s dvoma smermi

Smerom dovnútra klient posiela dopyt na adresu tunela brány na porte 53. Smerom von démon preposiela tento dopyt svojmu nakonfigurovanému nadradenému serveru. Obe polovice musia fungovať a zlyhávajú rôznym spôsobom.

Časový limit hlásený klientom a časový limit videný na bráne nie sú tá istá porucha.

Priraďte adresu tunela, nie každú adresu

Vyhradená inštancia dnsmasq pre túto prácu potrebuje explicitnú adresu počúvania, režim priradenia, ktorý znáša objavenie tunela po štarte, a jeden jasný nadradený server. Toto je najmenšia verzia, ktorú používam:

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

bind-dynamic priraďuje jednotlivé adresy a zvláda, keď sa tun0 objaví neskôr, čo je dôležité na hostiteľovi, kde sa služba VPN reštartuje. Uvedenie loopbacku udrží miestne nástroje v chode bez pridania verejného prijímača. no-resolv zabráni démonovi zdediť nadradené servery z konfigurácie resolvera hostiteľa a no-hosts zabráni tejto inštancii publikovať súbor hosts brány. Žiadna z týchto možností nikomu nedáva oprávnenie dopytovať sa služby.

Skontrolujte, či neexistuje existujúci prijímač na porte 53 pred spustením druhého démona, a použite vlastníka konfigurácie distribúcie namiesto zatúlaného súboru v nesprávnom adresári.

Povoľte vstup DNS, nie tranzit tunela

Pravidlá firewallu, ktoré to umožňujú, sú pravidlá lokálneho vstupu obmedzené na rozhranie tunela, fond klientov, adresu brány a port 53. Dve pravidlá, jedno na protokol, stačia:

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 beží cez TCP aj UDP, takže pravidlo len pre UDP necháva veľké odpovede zlyhávať spôsobom, ktorý vyzerá občasne. Toto nie sú ufw route oprávnenia a nesmú sa stať širokým povolením na tun0. Poradie je rovnako dôležité ako obsah: skoršie pravidlo, ktoré zahodí celý vstup z tun0 stále vyhráva, a pridanie povolenia pod koncové zahodenie nič nevytvorí.

Ak je DNS brány teraz súčasťou návrhu, zámerne prepracujte tú skoršiu politiku a poznamenajte prečo.

Nadradená polovica je samostatná cesta

Dopyty opúšťajú bránu z jej vlastnej adresy smerom k nadradenému resolveru, takže smerovanie brány a výstupná politika voči tomuto resolveru musia výmenu povoliť. Je to iné pravidlo ako to, ktoré púšťa klientov k prijímaču, a zlyháva s iným príznakom.

Nepridávajte neobmedzený výstup tunela, aby odpovede fungovali; sledované odpovede to nepotrebujú.

Pretlačte voľbu a potom skontrolujte odovzdanie

Server môže klientom ohlásiť resolver pretlačenou voľbou. To je voľba, nie príkaz, ktorý musí operačný systém poslúchnuť:

push "dhcp-option DNS 10.90.0.1"

Klient Linuxu z príkazového riadku môže potrebovať integráciu resolvera vo svojom správcovi pripojení a spravované zariadenie môže potrebovať aktualizovaný profil správy. Po pripojení overte aktívny resolver na klientovi, namiesto toho aby ste predpokladali, že pretlačenie bolo použité. Keď sa dva mechanizmy snažia nastaviť DNS súčasne, vznikne pretek, ktorý vyzerá ako blikajúce prekladanie mien.

Cieľom je jeden vlastník konfigurácie resolvera klienta a pretlačenie je tým vlastníkom zvyčajne len vtedy, keď platforma klienta súhlasí.

Otestujte, čo ste skutočne postavili

Dopytujte sa na jedno súkromné plne kvalifikované meno a jedno povolené externé meno priamo voči adrese tunela, cez UDP aj TCP. Potom to zopakujte bežnou cestou vyhľadávania aplikácie.

Ak priame dopyty fungujú a aplikácia stále zlyháva, porucha je v odovzdaní, nie na serveri:

  • Klient nikdy nepoužil pretlačenú voľbu.
  • Neskôr bol nastavený iný resolver a vyhral pretek.
  • Aplikácia používa vlastnú knižnicu resolvera alebo uloženú odpoveď.

Skončite potvrdením, že zdroj mimo schválenej cesty VPN nemôže prijímač vôbec použiť. Úspešné prekladanie neoprávňuje adresu, ktorú vrátilo, takže tieto dve otázky držte oddelene.

Súvisiace články