Routing polityk w OpenWrt: łańcuch, który przechwytuje lokalny DNS

Klienci w LAN rozwiązują przez tunel, a własne zapytania routera po cichu tego nie robią. Aktualizacje pakietów, synchronizacja czasu i dynamiczny DNS wychodzą zwykłym uplinkiem, podczas gdy każde przekazane zapytanie trafia do VPN, i nic w interfejsie nie sugeruje istnienia dwóch różnych ścieżek. Wyjaśnienie nie jest błędem w polityce, lecz kwestią który hak widzi pakiet. Dwa przepływy, jeden adres resolvera, i tylko jeden z nich przechodzi przez router. Rozdzielenie ich to cała poprawka.

Dwa przepływy, jeden adres resolvera

Pierwszy przepływ to ten, który ludzie sobie wyobrażają. Klient pyta resolver routera, resolver przekazuje w górę, a ten przekazany pakiet przechodzi przez router przy wyjściu. Ten pakiet jest widoczny dla wszystkiego, co obserwuje przekazywany ruch.

Drugi przepływ nigdy nie nadchodzi znikąd. Tworzy go router, więc nie ma ani pakietu przychodzącego, ani kroku przekazywania do dopasowania.

Oba mogą celować w ten sam adres resolvera, i właśnie dlatego różnicę łatwo przeoczyć. Ten sam cel, inne pochodzenie, inny łańcuch. Gdy zobaczysz pochodzenie, reszta diagnozy podąża.

Pakiety przekazywane i tworzone lokalnie wchodzą inaczej

Przekazywany ruch jest oceniany, gdy nadchodzi z innego interfejsu. Pakiety routingu polityk ujawniają to jako łańcuch prerouting, a reguła umieszczona tam widzi każdy pakiet przechodzący przez router. Dlatego zapytania klientów zachowują się dokładnie tak, jak opisuje polityka, i dlatego router ją ignoruje. Reguła nie jest błędna, jest tylko przypięta do haka, do którego router nigdy nie dociera. Przenieś ją, a to samo dopasowanie zacznie działać.

Ruch tworzony lokalnie powstaje w procesie na routerze i wchodzi na ścieżkę wyjściową. Jest routingowany przez decyzję samego routera i spotyka politykę tylko wtedy, gdy polityka obejmuje ten łańcuch. Nie ma interfejsu przychodzącego do dopasowania ani decyzji przekazywania do obserwacji.

To cecha miejsca, w którym rodzą się pakiety, a nie jakiegoś konkretnego pakietu. Reguła napisana dla jednego łańcucha po prostu nie ma zdania o drugim. Żadne strojenie reguł tego nie zmienia.

Wybierz łańcuch wyjściowy, a potem zawęź dopasowanie

Poprawka polega na przypięciu tej samej intencji także do łańcucha wyjściowego, albo na przeniesieniu tam reguły, gdy chodzi ci o własne zapytania routera. W instalacji OpenWrt zbudowanej na pakiecie routingu polityk oznacza to wybranie output zamiast prerouting w ustawieniu łańcucha reguły. Zachowaj obie reguły, jeśli obie populacje potrzebują pokrycia.

Potem zawęź to, do czego dopasowuje się reguła. Docelowe adresy resolvera na porcie, którego resolver faktycznie używa, to znacznie mniejsza decyzja niż wysyłanie do tunelu wszystkiego, co tworzy router.

Trzymaj dwie reguły jawnie, zamiast próbować napisać jedną obejmującą oba łańcuchy. Osobne reguły są łatwiejsze do czytania, i pozwalają wyłączyć ścieżkę routera bez zakłócania ruchu klientów podczas debugowania. Czynią też liczniki sensownymi pojedynczo.

Trzymaj własny transport tunelu poza regułą

Zewnętrzne połączenie tunelu również tworzy router. Reguła wysyłająca cały ruch tworzony lokalnie do tunelu będzie routować tunel przez siebie samego, i tunel w ogóle nie wstanie.

Dostęp administracyjny jest drugą ofiarą. Sesje administracyjne powstałe na routerze lub odpowiedzi na nie mogą zostać wciągnięte do tunelu przez zbyt szeroką regułę lokalną i stać się nieosiągalne z LAN.

Wyklucz punkt końcowy tunelu z dopasowania i trzymaj regułę ograniczoną do adresów resolvera. To wystarcza dla wymogu DNS i jest dość małe, by o tym myśleć.

Testuj obie populacje, nie jedną

Obserwuj, jak router wykonuje własne zapytanie, i zanotuj, który interfejs je niósł. Powtórz wyszukiwanie z hosta w LAN i zanotuj, którą ścieżkę wybrało. Liczniki na regułach polityk pokazują obie odpowiedzi bez zgadywania.

Traktuj wyniki jako dwa ustalenia. Klient, który rozwiązuje przez tunel, nic nie mówi o routerze, a router, który rozwiązuje poprawnie, nic nie mówi o kliencie na innym nasłuchu. Zapisz je jako osobne wiersze w dzienniku zmian.

Sprawdź też port: reguła dopasowująca port docelowy 53 pomija resolver osiągany przez DNS over TLS na 853 lub punkt końcowy HTTPS. Dopasuj transport, którego skonfigurowany upstream naprawdę używa, a wyciek zamknie się z właściwego powodu.