NAT w Azure VPN nie naprawia nakładających się adresów VNet
Dwie sieci VNet z tym samym zakresem prywatnym nie połączą się tylko dlatego, że istnieje NAT. Najpierw sprawdź typ połączenia, potem przenumeruj lub posiadaj alias tłumaczenia.
Obie sieci VNet używają 10.40.1.0/24, tunele wstają i nic nie działa. Dodanie drugiej bramy VPN tego nie zmienia, podobnie jak niższa metryka trasy, bo problem nie leży w wyborze ścieżki. Dwa obciążenia odpowiadające na ten sam adres prywatny pozostawiają każdy pakiet z niejednoznacznym celem i niepodlegającą weryfikacji drogą powrotną. Zanim zaplanujesz jakiekolwiek tłumaczenie, ustal, jaki typ połączenia faktycznie utworzyłeś, ponieważ ten jeden wybór rozstrzyga, czy funkcja NAT w Azure jest w ogóle dostępna.
Co ten objaw naprawdę mówi
Gdy host w VNet A wysyła do 10.40.1.10, tabela routingu może go jedynie gdzieś skierować. Jeśli VNet B również zawiera 10.40.1.10, ten adres nie jest celem, który ścieżka potrafi rozróżnić; to jeden adres z dwoma właścicielami.
Druga brama, którą zwykle się wdraża, nie pomaga. Daje kolejny tunel, a nie kolejny adres, a zduplikowany zakres podróżuje wewnątrz tunelu bez zmian. Podwaja też konfigurację, którą trzeba utrzymywać spójną. Czego nie potrafi, to sprawić, by jeden adres oznaczał dwa hosty.
Zmiana publicznych adresów partnerów VPN też nic nie daje. Te adresy identyfikują końce tunelu, podczas gdy kolizja tkwi w zakresie prywatnym przenoszonym w środku.
Typ połączenia decyduje, czy NAT jest dostępny
Azure VPN Gateway rzeczywiście ma możliwość NAT i jest ona udokumentowana dla opartych na trasach połączeń IPsec między lokacjami w określonych SKU bramy. Ta sama dokumentacja wyklucza połączenia VNet-to-VNet i point-to-site, więc funkcja nie jest polem wyboru, które pojawia się przy każdej relacji bramy.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Natywne VNet-to-VNet również wymaga, aby zakresy VNet i sieci lokalnej nie nakładały się od początku, co jest spójne z tym wykluczeniem. Peering VNet nie jest obejściem nakładania się z tego samego powodu.
Istnieje obsługiwana alternatywa, którą ludzie mylą z typem natywnym: zamodeluj drugą sieć VNet jako sieć lokalną i połącz ją jako połączenie lokacja-lokacja. To inny zasób i inny projekt, więc zmienione nazwowo połączenie traktuj jako zmianę do walidacji, a nie zwykłą zmianę nazwy.
Przenumeruj albo tłumacz za pomocą czegoś, co posiada alias
Jeśli obie sieci VNet są twoje, porównaj planowane przenumerowanie z bieżącym kosztem tłumaczenia. Przenumerowanie dotyka konfiguracji aplikacji, rekordów DNS, reguł bezpieczeństwa i każdego istniejącego połączenia, ale zostawia sieć, która potem czyta się normalnie. Rób to po jednej podsieci, ze zmianą DNS na końcu. W połowie przenumerowany zakres jest gorszy niż każda z opcji, bo wtedy oba prefiksy wyglądają wiarygodnie dla tego, kto następny przeczyta tabelę.
Tam, gdzie przenumerowanie jest niepraktyczne, użyj projektu tłumaczonego z rzeczywistym właścicielem aliasu. Wywołujący w VNet A mogą docierać do 10.40.1.10 w VNet B jako 10.140.1.10, ale ten alias wymaga urządzenia, które tłumaczy, trasy do niego i pasującego zachowania dla odpowiedzi. Adres dodany tylko do DNS nie jest tłumaczeniem.
Zapisz oba zakresy w obu kierunkach: co wybiera wywołujący, co widzi cel jako źródło i która strona może inicjować. Własne reguły NAT Azure zawierają tłumaczenie odwrotne dla swoich mapowań SNAT, więc nie piszesz ręcznie pasującej reguły DNAT, ale ta wygoda kończy się na typach połączeń, które funkcja obsługuje.
Co nie zadziała
Trasa zdefiniowana przez użytkownika ani metryka trasy nie mogą wytworzyć brakującego rozróżnienia adresów. Oba działają na celu, który wciąż jest niejednoznaczny, a pakiet trafia do następnego przeskoku preferowanego przez tabelę.
Dodanie zduplikowanego zakresu do tabeli tras jako bardziej szczegółowego prefiksu przesuwa niejednoznaczność tylko o krok. Zwykle psuje też kierunek przeciwny, w którym odpowiedź ma teraz dwa prawdopodobne źródła.
Zaakceptuj projekt z ruchem w obu kierunkach
Udowodnij projekt świeżą dozwoloną operacją z każdej strony, a nie statusem tunelu. Połączony tunel IPsec mówi, że partnerzy zgadzają się co do kryptografii; nie mówi nic o tym, czy cele stały się rozróżnialne.
Potem uruchom ścieżki zabronione: adres, który powinien pozostać nieosiągalny, oraz usługę, którą polityka powinna blokować. Jeśli oba nadal się udają, tłumaczenie jest szersze, niż zakładał projekt.
Zakończ faktami, które później wyjaśnią konfigurację: zakres pierwotny, zakres prezentowany, urządzenie tłumaczące i kierunek, w którym każda strona może inicjować. Jeśli któregoś brakuje, następny inżynier dziedziczy sieć, w której dwa hosty dzielą nazwę i nikt nie pamięta, dlaczego jeden z nich odpowiada.