Azure-peering vagy VNet–VNet VPN? Döntsön az útválasztás előtt

Az Azure legalább két módot ad két virtuális hálózat összekapcsolására, és ezek nem felcserélhető beállítások ugyanazon az objektumon. A peering átjáró nélkül kapcsolja össze a VNeteket a Microsoft gerinchálózatán; a VNet–VNet VPN IPsec-kapcsolatot helyez két átjáró közé, amelyeket Ön telepít, méretez és felügyel. A döntés három feltételen múlik, és ha nem tud mindháromra válaszolni, mielőtt útvonalat ad hozzá, éppen egy olyan modell megkerülését építi, amelyet soha nem választott.

Három feltétel, amely eldönti a modellt

Az első, hogy a követelményben van-e olyan elem, amelyhez az Önéhez tartozó, megmutatható IPsec-határ kell. A második, hogy tiszták-e a címterek, és a két VNetnek csak egymással kell-e beszélnie. A harmadik, hogy kié bármely tranzitútvonal és az átjárószámla. Ebben a sorrendben válaszoljon, mert az első kizárhatja a peeringet, bármennyire vonzó is a második.

Ami mindkét modellben közös, az a szigorú címzési szabály: a VNetek címtartományai nem fedhetik át egymást. Sem a peering, sem a VNet–VNet VPN nem támogatott módja annak, hogy két azonos tartomány egyértelmű legyen, és az átfedés leképezési tervet vagy újratervezést igényel, nem más kapcsolattípust.

1. feltétel: kell-e az Önéhez tartozó IPsec-határ?

A peering az Azure privát gerinchálózatán szállítja a forgalmat, és magához a peered kapcsolathoz nem kell VPN-átjáró. Ez szállítási állítás, nem titkosítási állítás, amelyet odaadhat egy auditornak úgy, hogy «IPsecet futtatunk». Ha a követelmény ügyfél által konfigurált alagutat, meghatározott IKE-szabályt vagy az Ön által ellenőrzött eszközön végződő határt nevez meg, a peering nem teljesíti, bármennyire privát a gerinchálózat.

A VNet–VNet VPN megadja ezt a határt: két átjáró, IPsec/IKE kapcsolat, megosztott kulcsok és a teljes operatív felület, amely ezzel jár. Ön örökli az alagút állapotát, az átjáró kapacitását, az SKU-korlátokat és azt a felügyeletet, amely bizonyítja, hogy az alagút él. Ez a helyes válasz, amikor a követelmény éppen erről a határról szól, amelyet a peering áttekintése a peeringtől eltérő kapcsolattípusként ír le.

Legyen ugyanilyen óvatos a másik irányban. A «titkosítás kell a VNetek között» igényt gyakran a munkaterhelés saját TLS-e elégíti ki, és akkor az átjáró mögöttes követelmény nélküli költség. Írja le azt a mondatot, amelyet az auditor olvasni fog, mielőtt a mechanizmust választja.

2. feltétel: közvetlen a topológia, vagy valaminek tranzitálnia kell?

A peering nem tranzitív. Két hubhoz peerelt VNet ettől nem kapcsolódik egymáshoz, és az egy irányban működőnek tűnő útvonal általában olyan peering, amely csak az egyik oldalon érte el a Connected állapotot. Mindkét oldalnak léteznie kell, és mindkettőnek Connectedet kell mutatnia, és ez az első, amit ellenőriz, amikor a forgalom csendben eltűnik.

Ha a követelmény a helyszíni hálózat elérése hubon keresztül, az átjárótranzit külön terv meghatározott szerepekkel: a hub birtokolja az átjárót, a spoke peeringje engedélyezi az átjárótranzitot, és a spokénak engedélyeznie kell a továbbított forgalmat. Ezek a peering tulajdonságai, nem a VNetek összekapcsolásának automatikus következményei:

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

A tényleges útvonaltábla őszinte válasz arra, hogy «létezik-e az útvonal?». Megmutatja a következő ugrás típusát, amelyet a platform valóban használni fog, ezért a konfiguráltnak tűnő, de nem csatlakoztatott peering hiányzó vagy hibás útvonalként jelenik meg, nem rejtélyként.

3. feltétel: kié a tranzitútvonal és a számla?

Minden további ugrásnak van tulajdonosa. Peeringnél az új VNet új peeringpárt jelent mindkét oldalon, a tranzithoz pedig egy hubot, amely továbbra is továbbítja a forgalmat, és egy útvonaltáblát, amely továbbra is rá mutat. VPN-nél az új VNet egy másik átjárót vagy egy másik kapcsolatot jelent egy meglévőn, saját figyelendő kapacitásplafonnal.

A költség ugyanazt a formát követi, de nem ugyanazokat a tételeket: a peering díjai a kapcsolat és az adatátvitel, míg a VPN átjáróórákat és saját átviteli díjakat ad hozzá. Hasonlítsa össze a valóban egy évig üzemeltetett topológia végösszegét, beleértve a második alagutat és a felügyeletet, nem egy kapcsolat mai árát. Számítsa bele a munkát, amelyet senki nem számláz ki: valakinek kulcsokat kell forgatnia, figyelnie az alagút állapotát, és hajnali háromkor válaszolnia a riasztásra, amikor egy átjáró újraindul. Általában ez a tétel dönti el a vitát, mert ez az egyetlen, amely soha nem jelenik meg egy ajánlatban.

Bármit is választ, három folyamatot teszteljen: a szándékoltat, egy elutasítottat, amelynek elutasítottnak kell maradnia, és a helyreállítási esetet, amikor a hub átjárója vagy egy peering leállt. Az a modell, amely csak a boldog utat magyarázza, nincs igazolva, hanem bemutatva.

Ellenőrizze a választást a saját állításával szemben

Írjon egy mondatot, amely megnevezi a modellt, a határt és a tulajdonost, majd ellenőrizze, hogy a telepített állapot megfelel-e neki. Peeringnél ez azt jelenti, hogy mindkét peering állapot Connected, a tényleges útvonal a cél-előtag peering következő ugrását mutatja, és nincs átjáró az útvonalon. VNet–VNet VPN-nél azt jelenti, hogy mindkét kapcsolat Connected, a kulcsok és szabályok egyeznek mindkét átjárón, és az útvonal következő ugrása a virtuális hálózati átjáró.

Ha az ellenőrzések ellentmondanak a mondatnak, először a mondatot javítsa. A zavar legnagyobb része ezekben a tervekben egy olyan hibridből származik, amelyet senki nem írt le: peering a munkaterhelés alhálózatához, VPN egy örökölt szolgáltatáshoz, és egy útvonaltábla, amely csendben az egyiket részesíti előnyben.