Proč připojení point-to-site potřebuje bránu Azure VPN založenou na směrování

Brána založená na zásadách vytváří tunel IPsec vybíraný selektory provozu a nemá rozhraní, kterému by předala klientské trasy. Připojení point-to-site je funkce směrování: brána vlastní fond klientských adres a do virtuální sítě instaluje trasy k těmto klientům. Právě kvůli tomuto nesouladu portál nenabízí možnost je přidat. Na stávající bráně nelze přepnout nic, co by rozhraní vytvořilo, takže změna je výměna, nikoli úprava konfigurace.

Pořadí je důležitější než jednotlivé kroky. Spleťte sled a výpadek spojení mezi lokalitami přesáhne údržbové okno.

Co brána založená na zásadách skutečně dělá

Brána založená na zásadách porovnává pakety se selektory provozu nakonfigurovanými na připojení a shody posílá do jednoho tunelu. Neexistuje tunelové rozhraní s adresou a ve virtuální síti se nikde neobjevuje trasa pro jednotlivého klienta. Směrovací tabulka prostě získá místní prefixy ukazující na bránu. Tento model stačí pro spojení mezi lokalitami se dvěma pevnými adresními prostory.

Brána založená na směrování funguje opačně: nabízí tunelové rozhraní a trasy určují, co do něj vstoupí. Připojení point-to-site a každý návrh, jehož sada protějšků se mění, závisí na existenci tohoto rozhraní.

Proč fond klientů toto rozhraní potřebuje

Když se notebook připojí, brána mu přidělí adresu z fondu point-to-site. Virtuální síť pak potřebuje trasu, která říká, že tato adresa je dosažitelná přes bránu. Bez tunelového rozhraní není trasu k čemu připojit.

Fond pochází z rozsahu, který určíte, a brána z něj přiděluje. Pokud se tento rozsah překrývá s místní sítí nebo s propojenou virtuální sítí, konflikt se objeví až po připojení klienta, což je špatný okamžik na jeho objevení. Fond rezervujte před začátkem migrace.

Ani typ není nastavení pro jednotlivé připojení. Jedna brána má jeden typ a každé připojení, které drží, se podle toho chová, takže smíšený návrh potřebuje druhou bránu, nikoli druhé připojení.

Typ je pevně daný při vytvoření

Microsoft uvádí, že bránu virtuální sítě nelze po nasazení změnit mezi založenou na zásadách a založenou na směrování. Neexistuje příkaz pro převod ani přepínač na portálu. Vytvoření druhé brány ve stejné podsíti také není náhradní řešení, protože Azure povoluje jednu bránu na virtuální síť. Migrace je proto odstranit, znovu postavit a znovu připojit.

Tím se rozhodnutí o SKU vtahuje do stejné stavby. Přechod na větší SKU později je další výměna brány s dalším výpadkem.

Jedna brána, jedna GatewaySubnet

Brána žije v podsíti s názvem GatewaySubnet a obsazuje ji jen jedna brána. Dimenzování této podsítě patří k přípravě, protože větší SKU potřebuje více adres a podsíť nelze později zmenšit. Před jakýmkoli zásahem zaznamenejte stávající nastavení spojení mezi lokalitami, sdílený klíč, bránu místní sítě a efektivní trasy. Pak okno berte jako výpadek, protože tunel mezi lokalitami zůstane vypnutý, dokud se nové připojení nenakonfiguruje.

Pořadí přestavby, které udrží výpadek ohraničený: vytvořte bránu založenou na směrování, znovu vytvořte spojení mezi lokalitami ke stejné bráně místní sítě, potvrďte tunel a jeden požadavek hostitel–hostitel a teprve potom přidejte point-to-site a vygenerujte nový klientský balíček.

Co výměna neopraví

Druhé omezení patří protějšku, nikoli Azure. Místní zařízení založené na zásadách dosáhne jen na virtuální síť, ke které se připojuje, a nemůže přes stejnou bránu procházet do jiných místních sítí ani jiných virtuálních sítí. Výměna strany Azure nemění to, co protějšek může vybrat.

Pokud je požadavkem skutečně tranzit mezi lokalitami, odpovědí je protější zařízení založené na směrování nebo topologie, v níž každé cílové místo končí samostatně. Vyřešte to dřív, než slíbíte termín, protože samotná výměna brány to nedodá.

Pořadí operací a kontrol

Každou schopnost ověřujte zvlášť. Nejprve stav tunelu mezi lokalitami a jeden požadavek hostitel–hostitel, potom připojení point-to-site a jeden soukromý prostředek, potom jakoukoli tranzitní cestu, kterou návrh tvrdí. Zelený stav brány dokazuje jen to, že se zvedla bezpečnostní asociace, a nic víc. Kontroly držte v tomto pořadí, aby selhání ukázalo na fázi, která ho zavedla.

Po každé změně topologie znovu vygenerujte klientské balíčky a fond držte mimo každý místní a propojený rozsah. Omezení a rozdíly mezi SKU jsou shrnuty v referenci nastavení Azure VPN Gateway.