ExpressRoute plus VPN: které domény selhání pokrýváte?
Druhý tunel IPsec pokrývá koncový bod, ne okruh pod ním. Zmapujte každou doménu selhání a pak rozhodněte, zda je povolený nešifrovaný záložní přístup.
Tunel IPsec běžící přes privátní peering ExpressRoute přidává šifrování k transportu, který už existuje. Druhý tunel zlepšuje dostupnost koncového bodu a pro cestu operátora pod oběma nedělá vůbec nic. Tento rozdíl se snadno ztratí, když dashboardy ukazují dva zelené tunely a revize návrhu položí jinou otázku: které poruchy musí toto připojení přežít? Odpovězte nejdřív na to, pak počítejte tunely, protože počet zelených indikátorů je vlastností šifrovací vrstvy a počet domén selhání je vlastností celé cesty.
Začněte poruchami, ne zelenými tunely
Napište čtyři řádky, než cokoli nakreslíte: selhání jednoho koncového bodu VPN nebo instance peer, selhání jednoho místního routeru nebo připojení první míle, selhání sdílené cesty ExpressRoute a nedostupnost IPsec, zatímco privátní peering stále přenáší provoz. Každý řádek pojmenovává, co má návrh zachovat, a na každý odpovídá jiný mechanismus.
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft dokumentuje VPN typu site-to-site s privátními IP adresami přes privátní peering ExpressRoute a podporovanou koexistenci s připojeními site-to-site přes internet. Tato koexistence je jiný návrh spodní vrstvy a neobjeví se jen proto, že jste přidali další koncový bod privátního tunelu.
Doména selhání 1: koncový bod VPN
Dva tunely na jedné bráně jsou obvykle páry active-active, které končí na stejném prostředku na straně Azure. Chrání před problémem jednoho tunelu nebo instance a nechrání před tím, že tento prostředek bude nedostupný, překonfigurovaný nebo bez kapacity. Redundance koncového bodu znamená druhý podporovaný koncový bod s vlastní cestou a vlastní konfigurací plus trasu, která se k němu dostane.
Ověřte, co jste skutečně nasadili, a ne co říká diagram, protože portál tyto prostředky seskupuje způsobem, který skrývá jejich vztah:
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'Pokud oba tunely míří na jednu bránu s jednou veřejnou IP, máte redundanci koncového bodu zvláštního a omezeného druhu. Může to být přesně to, co požadavek žádá, a takto to má být řečeno, místo aby se to popisovalo jako redundantní připojení.
Doména selhání 2: místní cesta a operátor
Pod šifrováním leží fyzická a obchodní realita: zařízení na okraji zákazníka, propojení, síť poskytovatele a lokalita peeringu. pokyny k dostupnosti ExpressRoute výslovně uvádějí, že redundance end-to-end zahrnuje segmenty zákazníka i poskytovatele služeb, nejen stranu Microsoftu. Dvě logické cesty, které sdílejí router, napájení nebo připojení první míle, stále sdílejí tuto závislost.
Tady návrh obvykle neuspěje u poctivé revize. Dva okruhy od stejného poskytovatele, končící ve stejné budově, na zařízení ze stejné objednávky, nejsou dvě domény selhání. Jsou to jedna doména selhání se dvěma fakturami.
Položte otázku operátorovi písemně: které z těchto cest se rozcházejí, kde, a jaké je dokumentované chování, když sdílený segment selže? Ústní ujištění během návrhového hovoru nepřežije výpadek, na který navrhujete.
Doména selhání 3: trasa, která přežije bez IPsec
Privátní peering a IPsec mohou nabídnout konkurenční trasy ke stejnému prefixu aplikace. Pokud chráněná trasa zmizí, přeživší přímá trasa ExpressRoute může být stále použitelná, bez šifrovací vrstvy, kterou tunel poskytoval. Zda je to přijatelné, je rozhodnutí politiky, a právě toto rozhodnutí se nejčastěji nechává implicitní.
Požadavky na šifrování a požadavky na dostupnost zde mohou skutečně kolidovat. „Každá přeživší trasa se počítá jako úspěch“ je tvrzení o dostupnosti, které potichu odpovídá na otázku šifrování „ne“. Zapište, co vítězí, pro které prefixy a kdo to schválil.
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o tablePorovnejte naučené trasy s prefixy, které jste očekávali. Záložní cesta, která nese malou administrativní zátěž, může být pro tuto zátěž naprosto dostačující a daleko od kapacity, kterou produkční poptávka potřebuje, takže si poznamenejte předpoklad kapacity vedle trasy.
Zaznamenejte tři samostatné řádky, ne jeden verdikt
Držte redundanci koncového bodu, redundanci transportu a obnovu po havárii jako samostatné položky v návrhovém záznamu, každou s vlastním mechanismem, vlastním ověřením a vlastním vlastníkem. Když se revize incidentu ptá, proč připojení přežilo restart brány, ale ne přerušení vlákna, tři řádky odpoví jednou větou; jedno zaškrtávací pole „redundantní“ to nedokáže.
Pak otestujte řádky, které lze otestovat levně. Vypněte jeden tunel a potvrďte, že provoz se přesune a znovu zašifruje. Stáhněte jednu trasu a potvrďte, že přeživší cesta je ta zamýšlená, a pak potvrďte, zda je stále šifrovaná. Zdokumentujte poruchy, které jste nedokázali simulovat, protože netestovaný řádek je předpoklad a měl by tak být označen.
Užitečným výstupem je krátká tabulka plus věta na řádek. Pokud řádek nemá mechanismus, to je zjištění, a objevit ho při revizi návrhu je mnohem levnější než během výpadku operátora, který by oba tunely nikdy nepřežily.