Proč přidání prefixu Azure VPN odpojí připojení

Prefix přidaný ke špatnému objektu Azure vytvoří připojení, které hlásí Connected a nic nepředává, což je nejdražší druh chyby v tomto stacku. Zapojeny jsou tři prostředky a jen jeden z nich vlastní vzdálený adresní prostor: brána virtuální sítě, brána místní sítě, která popisuje vzdálenou stranu, a připojení, které je spojuje. Prefix patří bráně místní sítě, připojení se musí znovu vytvořit, aby se změna projevila, a samotná brána obvykle zůstává nedotčena. Pořadí je nepřekročitelné a portál ukazuje jen část z něj.

Tři objekty, z nichž jeden drží prefix

Adresní prostor virtuální sítě odpovídá na jinou otázku: co žije uvnitř Azure. Přidání vzdáleného prefixu tam nevede provoz k němu, jen rozšiřuje prostor, o kterém si platforma myslí, že ho vlastní, což se může střetnout se skutečným vzdáleným rozsahem. Brána místní sítě je objekt, který drží vzdálené prefixy, a připojení odkazuje na obě brány plus předem sdílený klíč.

Je tu ještě třetí rezervace, kterou je třeba mít na paměti. GatewaySubnet hostuje spravované instance brány, musí mít přesně tento název a u ne-Basic SKU se očekává, že bude alespoň /27.

Nic jiného do té podsítě nepatří a změna prefixu nemá důvod se jí dotýkat. Prefix, který v bráně místní sítě chybí, je nedosažitelný bez ohledu na to, co říká stav připojení, protože brána nabízí jen ty prefixy, o kterých byla informována při vyjednávání tunelu. Proto je symptom asymetrický: tunel je nahoře, přidružení zabezpečení je v pořádku a jedna podsíť se nikdy neobjeví v selektorech provozu. Pokud jeden vzdálený rozsah chybí, zatímco sousedé fungují, přestaňte se dívat na tunel a přečtěte si bránu místní sítě.

Proč se odstraňuje právě připojení

Objekt připojení fixuje vyjednanou konfiguraci po celou dobu své životnosti. Proto dokumentovaný postup nejprve odstraní připojení, aktualizuje bránu místní sítě a poté připojení znovu vytvoří se stejným sdíleným klíčem. Instance brány se pro změnu pouze prefixu nepřestavují, což omezuje výpadek na rozebrání připojení místo na nové nasazení brány.

Toto smazání je výpadek, tak k němu přistupujte jako k plánované změně se začátkem a očekávaným koncem, ne jako k rychlé úpravě. V PowerShellu je sled krátký: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, pak Set-AzLocalNetworkGateway s novým -AddressPrefix polem, pak New-AzVirtualNetworkGatewayConnection se stejným -SharedKey a stejnými branami. Opětovné použití klíče je důležité, protože vzdálená strana se nepřekonfigurovává a nový klíč znamená koordinaci s tím, kdo vlastní vzdálené zařízení. Pokud toto zařízení provozuje jiný tým, dohodněte s ním okno, než cokoli odstraníte.

Kdy je nutné přestavět samotnou bránu

Druhá odpověď, která kolem tohoto problému koluje, říká, že brána musí být znovu vytvořena a klíč znovu vyměněn. To platí pro jinou sadu operací: změnu typu brány nebo SKU, přechod mezi point-to-site a site-to-site nebo opravu brány, jejíž vlastní konfigurace je špatná. Takové změny skutečně mění prostředek brány, takže přestavba je opravdu nutná.

Bráně vytvořené pro point-to-site nelze jednoduše předat připojení site-to-site. Konfigurace point-to-site se musí odstranit a brána znovu vytvořit, což také vytvoří nový sdílený klíč a nový klientský balíček.

Balíček point-to-site si zaslouží vlastní poznámku, protože vyprší. Portál generuje soubor s krátkou životností, takže praktický přístup je stáhnout ho jednou a distribuovat spolu s klientským certifikátem, místo abyste uživatelům posílali odkaz na portál, který bude mrtvý, než na něj kliknou. Pro otázku prefixu nic z toho neplatí. Držet oba postupy oddělené je celá disciplína: prefixy jsou změna na úrovni připojení a vlastnosti brány jsou změna na úrovni brány.

Čtěte stav, ne odznak portálu

Čtěte stav z prostředku, ne z odznaku na portálu. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 vrací ConnectionStatus spolu s počítadly příchozích a odchozích bajtů, a právě počítadla oddělují tunel, který je připojený a nic nenese, od toho, který se nikdy neustavil.

Počítadla, která přestanou růst uprostřed přenosu, ukazují na cestu, ne na ověřování. Počítadla, která se vůbec nehýbou, ukazují na sadu prefixů nebo sdílený klíč.

Časovače vysvětlují třídu odpojení, která se mylně přičítají VPN. Nástroj pro vyrovnávání zatížení Azure zavírá neaktivní toky po svém nastaveném časovém limitu, ve výchozím nastavení čtyři minuty, když se psaly tyto poznámky, a lze jej zvyšovat, takže server OpenVPN na VM bez keepalive může spadnout každých několik minut, zatímco všechno ostatní vypadá zdravě. Brána, kterou platforma cyklicky restartuje, může také přerušit připojení VNet k Web App, a tato porucha je na straně platformy, ne v konfiguraci klienta. Vodítkem je, zda odpojení sleduje pevný interval, nebo změnu, kterou jste provedli.

Držte tři objekty a jejich hodnoty v jednom záznamu: adresní prostor virtuální sítě, seznam prefixů brány místní sítě a odkaz na sdílený klíč připojení. článek o PowerShellu pro site-to-site dokumentuje příkazy brány místní sítě a pořadí, do kterého patří. Porovnávat změnu prefixu s pamětí je způsob, jak dvakrát přestavět fungující tunel.

Poté ověřte v pořadí, v jakém jste měnili: brána místní sítě zobrazuje nový seznam prefixů, připojení je zpět ve stavu Connected a počítadla se hýbou, když odešlete provoz na hostitele v novém rozsahu. Pokud třetí krok selže, zatímco první dva projdou, vzdálená strana nepřijala nový selektor provozu a vzdálené zařízení potřebuje odpovídající položku fáze 2. To je rozhovor s druhým koncem tunelu, ne další změna v Azure.