Dlaczego prywatny punkt końcowy nadal odpowiada adresem publicznym

Laptop się łączy, tunel zgłasza aktywność, a konto magazynu nadal odrzuca każde żądanie. Prywatny punkt końcowy istnieje, trasa do jego podsieci istnieje, a nazwa albo odpowiada adresem publicznym, albo wcale się nie rozwiązuje. Z tunelem wszystko jest w porządku: klientowi nigdy nie powiedziano, który serwer ma odpowiadać za tę nazwę. Prześledź zapytanie na zewnątrz, a luka stanie się oczywista.

Zacznij od resolvera klienta

Zapytaj klienta, który serwer odpytywany jest przy aktywnym tunelu. Profil punkt-do-lokacji dostarcza ten adres, a profil, który nic nie dostarcza, pozostawia systemowi operacyjnemu powrót do domyślnych ustawień karty sieciowej.

Publiczne resolvery nie mają żadnego wglądu w strefę prywatną, więc odpowiadają z internetu, co jest dokładnie ich zadaniem. Pierwszym sprawdzeniem jest więc adres używanego resolvera, a nie tunel i nie punkt końcowy.

Przeczytaj, czym odpowiedź jest naprawdę

Rozwiąż nazwę usługi i odczytaj adres, który wraca. Publiczna odpowiedź oznacza, że zapytanie dotarło do serwera, który nie widzi strefy. Brak odpowiedzi oznacza, że nazwa istnieje tylko prywatnie i nic, do czego klient może dotrzeć, jej nie przechowuje.

Te dwa wyniki powodują podobne błędy aplikacji i należą do różnych właścicieli. Jeden to problem wyboru resolvera, drugi to brakujące połączenie strefy.

Wpis w hosts dowodzi trasy, a potem kłamie

Umieszczenie adresu punktu końcowego w lokalnym pliku hosts to najszybszy sposób udowodnienia, że tunel i zapora usługi już działają. Jeśli żądanie z tym wpisem się powiedzie, zepsute jest tylko rozwiązywanie nazw. To także zmiana na jednej maszynie, obejmująca dokładnie jedną nazwę.

Nie pomaga drugiemu kontu, drugiemu punktowi końcowemu ani koledze, i psuje się bez ostrzeżenia, gdy punkt końcowy zostanie odtworzony pod nowym adresem.

Co gorsza, sprawia, że twoja maszyna zachowuje się inaczej niż wszystkie inne, i właśnie tak awaria resolvera przeżywa tydzień śledztwa. Użyj go do potwierdzenia trasy, potem usuń i napraw przyczynę.

Połącz strefę i rozdaj resolver

Dwa warunki muszą być spełnione jednocześnie. Strefa prywatna musi być połączona z siecią wirtualną, w której mieszka punkt końcowy, a klient musi wysyłać zapytania do serwera, który tę strefę potrafi odczytać. Wejściowy punkt końcowy DNS Private Resolver zapewnia taki adres wewnątrz sieci i odpowiada na zapytania przychodzące przez tunel. Umieść ten adres w profilu VPN i dodaj prywatny sufiks, który klient ma stosować.

Istniejący resolver lokalny może osiągnąć ten sam wynik przez przekazywanie warunkowe skierowane na strefę.

Reguły sieciowe resolvera liczą się tak samo jak routing. Jeśli reguła wejściowa wyklucza zakres klientów VPN, zapytania wygasają zamiast zwracać błędną odpowiedź. To właśnie ten limit czasu odsyła ludzi do tablicy tras, w której nic nie jest zepsute.

Sprawdź nazwę, port i tożsamość po kolei

Pracuj po kolei: rozwiąż nazwę, potwierdź, że odpowiedź jest prywatna, otwórz port, a następnie wykonaj uwierzytelnione żądanie. Każdy etap ma własnego właściciela i własną sygnaturę awarii.

Prywatna odpowiedź, po której następuje limit czasu, wskazuje na trasę lub zaporę. Publiczna odpowiedź wskazuje resolver. Zakończone połączenie zwracające błąd tożsamości należy do usługi.

Jeszcze jedna awaria należy do tej listy. Zapora usługi, która zezwala na adres klienta, przestaje pasować, gdy pula po ponownym połączeniu przydzieli ten adres innej sesji. Czytaj adres wywołującego zapisany przez usługę, a nie ten, który klient uważa, że ma. Te dwa nie zgadzają się częściej, niż ludzie się spodziewają. Wskazówki dotyczące Azure DNS Private Resolver omawiają połączenie strefy i układ przekazywania.