Peering v Azure alebo VPN VNet–VNet? Rozhodnite pred smerovaním

Azure vám dáva najmenej dva spôsoby, ako prepojiť dve virtuálne siete, a nie sú to zameniteľné nastavenia toho istého objektu. Peering spája VNet-y po chrbtici Microsoftu bez brány; VPN VNet–VNet stavia vzťah IPsec medzi dve brány, ktoré nasadzujete, dimenzujete a sledujete. Rozhodnutie sa redukuje na tri podmienky, a ak na všetky tri neodpoviete skôr, než pridáte trasu, chystáte sa postaviť obchádzku pre model, ktorý ste si nikdy nevybrali.

Tri podmienky, ktoré rozhodujú o modeli

Prvá je, či niečo v požiadavke potrebuje hranicu IPsec, ktorú vlastníte a na ktorú môžete ukázať. Druhá je, či sú adresné priestory čisté a obe VNet-y sa majú len rozprávať medzi sebou. Tretia je, kto vlastní akúkoľvek tranzitnú cestu a účet za bránu. Odpovedajte v tomto poradí, pretože prvá môže peering vylúčiť, nech druhá vyzerá akokoľvek lákavo.

Obe modelom je spoločné tvrdé pravidlo adresovania: adresné priestory VNet-ov sa nesmú prekrývať. Ani peering, ani VPN VNet–VNet nie je podporovaný spôsob, ako urobiť dva totožné rozsahy jednoznačnými, a prekrytie vyžaduje návrh mapovania alebo prepracovanie, nie iný typ pripojenia.

Podmienka 1: potrebujete hranicu IPsec, ktorú vlastníte?

Peering prenáša prevádzku po súkromnej chrbtici Azure a pre samotné peered pripojenie nevyžaduje VPN bránu. To je tvrdenie o prenose, nie tvrdenie o šifrovaní, ktoré môžete dať audítorovi ako „používame IPsec“. Ak požiadavka menuje tunel konfigurovaný zákazníkom, konkrétnu politiku IKE alebo hranicu, ktorá končí na zariadení pod vašou kontrolou, peering to nesplní, nech je chrbtica akokoľvek súkromná.

VPN VNet–VNet túto hranicu poskytuje: dve brány, vzťah IPsec/IKE, zdieľané kľúče a celý prevádzkový povrch, ktorý k tomu patrí. Dedicujete stav tunela, kapacitu brány, limity SKU a monitorovanie, ktoré dokazuje, že tunel beží. To je správna odpoveď, keď sa požiadavka týka práve tejto hranice, opísanej v prehľade peeringu ako odlišný typ pripojenia.

Buďte rovnako opatrní v opačnom smere. „Potrebujeme šifrovanie medzi VNet-mi“ často splní vlastný TLS úlohy, a potom je brána nákladom bez požiadavky za sebou. Napíšte vetu, ktorú bude audítor čítať, skôr než zvolíte mechanizmus.

Podmienka 2: je topológia priama alebo musí niečo tranzitovať?

Peering nie je tranzitívny. Dve VNet-y peered do hubu tým nie sú prepojené navzájom, a trasa, ktorá vyzerá funkčne jedným smerom, je zvyčajne peering, ktorý dosiahol Connected len na jednej strane. Obe strany musia existovať a obe musia ukazovať Connected, a to je prvé, čo skontrolujete, keď prevádzka potichu zmizne.

Ak je požiadavkou dostupnosť lokálnej siete cez hub, tranzit brány je samostatný návrh s konkrétnymi rolami: hub vlastní bránu, peering spoke siete povoľuje tranzit brány a spoke musí povoliť preposielanú prevádzku. To sú vlastnosti peeringu, nie automatické dôsledky prepojenia VNet-ov:

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

Efektívna tabuľka trás je poctivá odpoveď na otázku „existuje cesta?“. Ukazuje typ ďalšieho skoku, ktorý platforma skutočne použije, takže peering, ktorý vyzerá nakonfigurovaný, ale nie je pripojený, sa prejaví ako chýbajúca alebo nesprávna trasa, nie ako záhada.

Podmienka 3: kto vlastní tranzitnú cestu a účet?

Každý ďalší skok má vlastníka. Pri peeringu nový VNet znamená novú dvojicu peeringov na oboch stranách a pre tranzit hub, ktorý ďalej preposiela prevádzku, a tabuľku trás, ktorá naň ďalej ukazuje. Pri VPN nový VNet znamená ďalšiu bránu alebo ďalšie pripojenie na existujúcej, s vlastným stropom kapacity, ktorý treba sledovať.

Náklad sleduje rovnaký tvar, ale nie rovnaké položky: poplatky za peering sú pripojenie a prenos údajov, zatiaľ čo VPN pridáva hodiny brány a vlastné poplatky za prenos. Porovnávajte súčet pre topológiu, ktorú budete skutočne rok prevádzkovať, vrátane druhého tunela a monitorovania, nie cenu jedného pripojenia dnes. Zahrňte prácu, ktorú nikto nefakturuje: niekto musí rotovať kľúče, sledovať stav tunela a odpovedať na poplach o tretej ráno, keď sa brána reštartuje. Práve táto položka zvyčajne rozhoduje spor, pretože je jediná, ktorá sa nikdy neobjaví v ponuke.

Čokoľvek si vyberiete, otestujte tri toky: zamýšľaný, odmietnutý, ktorý má zostať odmietnutý, a prípad obnovy, keď je brána hubu alebo peering mimo prevádzky. Model, ktorý vysvetľuje len šťastnú cestu, nebol overený, bol predvedený.

Overte voľbu proti jej vlastnému tvrdeniu

Napíšte jednu vetu, ktorá pomenuje model, hranicu a vlastníka, a potom skontrolujte, či nasadený stav jej zodpovedá. Pri peeringu to znamená oba stavy peeringu Connected, efektívna trasa ukazuje ďalší skok peeringu pre cieľový prefix a na ceste nie je žiadna brána. Pri VPN VNet–VNet to znamená obe pripojenia Connected, zhodné kľúče a politiky na oboch bránach a trasu, ktorej ďalší skok je brána virtuálnej siete.

Ak kontroly odporujú vete, najprv opravte vetu. Väčšina zmätku v týchto návrhoch pochádza z hybridu, ktorý nikto neopísal: peering pre podsieti úlohy, VPN pre jednu starú službu a tabuľka trás, ktorá potichu preferuje jednu z nich.