Peering v Azure, nebo VPN VNet–VNet? Rozhodněte se před směrováním

Azure vám dává nejméně dva způsoby, jak propojit dvě virtuální sítě, a nejsou to zaměnitelná nastavení téhož objektu. Peering spojuje sítě VNet po páteři Microsoftu bez brány; VPN VNet–VNet staví vztah IPsec mezi dvě brány, které nasazujete, dimenzujete a sledujete. Rozhodnutí se redukuje na tři podmínky, a pokud na všechny tři neumíte odpovědět dřív, než přidáte trasu, chystáte se postavit obejití modelu, který jste si nikdy nevybrali.

Tři podmínky, které rozhodují o modelu

První je, zda něco v požadavku potřebuje hranici IPsec, kterou vlastníte a můžete na ni ukázat. Druhá je, zda jsou adresní prostory čisté a obě sítě VNet spolu mají jen komunikovat. Třetí je, kdo vlastní případnou tranzitní cestu a účet za bránu. Odpovídejte v tomto pořadí, protože první může peering vyloučit, ať už druhá vypadá jakkoli lákavě.

Oběma modelům je společností tvrdé pravidlo adresování: adresní prostory VNet se nesmí překrývat. Ani peering, ani VPN VNet–VNet není podporovaný způsob, jak udělat dva totožné rozsahy jednoznačnými, a překryv vyžaduje návrh mapování nebo přepracování, ne jiný typ připojení.

Podmínka 1: potřebujete hranici IPsec, kterou vlastníte?

Peering přenáší provoz po privátní páteři Azure a pro samotné peered připojení nevyžaduje VPN bránu. To je tvrzení o přenosu, ne tvrzení o šifrování, které můžete dát auditorovi jako „používáme IPsec“. Pokud požadavek jmenuje tunel konfigurovaný zákazníkem, konkrétní zásadu IKE nebo hranici, která končí na zařízení pod vaší kontrolou, peering to nesplní, ať je páteř sebevíc privátní.

VPN VNet–VNet tuto hranici skutečně poskytuje: dvě brány, vztah IPsec/IKE, sdílené klíče a celý provozní povrch, který k tomu patří. Dědíte stav tunelu, kapacitu brány, limity SKU a monitorování, které dokazuje, že tunel běží. To je správná odpověď, když se požadavek týká právě této hranice, popsané v přehledu peeringu jako odlišný typ připojení.

Buďte stejně opatrní v opačném směru. „Potřebujeme šifrování mezi sítěmi VNet“ často splní vlastní TLS úlohy, a pak je brána nákladem bez požadavku za sebou. Napište větu, kterou bude auditor číst, dřív než zvolíte mechanismus.

Podmínka 2: je topologie přímá, nebo musí něco tranzitovat?

Peering není tranzitivní. Dvě sítě VNet peered do hubu tím nejsou propojené navzájem, a trasa, která vypadá funkčně jedním směrem, je obvykle peering, který dosáhl Connected jen na jedné straně. Obě strany musí existovat a obě musí ukazovat Connected, což je první věc, kterou zkontrolujete, když provoz tiše zmizí.

Pokud je požadavkem dostupnost lokální sítě přes hub, tranzit brány je samostatný návrh s konkrétními rolemi: hub vlastní bránu, peering spoke sítě povoluje tranzit brány a spoke musí povolit předávaný provoz. To jsou vlastnosti peeringu, ne automatické důsledky propojení sítí VNet:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Efektivní tabulka tras je poctivá odpověď na otázku „existuje cesta?“. Ukazuje typ dalšího skoku, který platforma skutečně použije, takže peering, který vypadá nakonfigurovaný, ale není připojený, se projeví jako chybějící nebo špatná trasa, ne jako záhada.

Podmínka 3: kdo vlastní tranzitní cestu a účet?

Každý další skok má vlastníka. U peeringu nová síť VNet znamená novou dvojici peeringů na obou stranách a pro tranzit hub, který dál předává provoz, a tabulku tras, která na něj dál ukazuje. U VPN nová síť VNet znamená další bránu nebo další připojení na existující, s vlastním stropem kapacity, který je třeba hlídat.

Náklad sleduje stejný tvar, ale ne stejné položky: poplatky za peering jsou připojení a přenos dat, zatímco VPN přidává hodiny brány a vlastní poplatky za přenos. Porovnávejte součet pro topologii, kterou budete skutečně rok provozovat, včetně druhého tunelu a monitorování, ne cenu jednoho připojení dnes. Zahrňte práci, kterou nikdo nefakturuje: někdo musí rotovat klíče, hlídat stav tunelu a odpovídat na poplach ve tři ráno, když se brána restartuje. Právě tato položka obvykle rozhoduje spor, protože je jediná, která se nikdy neobjeví v nabídce.

Ať vyberete cokoli, otestujte tři toky: zamýšlený, odmítnutý, který má zůstat odmítnutý, a případ obnovy, kdy je brána hubu nebo peering mimo provoz. Model, který vysvětluje jen šťastnou cestu, nebyl ověřen, byl předveden.

Ověřte volbu proti jejímu vlastnímu tvrzení

Napište jednu větu, která pojmenuje model, hranici a vlastníka, a pak zkontrolujte, že nasazený stav jí odpovídá. U peeringu to znamená oba stavy peeringu Connected, efektivní trasu ukazující další skok peeringu pro cílový prefix a žádnou bránu na cestě. U VPN VNet–VNet to znamená obě připojení Connected, shodné klíče a zásady na obou bránách a trasu, jejíž další skok je brána virtuální sítě.

Pokud kontroly odporují větě, opravte nejdřív větu. Většina zmatku v těchto návrzích pochází z hybridu, který nikdo nepopsal: peering pro podsíť úlohy, VPN pro jednu starou službu a tabulka tras, která jedné z nich tiše dává přednost.