Dlaczego odpowiedź DNS zawodzi na bezstanowej zaporze brzegowej VPN

Tunel działa, klienci docierają do hosta VPN, a host nie potrafi nic rozwiązać. Jego własne zapytania wychodzące czysto opuszczają interfejs, więc usterka jest na drodze powrotnej: na nadrzędnej krawędzi, która filtruje ruch przychodzący, nie pamiętając, co host właśnie wysłał. Zezwolenie na port tunelu w ogóle nie opisuje tej wymiany. Odpowiedź na zapytanie DNS to osobny przepływ, a jeśli krawędź jest bezstanowa, nic nie upoważniło jej do powrotu.

Dwie wymiany to nie ta sama wymiana

Zapisz krotki, a błąd staje się oczywisty. Port docelowy zapytania staje się portem źródłowym odpowiedzi, co jest przeciwieństwem tego, co wyobraża sobie większość, dodając regułę przychodzącą dla portu 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Reguła przychodząca wymagająca portu docelowego 53 opisuje ruch adresowany do nasłuchującego DNS działającego na hoście, a to zupełnie inna usługa. Te adresy to przykłady dokumentacyjne, a port źródłowy jest wybierany przez klienta dla każdego zapytania, więc nie jest to wartość, którą można skopiować do reguły i oczekiwać, że będzie dalej działać.

Krawędź bezstanowa kontra stanowa zapora hosta

Bezstanowy filtr krawędziowy ocenia każdy pakiet przychodzący wobec swojej listy reguł, bez żadnej tablicy połączeń za sobą. Zapytanie wychodzące, które pomyślnie wyszło, nie tworzy żadnego zezwolenia dla swojej odpowiedzi przychodzącej, ponieważ urządzenie nie ma zapisu, że zapytanie kiedykolwiek miało miejsce. Stanowa zapora hosta jest przeciwieństwem: jej śledzenie połączeń rozpoznaje ruch powrotny dozwolonej wymiany i przepuszcza go bez reguły dla odpowiedzi. Obie granice istnieją na typowej ścieżce, i obie muszą przepuścić zamierzony pakiet.

Porównanie ma znaczenie, bo oba urządzenia zawodzą inaczej. Stanowa zapora, która odmawia odpowiedzi, zapisuje odrzucenie; bezstanowa krawędź odmawia po cichu, dlatego host po prostu kończy się przekroczeniem czasu.

Buduj zezwolenie wokół protokołu, a nie numeru portu

Ogranicz regułę do rzeczywistych adresów resolvera, hosta docelowego i polityki portu odbiorczego obsługiwanej przez produkt. Miej też na uwadze ścieżkę TCP DNS, ponieważ duża odpowiedź lub wycofanie się przy obcinaniu przenosi wymianę na TCP, a reguła tylko dla UDP tego nie obejmie. Jeśli krawędź obsługuje inspekcję stanową dla zdefiniowanego przepływu, preferuj ją zamiast ręcznie napisanej reguły odpowiedzi, ponieważ ścieżka stanowa automatycznie podąża za portami wybranymi przez klienta.

Następnie potwierdź, który produkt na ścieżce naprawdę filtruje ruch. Udokumentowany zakres krawędzi IPv4 nie ustanawia polityki IPv6, a ruch wewnętrzny dostawcy może nigdy nie przechodzić przez ten sam filtr.

Dlaczego zezwolenie na dowolny port źródłowy 53 nie jest poprawką

Reguła, która akceptuje wszystko, co twierdzi, że ma port źródłowy 53, jest regułą, która akceptuje to, co nadawca zapisze w polu nagłówka. Numer portu nie uwierzytelnia nadawcy i nie dowodzi, że ładunek jest prawidłową odpowiedzią, więc reguła zwiększa ekspozycję hosta, nie czyniąc rozwiązywania bardziej niezawodnym. Zachowaj ograniczenia źródła i zachowaj własne kontrole odpowiedzi klienta, w tym losowość portu źródłowego, zamiast je wyłączać, by uprościć listę dostępu.

Jeśli resolver jest usługą, którą kontrolujesz, ograniczenie do jego adresów wystarczy. Jeśli jest to publiczny resolver, ogranicz do adresów, które zatwierdziłeś, i odnotuj je w komentarzu reguły.

Weryfikuj na właściwej granicy, we właściwym kierunku

Przechwyć na hoście i na krawędzi to samo zapytanie i porównaj krotki, a nie liczbę pakietów. Zapytanie widoczne po obu stronach bez odpowiedzi widocznej po stronie hosta wskazuje na filtr przychodzący; zapytanie widoczne tylko po stronie hosta wskazuje na routing lub sam resolver. Powtórz z zapytaniem TCP, jeśli masz zezwolenie tylko dla UDP, bo właśnie tego lukę pierwszy test nie widzi.

Naprawienie tego kończy wymianę DNS, której host naprawdę potrzebuje. Nie czyni hosta publicznym resolverem, nie autoryzuje przekazywanych przepływów VPN i nie dowodzi, że DNS był przyczyną jakiegoś niepowiązanego problemu z tunelem.