Weryfikacja przepływu IP w Azure mówi dozwolone, ale VPN nadal zawodzi

Tunel lokacja-lokacja jest połączony, maszyna wirtualna zdrowa, ale klient lokalny nic nie otrzymuje. Otwierasz Network Watcher, uruchamiasz weryfikację przepływu IP i ona mówi Access allowed, więc zgłoszenie zostaje zamknięte jako problem z VPN. Ten wynik nie znaczy tego, na co wygląda, bo weryfikacja przepływu IP ocenia reguły zabezpieczeń dla opisanego przepływu i nigdy nie sprawdza, czy Azure ma trasę do twojego prefiksu lokalnego.

Pytanie o filtrowanie i pytanie o routing są osobne, a Network Watcher odpowiada na nie różnymi narzędziami. Wiedza, o które zapytałeś, to większość diagnozy.

Co weryfikacja przepływu IP naprawdę rozstrzyga

Weryfikacja przepływu IP bierze maszynę wirtualną, interfejs sieciowy, kierunek, wartości piątki i protokół, a następnie raportuje decyzję reguły NSG i administratora zabezpieczeń dla tego przepływu. Działa na TCP i UDP, więc nie jest testerem reguł ICMP, a zablokowany ping niczego nie dowodzi o twojej usłudze. Podaj jej rzeczywisty przepływ, a nie domysł. Połączenie przychodzące z sieci lokalnej do portu bazy danych to inny opis niż połączenie wychodzące inicjowane przez maszynę wirtualną.

Jeśli brama tłumaczy adresy, użyj adresu źródłowego, który dociera do ocenianej granicy, a nie tego z konfiguracji klienta. Czytaj też wynik takim, jaki jest. Access allowed znaczy, że warstwa filtrowania przepuściłaby pakiet, gdyby dotarł, i nic więcej.

Czego nie potrafi powiedzieć, to trasa wybrana przez Azure, czy zapora gościa dopuszcza port i czy coś nasłuchuje. To żyje w innych warstwach.

Co dodają następny przeskok i efektywne trasy

Następny przeskok odpowiada na pytanie o przekazywanie: dla tego celu jaki typ następnego przeskoku wybiera Azure, pod jakim adresem, z której tabeli tras. Efektywne trasy wyliczają, co NIC rzeczywiście ma. Uruchom oba i otrzymasz ścieżkę po stronie Azure, którą zielona weryfikacja przepływu IP pozostawia pustą.

Omówienie weryfikacji przepływu IP firmy Microsoft wprost podaje zakres filtrowania, a strony o następnym przeskoku i diagnostyce tras obejmują stronę przekazywania. Cytuj właściwą stronę, gdy zapisujesz ustalenie.

Polecenia są dość krótkie, by uruchomić je z powłoki. az network nic show-effective-route-table wylicza trasy zastosowane do interfejsu. az network watcher show-next-hop ze źródłem i celem zwraca wybrany przeskok. Porównaj interesujący cię prefiks z tą tabelą, a potem potwierdź, który wpis wygrywa.

Przejdź drogę powrotną z NIC maszyny wirtualnej

Zrób to z NIC docelowej maszyny wirtualnej, dla prefiksu klienta lokalnego, nie dla internetu. Droga powrotna to miejsce, w którym ukrywają się awarie lokacja-lokacja, bo sprawdzenie stanu tunelu tylko zgłasza, że skojarzenia zabezpieczeń są podniesione.

Jeśli brakuje oczekiwanej trasy, sprawdź prefiksy zdalne dostarczane przez konfigurację bramy, projekt łączności VNet i dowolne ustawienie propagacji tras. Obiekt bramy sieci lokalnej opisuje stronę lokalną; jego istnienie nie dowodzi, że każdy wymagany prefiks jest obecny i preferowany na NIC. To różne fakty i tylko jeden z nich pojawia się w podsumowaniu portalu.

Czytaj typ następnego przeskoku zamiast kopiować przykład

Ścieżka przez zarządzaną bramę VPN zwykle pokazuje VirtualNetworkGateway jako typ następnego przeskoku. VirtualAppliance opisuje inny projekt przekazywania, zwykle zaporę lub wirtualne urządzenie sieciowe.

Nie twórz trasy urządzenia do zgadywanego punktu końcowego VPN tylko dlatego, że stara odpowiedź na forum użyła tego typu. Jeśli trasa zdefiniowana przez użytkownika zastępuje zamierzoną ścieżkę, znajdź jej właściciela i cel, zanim ją zmienisz. Druga NIC też może zmienić, którego interfejsu używa gość, a jej usunięcie może zepsuć inną usługę zamiast naprawić tę trasę.

Przejdź do granicy, która nadal zawodzi

Gdy filtrowanie i routing oba pasują do projektu, usterka jest gdzie indziej. Sprawdź własną tabelę tras gościa, jego zaporę i to, czy nasłuchujący jest powiązany z oczekiwanym adresem. Potem sprawdź chronione selektory ruchu VPN i lokalną drogę odpowiedzi. Każde z nich to osobny test z osobnym wynikiem.

Zakończ dozwolonym żądaniem aplikacji i obserwacjami z obu stron. Wynik allow i prawidłowy następny przeskok to dwa dowody, a nie dowód, że połączenie się udało.