OpenVPN DNS na bramie: dnsmasq i zakres firewalla

Uruchom dnsmasq na adresie tunelu, zezwól na DNS tylko z puli klientów, wypchnij resolver, a następnie przetestuj zapytania bezpośrednie i wyszukiwanie samej aplikacji.

Klienci w tunelu docierają do bramy, a brama dociera do wewnętrznego resolvera, więc DNS powinien działać. Nie działa, bo to dwa różne uprawnienia, a działająca usługa DNS to trzecia rzecz. Nasłuchiwacz musi istnieć pod adresem, do którego docierają klienci, firewall musi zezwalać na zapytania do tego adresu, a klientowi trzeba powiedzieć, żeby go używał. Otwarcie tunelu w obu kierunkach przypadkiem rozwiązuje pierwsze dwie rzeczy i zostawia trzecią niedokończoną.

Nasłuchiwacz to usługa lokalna o dwóch kierunkach

Na wejściu klient wysyła zapytanie na adres tunelu bramy na porcie 53. Na wyjściu demon przekazuje to zapytanie do skonfigurowanego serwera nadrzędnego. Obie połowy muszą działać, a one zawodzą na różne sposoby.

Limit czasu zgłoszony przez klienta i limit czasu widoczny na bramie to nie ta sama usterka.

Przypisz adres tunelu, nie każdy adres

Dedykowana instancja dnsmasq do tego zadania potrzebuje jawnego adresu nasłuchu, trybu przypisania, który znosi pojawienie się tunelu po starcie, i jednego jasnego serwera nadrzędnego. To najmniejsza wersja, której używam:

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

bind-dynamic przypisuje poszczególne adresy i radzi sobie, gdy tun0 pojawi się później, co ma znaczenie na hoście, na którym usługa VPN restartuje się. Wymienienie loopback utrzymuje lokalne narzędzia w działaniu bez dodawania publicznego nasłuchiwacza. no-resolv nie pozwala demonowi odziedziczyć serwerów nadrzędnych z konfiguracji resolvera hosta, a no-hosts nie pozwala tej instancji publikować pliku hosts bramy. Żadna z tych opcji nie daje nikomu uprawnienia do odpytywania usługi.

Sprawdź, czy nie ma już istniejącego nasłuchiwacza na porcie 53 przed uruchomieniem drugiego demona, i użyj właściciela konfiguracji dystrybucji zamiast zabłąkanego pliku w złym katalogu.

Zezwól na wejście DNS, nie na tranzyt tunelu

Reguły firewalla, które to umożliwiają, to lokalne reguły wejścia ograniczone do interfejsu tunelu, puli klientów, adresu bramy i portu 53. Dwie reguły, po jednej na protokół, wystarczą:

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 działa przez TCP tak samo jak przez UDP, więc reguła tylko dla UDP zostawia duże odpowiedzi zawodzące w sposób, który wygląda na przerywany. To nie są ufw route uprawnienia i nie mogą stać się szerokim zezwoleniem na tun0. Kolejność jest równie ważna jak treść: wcześniejsza reguła, która odrzuca całe wejście z tun0, nadal wygrywa, a dodanie zezwolenia poniżej końcowego odrzucenia niczego nie tworzy.

Jeśli DNS bramy jest teraz częścią projektu, przejrzyj tamtą wcześniejszą politykę świadomie i zapisz dlaczego.

Połowa nadrzędna to osobna ścieżka

Zapytania opuszczają bramę z jej własnego adresu w stronę resolvera nadrzędnego, więc trasa bramy i polityka wyjścia wobec tego resolvera muszą zezwalać na wymianę. To inna reguła niż ta, która wpuszcza klientów do nasłuchiwacza, i zawodzi z innym objawem.

Nie dodawaj nieograniczonego wyjścia tunelu, żeby odpowiedzi działały; śledzone odpowiedzi tego nie potrzebują.

Wypchnij opcję, a potem sprawdź przekazanie

Serwer może ogłosić resolver klientom za pomocą wypchniętej opcji. To opcja, nie polecenie, którego system operacyjny musi słuchać:

push "dhcp-option DNS 10.90.0.1"

Klient Linuksa z wiersza poleceń może potrzebować integracji resolvera ze swoim menedżerem połączeń, a zarządzane urządzenie może potrzebować zaktualizowanego profilu zarządzania. Po połączeniu potwierdź aktywny resolver na kliencie, zamiast zakładać, że wypchnięcie zostało zastosowane. Gdy dwa mechanizmy próbują ustawić DNS naraz, powstaje wyścig, który objawia się migoczącym rozwiązywaniem nazw.

Celem jest jeden właściciel konfiguracji resolvera klienta, a wypchnięcie jest tym właścicielem zwykle tylko wtedy, gdy platforma klienta się zgadza.

Przetestuj to, co naprawdę zbudowałeś

Odpytaj jedną prywatną w pełni kwalifikowaną nazwę i jedną dozwoloną nazwę zewnętrzną bezpośrednio pod adres tunelu, przez UDP i TCP. Następnie powtórz zwykłą ścieżką wyszukiwania aplikacji.

Jeśli bezpośrednie zapytania działają, a aplikacja nadal zawodzi, usterka jest w przekazaniu, a nie na serwerze:

  • Klient nigdy nie zastosował wypchniętej opcji.
  • Później ustawiono inny resolver i wygrał wyścig.
  • Aplikacja używa własnej biblioteki resolvera albo odpowiedzi z pamięci podręcznej.

Zakończ potwierdzeniem, że źródło spoza zatwierdzonej ścieżki VPN w ogóle nie może używać nasłuchiwacza. Udane rozwiązanie nazwy nie upoważnia zwróconego adresu, więc trzymaj te dwa pytania osobno.

Powiązane artykuły