Konfiguracja GatewaySubnet w Azure: zarezerwuj go przed bramą

Otwórz sieć wirtualną w portalu i sprawdź przestrzeń adresową, zanim dotkniesz bloku podsieci. Jeśli to /24 jest już podzielone na podsieci obciążeń i nic nie zostało wolne, nie ma miejsca na rezerwację /27 i skończysz albo na ponownym podziale, albo na poszerzeniu VNet, co jest inną zmianą z innym przeglądem. Najpierw ustal przestrzeń, potem utwórz podsieć.

Ta kolejność ma znaczenie, bo podsieć bramy nie jest podsiecią obciążenia ze specjalną nazwą. To rezerwacja adresów dla zarządzanych wystąpień bramy, a Azure odrzuci bramę, jeśli rezerwacja jest błędna.

Zacznij od przestrzeni adresowej

Zapisz prefiks VNet, podsieci obciążeń i rezerwację bramy w jednym wierszu, zanim cokolwiek wpiszesz. VNet w 10.60.0.0/16 ma miejsce; wybierz zakres na końcu, aby wzrost obciążeń pozostał ciągły.

Na przykład 10.60.255.192/26 zostawia 64 adresy dla bramy, a obciążenia pozostają w 10.60.0.0/20. To przykład planowania adresów, a nie obietnica rozmiaru. Microsoft obecnie wymaga /27 lub większego dla bram VPN innych niż Basic, gdzie większy oznacza więcej adresów: /26 daje 64, a /28 daje 16. Zaokrąglaj w górę, nigdy w dół, dopóki plan adresów jeszcze się zmienia.

Utwórz podsieć z dokładną nazwą

W portalu dodaj podsieć i wpisz nazwę GatewaySubnet dokładnie, wielkie G i wielkie S, bez spacji i sufiksu. Azure porównuje ten ciąg, więc Gateway-Subnet lub gateway tworzy podsieć, której usługa bramy nie użyje.

Ten sam krok z CLI, łatwiejszy do wpisania w przegląd:

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

Zostaw podsieć pustą. Żadnej VM, żadnego prywatnego punktu końcowego, żadnego delegowania usługi. Jeśli coś już tam mieszka, wdrożenie się nie powiedzie, a błąd rzadko nazywa przeszkadzający zasób, więc przed startem sprawdź listę zasobów podsieci.

Trzymaj zarządzaną podsieć wolną od reguł obciążeń

Nie dołączaj sieciowej grupy zabezpieczeń do tej podsieci; Microsoft oznacza to jako nieobsługiwane. Nie kojarz tabeli tras, której trasa domyślna wysyła 0.0.0.0/0 gdzieś dalej, bo to może zepsuć działanie bramy, i pozostaw włączone propagowanie tras bramy.

Ograniczenia dostępu, których naprawdę chciałeś, umieść na podsieci obciążenia albo na granicy inspekcji. Traktowanie GatewaySubnet jak zwykłej podsieci to błąd, który daje bramę wdrażającą się czysto, a potem nieprzepuszczającą żadnego ruchu.

Wymuszony tunel ma własny udokumentowany projekt. Improwizowana trasa domyślna na podsieci bramy to nie to.

Sprawdź zależności, których portal nie pokazuje

Zanim naciśniesz utwórz, przejdź listę: dokładna nazwa, prefiks w przestrzeni VNet, brak nakładania się z zakresami lokalnymi, brak zasobów obciążeń w środku, brak NSG i brak tabeli tras z trasą domyślną. Każdy z tych punktów psuł realne wdrożenie. Potem potwierdź szerszy projekt: lokalna brama sieciowa po stronie lokalnej, przestrzenie adresowe, które zamierzasz routować, i czy planowany jest tryb aktywny-aktywny lub współistnienie. Te wybory zmieniają rozmowę o rozmiarze i znacznie taniej jest je rozstrzygnąć teraz.

Dokumentacja ustawień bramy Azure to strona, na którą się powołujesz, gdy ktoś pyta, dlaczego podsieć nie może pomieścić VM.

Jeśli brama już istnieje

Zmiana rozmiaru lub wymiana podsieci bramy nie jest edycją maski. Najpierw sprawdź obsługiwaną procedurę zmiany dla SKU i generacji bramy, a potem wypisz obiekty zależne: połączenia, publiczne adresy IP, routing i wszelkie wymagania odzyskiwania.

Jeśli procedura wymaga odtworzenia bramy, zaplanuj to jako migrację usługi z oknem i wycofaniem. Zapisz wybraną rezerwację, powód rozmiaru i reguły, których celowo nie dołączyłeś, aby następny recenzent nie naprawił pustej podsieci, dodając NSG.