Dlaczego połączenie punkt-lokalizacja wymaga bramy Azure VPN opartej na trasach

Brama oparta na zasadach buduje tunel IPsec wybierany przez selektory ruchu i nie ma interfejsu, któremu można przekazać trasy klientów. Połączenie punkt-lokalizacja jest funkcją routingu: brama posiada pulę adresów klientów i instaluje trasy do tych klientów w sieci wirtualnej. Ta niezgodność jest powodem, dla którego portal nie pokazuje żadnej opcji dodania jej. Nic w istniejącej bramie nie da się przełączyć, aby utworzyć interfejs, więc zmiana jest wymianą, a nie edycją konfiguracji.

Kolejność jest ważniejsza niż poszczególne kroki. Jeśli kolejność będzie błędna, przerwa między lokacjami przekroczy okno konserwacji.

Co naprawdę robi brama oparta na zasadach

Brama oparta na zasadach dopasowuje pakiety do selektorów ruchu skonfigurowanych na połączeniu i wysyła dopasowania do jednego tunelu. Nie ma interfejsu tunelu z adresem i nigdzie w sieci wirtualnej nie pojawia się trasa dla pojedynczego klienta. Tabela tras po prostu otrzymuje lokalne prefiksy wskazujące na bramę. Ten model wystarcza do połączenia między lokacjami między dwiema stałymi przestrzeniami adresowymi.

Brama oparta na trasach działa odwrotnie: udostępnia interfejs tunelu, a trasy decydują, co do niego wchodzi. Połączenie punkt-lokalizacja i każdy projekt, w którym zmienia się zbiór partnerów, zależą od istnienia tego interfejsu.

Dlaczego pula klientów potrzebuje tego interfejsu

Gdy laptop się łączy, brama przydziela mu adres z puli punkt-lokalizacja. Sieć wirtualna potrzebuje wtedy trasy mówiącej, że ten adres jest osiągalny przez bramę. Bez interfejsu tunelu nie ma do czego podpiąć tej trasy.

Pula pochodzi z zakresu, który wyznaczasz, a brama przydziela z niego adresy. Jeśli ten zakres nakłada się na sieć lokalną lub sieć wirtualną połączoną przez peering, konflikt ujawnia się dopiero po połączeniu klienta, co jest złym momentem na jego odkrycie. Zarezerwuj pulę przed rozpoczęciem migracji.

Typ też nie jest ustawieniem dla pojedynczego połączenia. Jedna brama ma jeden typ i każde połączenie, które utrzymuje, zachowuje się odpowiednio, więc projekt mieszany wymaga drugiej bramy, a nie drugiego połączenia.

Typ jest ustalany przy tworzeniu

Microsoft podaje, że bramy sieci wirtualnej nie można po wdrożeniu zmienić między opartą na zasadach a opartą na trasach. Nie ma polecenia konwersji ani przełącznika w portalu. Utworzenie drugiej bramy w tej samej podsieci też nie jest obejściem, ponieważ Azure zezwala na jedną bramę na sieć wirtualną. Migracja to więc usunięcie, odtworzenie i ponowne połączenie.

To włącza też decyzję o SKU do tej samej budowy. Przejście na większą SKU później to kolejna wymiana bramy z kolejną przerwą.

Jedna brama, jedna GatewaySubnet

Brama mieszka w podsieci o nazwie GatewaySubnet i tylko jedna brama ją zajmuje. Dobór rozmiaru tej podsieci należy do przygotowania, ponieważ większa SKU wymaga więcej adresów, a podsieci nie można później zmniejszyć. Zapisz bieżące ustawienia między lokacjami, klucz współdzielony, bramę sieci lokalnej i efektywne trasy, zanim czegokolwiek dotkniesz. Następnie potraktuj okno jako przerwę, ponieważ tunel między lokacjami pozostaje wyłączony, dopóki nowe połączenie nie zostanie skonfigurowane.

Kolejność odbudowy, która ogranicza przerwę: utwórz bramę opartą na trasach, odtwórz połączenie między lokacjami do tej samej bramy sieci lokalnej, potwierdź tunel i jedno żądanie host-host, a dopiero potem dodaj punkt-lokalizację i wygeneruj nowy pakiet klienta.

Czego wymiana nie naprawia

Drugie ograniczenie należy do partnera, a nie do Azure. Lokalne urządzenie oparte na zasadach może dotrzeć tylko do sieci wirtualnej, z którą się łączy, i nie może przechodzić do innych sieci lokalnych ani innych sieci wirtualnych przez tę samą bramę. Wymiana strony Azure nie zmienia tego, co partner może wybrać.

Jeśli wymaganiem jest naprawdę tranzyt między lokacjami, odpowiedzią jest partnerskie urządzenie oparte na trasach albo topologia, w której każde miejsce docelowe kończy się osobno. Rozstrzygnij to, zanim obiecasz termin, ponieważ sama wymiana bramy tego nie dostarczy.

Kolejność operacji i kontroli

Sprawdzaj każdą możliwość osobno. Najpierw stan tunelu między lokacjami i jedno żądanie host-host, potem połączenie punkt-lokalizacja i jeden prywatny zasób, potem każdą ścieżkę tranzytu, którą deklaruje projekt. Zielony stan bramy dowodzi tylko, że asocjacja zabezpieczeń została nawiązana, i niczego więcej. Trzymaj kontrole w tej kolejności, aby awaria wskazywała etap, który ją wprowadził.

Po każdej zmianie topologii wygeneruj ponownie pakiety klienta i trzymaj pulę z dala od każdego zakresu lokalnego i połączonego przez peering. Ograniczenia i różnice między SKU są zebrane w dokumentacji ustawień Azure VPN Gateway.