Ruch powrotny Azure P2S VPN działa tylko w jedną stronę

Ikona tunelu jest zielona, NSG wygląda na przepuszczającą, efektywne trasy wyglądają poprawnie, a mimo to VM nadal nie może otworzyć połączenia z powrotem do podłączonego klienta. Zwykłe założenie mówi, że działający tunel point-to-site jest symetryczny: jeśli klient dociera do VM, VM dociera do klienta. To założenie jest błędem w rozumowaniu, nie w konfiguracji. Tunel może przenosić jeden kierunek nieproszonego przepływu i odrzucać drugi, a poprawka zależy od tego, która warstwa go odrzuca.

Mit: połączony tunel to tunel dwukierunkowy

Tunel VPN to ścieżka polityki, nie kabel. Każdy kierunek jest porównywany z selektorami, trasami i filtrami, a każdy z nich może zezwolić na jeden kierunek, blokując drugi.

W praktyce asymetria jest tak częsta, że kierunek należy do pierwszego testu, a nie ostatniego. Klient inicjuje, brama śledzi przepływ, a odpowiedź podąża za utworzonym stanem. VM, która rozpoczyna nowy przepływ, nie ma takiego stanu, więc zależy od tego, czy ścieżka powrotna jest jawnie trasowalna i dozwolona. Gdy tej ścieżki brakuje, próba połączenia ginie, zanim zobaczy ją jakakolwiek aplikacja.

Sprawdź kierunek, zanim sprawdzisz osiągalność

Wybierz jeden adres klienta, jeden adres VM i jeden protokół. Połącz się z klienta i zapisz wynik; następnie rozpocznij ten sam test z VM i też go zapisz. Jeśli pierwszy się powiedzie, a drugi nie, pula klientów, skojarzenie bramy i ścieżka od klienta do VNet działają.

Następnym krokiem są dowody, a nie kolejne reguły. Sprawdź NSG w podsieci VM w obu kierunkach, odczytaj efektywne trasy na karcie sieciowej VM i przechwyć pakiety na VM, gdy klient wysyła ruch. Żądanie, które przychodzi bez odpowiedzi, to problem filtra lub trasy powrotnej; żądanie, które nigdy nie przychodzi, to problem ścieżki. Nie traktuj nieudanego ping jako dowodu, że VM jest nieosiągalna, ponieważ polityka ICMP może odrzucić odpowiedź, podczas gdy TCP działa.

Ścieżka powrotna IKEv2 point-to-site jest zwykłym podejrzanym

W raporcie Azure, na którym opiera się ten artykuł, klient docierał do VM przez IKEv2, ale przychodzący ICMP z VM do klienta zawodził, dopóki typ tunelu bramy nie został przełączony na OpenVPN. Autor raportu twierdzi, że Microsoft potwierdził ograniczenie w ścieżce IKEv2 point-to-site, gdzie ruch powrotny z VM do klienta nie jest trasowany symetrycznie, o ile sesji nie rozpoczął klient. IKEv2 opiera się na selektorach ruchu, a brama w tym przypadku nie uwzględniła kierunku powrotnego.

To nie czyni OpenVPN ogólnie lepszym typem tunelu. To czyni typ tunelu zmienną w macierzy testów dla tego obciążenia.

Zmiana typu tunelu to zmiana usługi, nie przełącznik. Każdy klient potrzebuje zgodnego profilu, a brama może wymagać innego certyfikatu lub konfiguracji uwierzytelniania. Odtwórz zachowanie jednokierunkowe z jednym klientem testowym i jedną VM testową, zmień typ według zatwierdzonego harmonogramu, a następnie powtórz te same testy kierunku. Jeśli zachowanie przetrwa zmianę, typ tunelu nie był przyczyną i zawęziłeś problem, nie dotykając produkcji.

Mit: wykrywanie przez broadcast przekracza granicę VNet

Drugie założenie zawodzi z niepowiązanego powodu. Wirtualna sieć Azure nie przenosi ruchu broadcast, więc VM nie może odbierać ramek broadcast z sieci lokalnej przez połączenie site-to-site lub point-to-site. Aplikacje, które znajdują partnerów przez broadcast, jak starsze przeglądanie plików lub niektóre protokoły wykrywania urządzeń, nigdy nie zobaczą strony zdalnej, niezależnie od tego, jak zapisano trasy.

Zastąp wykrywanie przez broadcast nazwami DNS, usługą katalogową lub jawną listą partnerów. Jeśli aplikacja nie ma alternatywy unicast, projekt potrzebuje innego mechanizmu wykrywania, a nie szerszego tunelu.

Co zmienić i jak to udowodnić

Jeśli test kierunku zawodzi tylko na IKEv2, zapisz typ tunelu bramy, pulę adresów klientów i dokładny test ICMP lub TCP, a następnie oceń zatwierdzony profil OpenVPN dla dotkniętych klientów. Jeśli zawodzi na każdym typie tunelu, popracuj nad ścieżką powrotną: adres klienta musi być trasowalny z podsieci VM, każda trasa zdefiniowana przez użytkownika musi wskazywać prawidłowy następny skok, a zapora klienta musi akceptować ruch przychodzący. Dołącz dowody NSG i tras do zgłoszenia.

Weryfikuj aplikacją, nie pingiem. Udana wymiana ICMP po zmianie nic nie mówi o porcie usługi, jej uwierzytelnianiu ani rozwiązywaniu nazw. Powtórz test po ponownym połączeniu, ponieważ klient, który otrzyma inny adres z puli, może zmienić wynik. Następnie powtórz go jeszcze raz, gdy klient zaśnie i się obudzi, bo to w wznowionej sesji zachowanie jednokierunkowe często powraca.