Dlaczego wyszukiwanie nazw zawodzi przez trasowany tunel OpenVPN

Host odpowiada na ping po adresie, a każde wyszukiwanie po nazwie zawodzi. Tunel jest podniesiony i trasa istnieje, więc naturalny wniosek jest taki, że VPN jest źle skonfigurowany. Użyteczniejszy wniosek jest taki, że wyszukiwanie nigdy nie było trasowalne: trasowany tunel przenosi unicast IP, podczas gdy zapytanie było rozgłoszeniem szukającym segmentu, którego po drugiej stronie nie ma. Gdy niezgodność warstw staje się widoczna, poprawki same układają się według kosztu.

Mit: tunel jest zepsuty, bo zawodzi wyszukiwanie nazw

Objaw przekonuje, bo wszystko powyżej warstwy nazw działa. Adresy są trasowane, interfejs jest podniesiony, a partner odpowiada na ping. Zawiódł mechanizm wykrywania, który nigdy nie miał ścieżki przez łącze punkt-punkt, i to jest twierdzenie inne niż zepsuty tunel. Rozdzielenie tych dwóch twierdzeń to większość diagnozy.

Traktowanie tego jako usterki tunelu prowadzi do zmian profilu, które nie mogą pomóc. Dodanie opcji, zmiana szyfrowania lub ponowna instalacja klienta pozostawia rozgłoszenie dokładnie tam, gdzie było.

Nazwij mechanizm, który zawiódł, zanim nazwiesz poprawkę. Wyszukiwanie rozgłoszeniowe potrzebuje segmentu, a wyszukiwanie przez resolver potrzebuje adresu, o który można zapytać.

Co TUN przenosi, a czego nie

Urządzenie TUN to interfejs IP i właśnie to czyni go trasowalnym. OpenVPN daje klientowi adres i zestaw tras, a od tego momentu klient wysyła datagramy do partnera. Nic w tym modelu nie tworzy łącza współdzielonego, w którym każdy host słyszy każdą ramkę.

Ruch wykrywania w ogóle nie pasuje do tego modelu. Starsze zapytania o nazwy w Windows, ogłoszenia SSDP i żądania mDNS są wysyłane do wszystkich w segmencie, a nie do jednego celu. Trasowane łącze nie ma żadnego „wszyscy”, do którego można wysłać. Każdy z tych mechanizmów zakłada współdzielone medium.

Tunel może więc być zdrowy, podczas gdy wykrywanie zawodzi całkowicie. To jest zdanie, którego trzeba się trzymać, gdy ktoś zgłasza, że VPN leży.

Mostkowanie działa przez usunięcie granicy

Urządzenie TAP przenosi ramki, a mostek podłącza je do prawdziwego segmentu LAN. Klient ma wtedy adres w tym segmencie i słyszy jego ruch rozgłoszeniowy. Dlatego mostkowanie wydaje się leczyć problem z nazwami. Czyni też klienta zależnym od tego segmentu w adresowaniu.

Lekiem jest usunięcie granicy trasowania, a nie nowa zdolność nazw wewnątrz tunelu. Wszystko, co segment rozgłasza, teraz przekracza także łącze.

Dla małego laboratorium to uczciwa wymiana. W rozproszonym zespole rzadko.

Wypchnięcie DNS i WINS to węższa naprawa

Daj klientowi konkretne miejsce do pytania. dhcp-option DNS i dhcp-option DOMAIN kierują nazwy wewnętrzne do serwera, który zna strefę, a klient Windows wciąż polegający na NetBIOS może w ten sam sposób otrzymać serwer WINS. Tunel pozostaje trasowany, a segment zostaje tam, gdzie należy.

Dwa warunki decydują, czy to zadziała. Wymieniony serwer musi odpowiadać za strefę, a zapytanie musi być dozwolone przez tunel.

Testuj resolver z klienta, a nie z własnej powłoki serwera. Resolver działający lokalnie nic nie mówi o tym, co przenosi tunel.

Ustal, która warstwa zawiodła

Najpierw pingnij adres, potem rozwiąż nazwę i przeczytaj, który serwer odpowiedział. Negatywna odpowiedź serwera, który nie hostuje strefy, wygląda inaczej niż zapytanie, które nigdy nie opuściło maszyny. Nazwa, która się rozwiązuje, ale odrzuca połączenia, to zupełnie trzeci problem.

Multicast stoi za tą samą ścianą. Grupa taka jak 224.0.0.251 nie jest domyślnie przekazywana przez trasowany tunel, a trasa dla grupy nie wystarcza bez ścieżki rozumiejącej multicast lub reflektora w sieci LAN.