VPN S2S w Azure połączona, ale brak ruchu: przeczytaj log IKE

Portal mówi Connected, tunel ma licznik czasu działania, a trace z twojej maszyny wirtualnej ginie na drugim hopie. Stan połączenia opisuje negocjację IKE i IPsec, a nie to, czy pojedynczy pakiet przetrwa warstwę zasad po którejkolwiek stronie. Dwa błędy wyjaśniają większość takich zgłoszeń i żadnego z nich nie naprawia zmiana trasy w Azure. Oba są już zapisane w logu, który wygenerowała brama, dlatego zaczynam tam, a nie w tabeli tras.

Co naprawdę poświadcza Connected

Połączone połączenie site-to-site oznacza, że faza 1 i faza 2 zostały zakończone i że asocjacje bezpieczeństwa działają. To stwierdzenie o negocjacji: obie strony uzgodniły propozycję, wymieniły klucze i zainstalowały parę SA. Nie mówi nic o tym, czy selektory ruchu odpowiadają podsieciom, które uważasz za chronione, ani o tym, czy druga strona po odszyfrowaniu gdzieś skieruje pakiet. Tunel może stać tygodniami, odrzucając każdy interesujący przepływ, i dokładnie ten wzorzec skłania ludzi do odbudowy zdrowej bramy.

Dwa błędy, które warto sprawdzić najpierw, to peer proponujący AH zamiast ESP oraz sieć wirtualna z numeracją w przestrzeni, której brama nie potraktuje jako wewnętrznej.

Otwórz wyeksportowany log, zanim dotkniesz tras

W portalu otwórz bramę sieci wirtualnej i uruchom operację VPN troubleshoot dla połączenia, następnie pobierz utworzony pakiet i rozpakuj go. W środku jest log IKE z wymianami fazy 1 i fazy 2, ze znacznikami czasu i czytelny jako zwykły tekst. Szukaj w nim wiersza transform, zamiast czytać od góry do dołu, ponieważ interesujący wpis zwykle znajduje się kilkaset wierszy dalej. Jeśli nie masz dostępu do portalu, te same dane diagnostyczne pojawiają się w miejscu docelowym logów bramy, gdy ustawienia diagnostyki są włączone.

Dwa wpisy niosą większość wartości. Pierwszy brzmi mniej więcej expected ESP with combined authentication and cipher, received AH. Drugi to błąd nieprawidłowego payloadu podczas wymiany IKE, co zwykle oznacza źle zbudowane lub nieobsługiwane pole propozycji.

Oba opisują, co zaproponowało urządzenie lokalne, więc oba są ustawieniami po stronie peera. Ponowne wygenerowanie strony Azure nie zmienia propozycji wysyłanej przez zaporę, a robienie tego mimo wszystko to najczęściej marnowana godzina w tym procesie. Na peerze ustaw fazę 2 na ESP z połączonym uwierzytelnianiem i szyfrem i pozwól jej wynegocjować algorytm, a następnie sprawdź, czy pole wyboru dostawcy o nazwie w rodzaju combined mode po cichu wybiera propozycję AH poniżej.

Potwierdź przestrzeń adresową sieci wirtualnej

Brama oczekuje, że sieć wirtualna będzie w zakresach prywatnych. Sieć z numeracją w bloku publicznym, na przykład zaczynająca się od 111.x, może podnieść tunel, podczas gdy Azure odmawia traktowania tej przestrzeni jako wewnętrznej, więc połączenie wygląda zdrowo i żaden przepływ nie jest akceptowany. Potwierdź przestrzeń adresową, zanim spędzisz popołudnie na selektorach. Jeśli numeracja jest twardym wymogiem ze starszego przydziału, poprawką jest zmiana planu adresów, a nie inna brama.

Zapisz nakładanie się na zakresy lokalne, będąc w bloku przestrzeni adresowej, ponieważ nakładające się prefiksy dają inny błąd, który z perspektywy klienta wygląda podobnie.

Sprawdź prefiksy w obu kierunkach

Zasób bramy sieci lokalnej zawiera prefiksy lokalne i muszą one odpowiadać podsieciom, które urządzenie zdalne naprawdę chroni. Podsumowanie obejmujące adresy, które urządzenie odrzuca, przepuści część przepływów, a na innych zawiedzie, co czyta się jak sporadyczny błąd routingu, a nie jak niezgodność konfiguracji. Sprawdź także drugą stronę: jeden koniec wymienia /16, a drugi trzy /24 wewnątrz niego — to klasyczny częściowy błąd. Żadna lista nie jest sama w sobie wiążąca, więc porównaj je obok siebie, zamiast ufać tej, którą widzisz.

Zmiana prefiksu nie zawsze jest przejmowana sama, więc zaplanuj ponowne zapisanie lub odtworzenie obiektu połączenia, a następnie potwierdź, że nowe prefiksy pojawiają się po obu stronach.

Testuj ścieżkę, nie ping

Trace, który oddziela działający tunel od działającej trasy, wygląda tak: pierwszy hop to brama lokalna, potem kilka nieodpowiadających hopów, potem odpowiada host zdalny. Jeśli trace nigdy nie dociera do hosta, przetestuj port TCP, którego aplikacja naprawdę używa, ponieważ ICMP jest filtrowany wystarczająco często, by nieudany ping dowodził bardzo niewiele. Uruchom ten sam trace z hosta zdalnego w stronę maszyny wirtualnej w Azure. Asymetria między oboma wynikami to najszybszy sposób znalezienia brakującej trasy powrotnej lub reguły dopuszczającej tylko jeden kierunek.

Zapisz propozycję peera, obie przestrzenie adresowe i czas utworzenia połączenia w zgłoszeniu, aby następny inżynier wiedział, które wartości odbudowano, a których nigdy nie ruszono.

Jeśli log wraca pusty, brama może w ogóle nie kończyć twojego połączenia. Potwierdź, że adres peera w bramie sieci lokalnej odpowiada urządzeniu, z którego czytasz log, ponieważ dwie bramy w jednej subskrypcji łatwo pomylić podczas odbudowy. Ten błąd kosztuje dzień i nie zostawia śladu w żadnym logu.