Azure P2S VPN nie potrafi rozwiązać nazwy prywatnego punktu końcowego

Łączysz się z tunelem point-to-site, pingujesz prywatny adres, otwierasz aplikację i dostajesz 403 albo błąd certyfikatu. Oba objawy wskazują na DNS, ale to różne usterki: jedna oznacza, że klient rozwiązał adres publiczny, druga, że rozwiązał adres prywatny i podał nazwę, której certyfikat nie obejmuje. Przejdź kontrole poniżej po kolei i zatrzymaj się na pierwszym błędzie, ponieważ wpis w hosts albo odpowiedź z pamięci podręcznej mogą sprawić, że każda kolejna kontrola przejdzie z niewłaściwego powodu. Trzymam tę kolejność w pliku tekstowym obok swoich profili VPN, bo poprawka niczego nie zmienia w tunelu, a wszystko w tym, co wie klient.

Zacznij od adresu, który klient faktycznie otrzymuje

Pytaj resolver bezpośrednio, zamiast ufać aplikacji. W Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net pokazuje, który widok otrzymał klient. Odpowiedź publiczna oznacza, że nic dalej nie dotrze do punktu końcowego; prywatny adres punktu końcowego oznacza, że DNS jest zakończony, a następną kontrolą jest samo połączenie.

Prywatny punkt końcowy nie zmienia nazwy usługi. Konto lub aplikacja zachowuje swoją zwykłą pełną nazwę, a punkt końcowy zmienia tylko adres, na który ta nazwa jest rozwiązywana dla klientów w sieci wirtualnej. Dlatego ta sama nazwa hosta jest rozwiązywana prywatnie z maszyny wirtualnej w sieci i publicznie z laptopa, któremu nigdy nie dano widoku prywatnego.

Sprawdź strefę, jej powiązanie i rekord przed tunelem

Trzy warunki muszą być spełnione razem: strefa prywatna istnieje, jest powiązana z siecią wirtualną, do której wchodzą do Azure brama VPN i klienci, oraz zawiera rekord A punktu końcowego wskazujący na adres prywatny. Powiąż strefę z niepowiązaną siecią, a brama nadal będzie rozwiązywać rekord publiczny, podczas gdy wszystko w tunelu będzie wyglądać zdrowo.

Nazwy stref należą do usług, a nie ogólnie do połączeń prywatnych. App Service zwykle używa privatelink.azurewebsites.net, magazyn i SQL mają własne przestrzenie nazw, a pożyczenie strefy innej usługi daje strefę, która istnieje i nie odpowiada nic użytecznego.

Daj klientowi resolver, do którego naprawdę dotrze

168.63.129.16 odpowiada z maszyn wirtualnych Azure i nie jest serwerem DNS dla laptopa po drugiej stronie tunelu point-to-site. Klient potrzebuje resolvera osiągalnego przez tunel: punktu końcowego przychodzącego Azure DNS Private Resolver, przekazującego wewnątrz sieci wirtualnej albo wpisów serwera DNS przenoszonych w profilu klienta VPN, aby klient pytał sieć wirtualną bezpośrednio.

Skonfigurowany, ale nieosiągalny resolver zachowuje się dokładnie jak brak resolvera, a objawem jest przekroczenie limitu czasu, a nie błędna odpowiedź, dlatego jest błędnie czytany jako problem zapory. Testuj go zapytaniem, które tunel ma przenosić, a nie publiczną nazwą, która i tak by się udała przez połączenie lokalne.

Jeśli przekazujesz, zamiast wypychać ustawienia, przekazuj przestrzeń nazw należącą do strefy prywatnej, privatelink.azurewebsites.net, a nie całą azurewebsites.net. Warunkowy przekazujący, który połyka cały sufiks nadrzędny, wysyła do Azure każde wyszukiwanie usługi, także te, które powinny zostać lokalne.

Użyj nazwy, dla której wystawiono certyfikat

