Dlaczego zapytania dnsmasq wychodzą poza VPN po przekierowaniu DNS

Klient sieci LAN poprawnie dociera do swojego VPN-a, a mimo to jego zapytania DNS pojawiają się na złym łączu wyjściowym. To nie jest wyciek w zwykłym sensie; to dzieje się, gdy router przestaje przekazywać zapytanie i sam na nie odpowiada. Przechwycenie przepisuje cel na lokalne gniazdo, a następnie resolver otwiera drugą, niezwiązaną rozmowę z własnym adresem źródłowym i własną decyzją routingu. Znaczniki nałożone na przepływ klienta opisują pierwszą rozmowę i kompletnie nic o drugiej.

Znacznik nie podróżuje razem z zapytaniem

Znaczniki pakietów żyją na wpisie conntrack i na pakiecie w locie. Reguła REDIRECT kończy ten lot: ładunek trafia do lokalnego gniazda, a pierwotny wpis wykonał swoje zadanie. To, co potem opuszcza router, to świeże gniazdo utworzone przez proces resolvera, ze źródłem w postaci adresu samego routera.

Dlatego trasa polityki oparta na adresie klienta sieci LAN nigdy nie pasuje do zapytania wychodzącego. Nowe gniazdo należy do dnsmasq, a nie do klienta, a jądro ocenia trasę dla ruchu samego routera. Reguły źródła, reguły interfejsu i reguły znaczników widzą inną krotkę. Założenie, że znacznik się propaguje, to najczęstszy błąd w tej konfiguracji i jest niewidoczny w przechwyceniu po stronie klienta.

Obie rozmowy dzielą nazwę i czas, i właśnie to sprawia, że wyglądają jak jeden przepływ, gdy pobieżnie przeglądasz przechwycenie.

Gdzie przekazywanie staje się rozwiązywaniem lokalnym

Zacznij od ustalenia, czy port 53 jest przekierowywany, tłumaczony na inny host, czy pozostawiony bez zmian, bo te trzy przypadki zachowują się różnie. Przekierowanie na lokalny port kończy przekazywanie, natomiast tłumaczenie na inną maszynę utrzymuje pakiet w ruchu i zachowuje sensowność krotki klienta.

Przyjrzyj się obu protokołom. Resolver osiągalny przez UDP i TCP będzie testowany przez oba, a zestaw reguł obejmujący tylko UDP zostawia cichą dziurę dla dużych odpowiedzi. Reguły generowane przez własnego menedżera konfiguracji routera też się liczą, a edycja wygenerowanego pliku zwykle przegrywa z następnym przeładowaniem.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Te wyniki odpowiadają po kolei na trzy pytania: co przepisuje zapytanie, co je odbiera i który proces posiada nasłuchujące gniazdo. Gdy właściciel jest znany, polityka wobec upstreamu ma gdzie mieszkać.

Daj resolverowi własną politykę wyjścia

Upstream właściwy dla domeny to najczystsze narzędzie, gdy tylko niektóre nazwy potrzebują tunelu. dnsmasq przyjmuje wiersz server ograniczony do domeny, z opcjonalnym interfejsem lub adresem źródłowym, który kieruje zapytanie poza wybrane urządzenie. To właśnie to sterowanie sprawia, że druga rozmowa podąża za VPN-em.

server=/corp.example/10.30.0.53@tun_work
log-queries

Domena, adres i interfejs powyżej to placeholdery dla twoich własnych wartości. Wybór domeny i kontrola wyjścia pozostają osobnymi decyzjami: trasa musi istnieć, adres źródłowy musi być dozwolony przez resolver upstreamu, a zapora musi przepuścić odpowiedź. Samo sterowanie interfejsem nie jest fail-closed, bo zniknięty tunel może zostawić resolver spadający na inną ścieżkę. Trzymaj każde publiczne obejście z dala od przestrzeni nazw, która musi pozostać prywatna.

Umieść wiersz u właściciela konfiguracji, którego router obsługuje, a nie w wygenerowanym pliku, inaczej następne przeładowanie usunie poprawkę.

Czego wspólny cache nie może zachować

Jeden forwarder z jednym cache obsługuje każdego klienta sieci LAN i to rozbija rozróżnienie, którego niektóre sieci potrzebują. Jeśli dwóch klientów musi rozwiązać tę samą nazwę inaczej, wspólne gniazdo nie ma sposobu odzyskać, który klient pytał. Polityka dla klienta musi żyć w osobnych instancjach resolvera albo w funkcji przekazywania, która zachowuje tożsamość.

Odpowiedź z cache też nie jest dowodem w sprawie nowej ścieżki. Odpowiedź może przyjść z pamięci, podczas gdy trasa do upstreamu pozostaje zepsuta.

Reguły portu 53 nie mówią nic o aplikacjach, które mówią DNS przez HTTPS lub przez TLS. Te zapytania nigdy nie docierają do przekierowania, więc polityka zbudowana tylko na porcie 53 opisuje podzbiór ruchu i powinna być udokumentowana jako podzbiór.

Zweryfikuj drugą rozmowę, nie pierwszą

Przetestuj z jedną nazwą, którą kontrolujesz, i obserwuj obie strony. Przechwycenie po stronie klienta dowodzi, że zapytanie opuściło sieć LAN; tylko strona routera dowodzi, dokąd poszło dalej.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Wyczyść cache przed każdą próbą, bo ciepła odpowiedź ukrywa zepsuty upstream. Powtórz przez TCP, a potem powtórz z wyłączonym tunelem, żeby zobaczyć, co robi resolver, gdy jego preferowana ścieżka zniknie. To ostatnie zachowanie decyduje, czy projekt jest fail-closed, czy tylko szczęśliwy.