Azure połączenie punkt-lokacja łączy się, ale żaden prywatny zasób nie odpowiada

Połączono to stan tunelu, a nie twierdzenie o osiągalności. Klient punkt-lokacja może zakończyć IKE, otrzymać adres i nadal donikąd nie dotrzeć, ponieważ brama przekazuje ruch tylko dla sieci, które VNet już zna. Wykonaj te pięć kontroli po kolei i zatrzymaj się przy pierwszym niepowodzeniu. Przeskakiwanie do przodu to sposób, w jaki problem DNS przez godzinę jest traktowany jako problem zapory.

Kolejność jest ważniejsza niż lista.

Kontrola 1: zdecyduj, co tunel ma przenosić

Azure VPN Gateway kończy tunel i przekazuje ruch należący do VNet; nie jestogólnym wyjściem do internetu. Jeśli użytkownicy oczekują, że ich przeglądanie wyjdzie przez Azure, projekt jest błędny jeszcze przed uwzględnieniem jakiegokolwiek ustawienia klienta. Włącz split tunneling, aby lokalny internet pozostał na ścieżce lokalnej, a gdy naprawdę potrzebny jest stały adres wyjściowy, użyj instancji NAT lub tunelu lokacja-lokacja.

Zapisz, do czego klient ma dotrzeć, zanim cokolwiek przetestujesz. Bez tej listy każdy częściowy wynik wygląda jak postęp.

Kontrola 2: porównaj przestrzenie adresowe przed certyfikatami

Nakładanie ocenia się na szerszych zakresach, więc dwie sieci, które na poziomie podsieci wyglądają różnie, nadal kolidują, jeśli ich bloki nadrzędne się pokrywają. Podsieć bramy musi być dedykowana i wystarczająco duża dla SKU, a pula adresów klienta nie może kolidować z VNet ani z niczym osiągalnym przez peering. Zmień plan i wdróż ponownie, bo dodawanie tras dla kompensacji daje tunel, który działa dla niektórych celów, a dla innych niepojęcie nie. Aprowizacja zawodzi tu głośno, i to jest dobry przypadek.

Uwierzytelnianie to kolejna brama. Profile certyfikatu, RADIUS i Entra ID nie są wymienne, a pakiet klienta różni się dla każdego.

Kontrola 3: rozwiąż prywatną nazwę od środka

Klient zachowuje własny resolver, chyba że pobrany profil zawiera serwery DNS VNet, a ta lista jest osadzana w momencie pobierania. Dodaj forwarder wewnątrz VNet, ustaw go jako serwer DNS VNet, a następnie ponownie pobierz i zaimportuj pakiet klienta. Ponowne użycie starego pakietu testuje tylko starą listę resolverów.

Najpierw przetestuj adres, bo to oddziela routing od nazewnictwa w jednym kroku: Test-NetConnection 10.20.1.4 -Port 3389.

Jeśli adres odpowiada, a nazwa nie, zapytaj resolver bezpośrednio za pomocą Resolve-DnsName files.corp.example -Server 10.20.0.4. Jeśli zawiodą oba, usterka nie jest w DNS i powinieneś przestać edytować ustawienia DNS. DNS platformy Azure pod 168.63.129.16 odpowiada tylko od wewnątrz VNet, więc klient z zewnątrz nie może używać tego adresu jako resolvera.

Kontrola 4: przetestuj usługę za tunelem

Zdrowy tunel i zamknięty port wyglądają identycznie z perspektywy klienta. Sprawdź zaporę gościa, potem grupę zabezpieczeń sieci na podsieci lub NIC, a potem czy usługa nasłuchuje na adresie prywatnym, a nie tylko na loopback. Zezwól puli klientów jako źródłu, zamiast otwierać regułę do internetu, i pamiętaj, że SMB do Azure Files wymaga ścieżki prywatnego punktu końcowego prowadzonej przez tunel. Gdy zasób odpowiada po IP, ale nie po nazwie, wróć do kontroli 3, zamiast dotykać bramy.

Jedna tabela trzyma warstwy osobno podczas pracy:

Kontrola 5: zapisz profil przed eskalacją

Wpisz w zgłoszeniu typ bramy, typ tunelu, metodę uwierzytelniania i system operacyjny klienta. Profil IKEv2 z certyfikatem i profil RADIUS zawodzą z różnych powodów, a klient zbudowany dla innego typu tunelu łączy się tylko wtedy, gdy brama oferuje zgodny protokół.

Dla małego zespołu trwałym rozwiązaniem jest jeden VNet, jeden forwarder DNS i udokumentowany klient split-tunnel. Jeśli wymaganiem jest stałe publiczne wyjście, zakończ tunel lokacja-lokacja na zaporze, którą kontrolujesz, i kieruj tam ruch internetowy, zamiast prosić bramę punkt-lokacja o coś, do czego nigdy jej nie zbudowano.