Gdy adres jest poprawny, ujawnia się druga usterka. Magazyn i App Service publikują alias privatelink, a ten alias nie musi być nazwą z certyfikatu. Wgranie AzCopy na privatelink.blob.core.windows.net nie przeszło walidacji; to samo wgranie na <account>.blob.core.windows.net/<container> zostało rozwiązane na adres prywatny i przeszło, więc pozostało na ścieżce prywatnej bez żadnego obejścia.

Zasada działa w przeglądarce i dla App Service: łącz się z nazwą hosta, którą obejmuje certyfikat, i pozwól DNS dostarczyć adres prywatny. Nie uciekaj się do obejścia walidacji, bo zamienia błąd nazewnictwa w regresję bezpieczeństwa. Udany ping dowodzi trasy i nic nie mówi o nazwie wewnątrz uścisku, dlatego to pozostaje osobnymi kontrolami.

Kolejność czterech kroków, która izoluje każdą warstwę

1. Potwierdź, że klient VPN ma adres z puli point-to-site i trasę do adresu prywatnego punktu końcowego.
2. Rozwiąż dokładną nazwę używaną przez aplikację i porównaj odpowiedź z adresem punktu końcowego.
3. Otwórz połączenie TCP do punktu końcowego na porcie usługi, a następnie odczytaj nazwę certyfikatu przedstawionego w tym połączeniu.
4. Dopiero teraz testuj autoryzację, bo działająca ścieżka i ważny certyfikat nadal nie dają dostępu do zasobu.

Odrzucone połączenie przy poprawnym adresie wskazuje grupę zabezpieczeń sieci albo stan połączenia prywatnego punktu końcowego, a nie DNS, więc sprawdź je, zanim ponownie zmienisz ustawienia resolvera. Niezgodność nazwy TLS odsyła cię do nazwy hosta w adresie URL i podmiotu certyfikatu. Trzymaj razem wynik rozwiązania, nazwę certyfikatu i dokładny adres URL; te trzy wartości wyjaśniają większość takich przypadków bez dotykania bramy.

Użyj maszyny wirtualnej w sieci wirtualnej jako kontroli. Jeśli nazwa rozwiązuje się tam prywatnie, a z tunelu publicznie, strefa i rekord są poprawne, a jedyną różnicą jest ścieżka resolvera klienta, co potwierdza się szybciej niż kolejne przejście przez konfigurację punktu końcowego.

Klienci też buforują. Rekord, który odpowiedział publicznie dziesięć minut temu, odpowiada nadal po naprawieniu strefy, więc wyczyść pamięć podręczną przed ponownym testem. W Windows ipconfig /flushdns czyści pamięć podręczną klienta; reguły zasad rozwiązywania nazw pozostają, decydują, który sufiks idzie do którego serwera, i mogą nadal wysyłać przestrzeń nazw do resolvera, który właśnie zastąpiłeś.

Gdzie należy wpis w hosts

Dodanie adresu punktu końcowego do pliku hosts to dobra diagnostyka i zły projekt. Dowodzi, że brakującym elementem jest mapowanie nazwy na adres, i pozwala przetestować wszystko po tym kroku, ale jest niewidoczne dla użytkowników, psuje się, gdy zmienia się adres punktu końcowego, i ukrywa strefę, która powinna odpowiadać.

Pozostawiony wpis testowy jest gorszy od nieaktualnej pamięci podręcznej, bo w zależności od kierunku błędu może pokazać naprawioną ścieżkę jako zepsutą albo zepsutą jako naprawioną. Usuń go przed ostatnim przebiegiem i rozwiązuj tylko resolverem produkcyjnym.

Krótkie nazwy wymagają sufiksu wyszukiwania, a pełne nazwy nie, więc najpierw przetestuj pełną nazwę, potem zdecyduj, czy przepływ pracy potrzebuje sufiksu wypychanego przez profil klienta. Microsoft dokumentuje nazwy stref i kształty rekordów dla każdej usługi w swoich wytycznych DNS dla prywatnych punktów końcowych; przeczytaj wpis dla swojej usługi, zamiast kopiować strefę z innej.