VPN lokacja-lokacja w Azure z partnerem za NAT: lista kontrolna

Wykonaj te kontrole po kolei i zatrzymaj się na pierwszej, która zawiedzie. Większość zgłoszeń, że Azure nie obsługuje urządzenia za NAT, okazuje się adresem partnera, do którego Azure nie dociera, albo tunelem, który nigdy nie zaczyna się po właściwej stronie. Transport zewnętrzny i routing wewnętrzny to dwa różne problemy, a ich mieszanie kosztuje popołudnie. Każdy krok poniżej daje obserwację, którą możesz przekazać komuś innemu.

Krok 1: potwierdź, że partner w ogóle jest za NAT

Porównaj adres na interfejsie WAN urządzenia z adresem, który Azure widzi dla niego. Jeśli się różnią, coś tłumaczy, a ten translator jest teraz częścią twojego projektu VPN. Zapytaj dostawcę, czy mapowanie jest statyczne, czy współdzielone, bo współdzielone mapowanie zmienia to, na czym możesz polegać. Urządzenie z prywatnym adresem WAN i bez przekierowania to inny przypadek niż urządzenie za NAT klasy operatorskiej ze stabilnym mapowaniem publicznym.

Jeśli oba adresy się zgadzają, zatrzymaj się tutaj: NAT nie jest twoim problemem, a reszta tej listy nie pomoże.

Zapisz oba adresy i model translatora w zgłoszeniu. Ta jedna linia zapobiega następnej rundzie pytań, dlaczego skonfigurowany partner nie odpowiada.

Krok 2: uzgodnijcie, kto inicjuje

Najczęstsze pytania dotyczące Azure VPN Gateway wymieniają obsługę NAT-T i dodają, że urządzenie lokalne powinno inicjować tunel IPsec, gdy znajduje się za NAT. To pasuje do działania tłumaczenia stanowego, ponieważ translator utrzymuje mapowanie, bo urządzenie wewnętrzne wysłało pierwszy pakiet. Jeśli oczekuje się, że zainicjuje Azure, a nic nie przychodzi, by utworzyć to mapowanie, tunel nigdy nie startuje.

Skonfiguruj partnera tak, aby błąd tylko-odpowiadającego był oczywisty, i sprawdź, czy urządzenie ponawia samo, czy potrzebuje wyzwalacza. Niektóre urządzenia podnoszą tunel tylko wtedy, gdy pojawi się interesujący ruch, co jest w porządku, dopóki interesującym ruchem nie okaże się sonda kondycji, która nigdy nie przychodzi.

Obserwuj wymianę IKE na urządzeniu podczas ręcznego inicjowania; cisza tam jest odpowiedzią routingu lub zapory, nie odpowiedzią Azure.

Krok 3: ustaw poprawnie adres partnera

Azure potrzebuje osiągalnego publicznego adresu partnera w obiekcie lokalnej bramy sieciowej, zwykle publicznego adresu translatora, a nie wewnętrznego adresu urządzenia. Tożsamość, którą uwierzytelnia się urządzenie, to osobne pole i może zasadnie różnić się od adresu, na który dzwoni Azure. Trzymaj je osobno, bo zamiana daje błąd uwierzytelniania, który wygląda dokładnie jak problem z NAT.

Jeśli publiczny adres się zmieni, ten obiekt musi się zmienić razem z nim. Nazwa, która rozwiązuje się na nieaktualny adres, jest gorsza niż statyczny adres, który trzeba aktualizować ręcznie.

Zapisz wszystkie trzy wartości: lokalny adres urządzenia, przetłumaczony adres publiczny i skonfigurowaną tożsamość partnera.

Krok 4: otwórz tylko porty, których potrzebuje NAT-T

NAT-T przenosi ESP wewnątrz UDP, a RFC 3948 opisuje to kapsułkowanie z portem 4500 używanym po wstępnych negocjacjach na porcie 500. Twoja zapora i translator muszą oba dopuszczać wymianę i jej ruch powrotny. Dopuszczenie niepowiązanego portu TCP niczego nie dowodzi o tej ścieżce, a reguła dopuszczająca ruch wychodzący, ale nie odpowiedź, nadal zawiedzie.

Statyczne przekierowanie portu przychodzącego nie jest automatycznie konieczne, gdy partner inicjuje, a translator utrzymuje stan. Staje się konieczne, gdy mapowanie jest niestabilne albo gdy coś na ścieżce agresywnie wygasa stan.

Przechwyć raz po obu stronach translatora; różnica w kapsułkowaniu jest od razu widoczna.

Krok 5: oddziel transport zewnętrzny od routingu wewnętrznego

Tunel, który się zestawia i nic nie przenosi, to problem routingu, nie NAT-T. Lokacje nadal potrzebują zgodnych selektorów ruchu, pasujących przestrzeni adresowych, reguł dostępu i ścieżki powrotnej dla sieci aplikacji. Niczego z tego nie zapewnia udana wymiana IKE.

Jeśli obie lokacje używają nakładających się zakresów prywatnych, tłumaczenie wewnątrz tunelu to osobny projekt z własnymi regułami. Nie przenumerowuj podsieci tylko dlatego, że zewnętrzna brama przypadkiem stoi za domowym routerem.

Zanim cokolwiek zmienisz, sklasyfikuj awarię według etapu i zachowaj tę klasyfikację w zgłoszeniu, aby następna osoba zaczęła tam, gdzie ty skończyłeś.