Peering d'Azure o VPN VNet a VNet? Decidiu abans d'encaminar

Azure us ofereix com a mínim dues maneres de connectar dues xarxes virtuals, i no són paràmetres intercanviables del mateix objecte. El peering uneix les VNet a la xarxa troncal de Microsoft sense gateway; una VPN VNet a VNet posa una relació IPsec entre dos gateways que desplegueu, dimensioneu i superviseu. La decisió es redueix a tres condicions, i si no podeu respondre les tres abans d'afegir una ruta, esteu a punt de construir una solució alternativa per a un model que no vau triar mai.

Tres condicions que decideixen el model

La primera és si alguna cosa del requisit necessita una frontera IPsec que sigui vostra i que pugueu assenyalar. La segona és si els espais d'adreces són nets i les dues VNet només han de parlar entre elles. La tercera és qui és propietari de qualsevol camí transitiu i del cost del gateway. Responeu-les en aquest ordre, perquè la primera pot eliminar el peering per atractiva que sembli la segona.

El que comparteixen tots dos models és una regla d'adreçament dura: els espais d'adreces de les VNet no es poden solapar. Ni el peering ni una VPN VNet a VNet són una manera suportada de fer inequívocs dos rangs idèntics, i un solapament necessita un disseny de mapatge o un redisseny, no un tipus de connexió diferent.

Condició 1: necessiteu una frontera IPsec que sigui vostra?

El peering transporta el trànsit per la xarxa troncal privada d'Azure i no requereix cap gateway VPN per a la connexió en si. Això és una afirmació sobre el transport, no una afirmació sobre xifratge que pugueu presentar a un auditor com «fem servir IPsec». Si el requisit anomena un túnel configurat pel client, una política IKE concreta o una frontera que acaba en equipament que controleu, el peering no ho compleix, per privada que sigui la xarxa troncal.

Una VPN VNet a VNet sí que proporciona aquesta frontera: dos gateways, una relació IPsec/IKE, claus compartides i tota la superfície operativa que comporta. Hereteu l'estat del túnel, la capacitat del gateway, els límits d'SKU i la supervisió que demostra que el túnel està actiu. Aquesta és la resposta correcta quan el requisit tracta específicament d'aquesta frontera, descrita a la visió general del peering com un tipus de connexió diferent del peering.

Sigueu igual de curosos en l'altra direcció. «Necessitem xifratge entre VNet» sovint se satisfà amb el TLS propi de la càrrega de treball, i llavors un gateway és una despesa sense cap requisit al darrere. Escriviu la frase que llegirà l'auditor abans de triar el mecanisme.

Condició 2: la topologia és directa, o cal que alguna cosa transiti?

El peering no és transitiu. Dues VNet amb peering cap a un hub no queden per això connectades entre elles, i una ruta que sembla funcionar en una direcció sol ser un peering que només ha arribat a Connected en un costat. Els dos costats han d'existir i tots dos han de mostrar Connected, i això és el primer que cal comprovar quan el trànsit desapareix en silenci.

Si el requisit és arribar a la xarxa local a través d'un hub, el trànsit de gateway és un disseny a part amb rols concrets: el hub posseeix el gateway, el peering del spoke permet el trànsit de gateway i el spoke ha de permetre el trànsit reenviat. Són propietats del peering, no conseqüències automàtiques de connectar les 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

La taula de rutes efectiva és la resposta honesta a «existeix el camí?». Mostra el tipus de salt següent que la plataforma farà servir realment, així que un peering que sembla configurat però no connectat apareix com una ruta absent o incorrecta i no com un misteri.

Condició 3: qui és propietari del camí transitiu i del cost?

Cada salt addicional té un propietari. Amb peering, una VNet nova significa una parella de peering nova als dos costats i, per al trànsit, un hub que continua reenviant trànsit i una taula de rutes que continua apuntant-hi. Amb una VPN, una VNet nova significa un altre gateway o una altra connexió sobre un d'existent, amb el seu propi sostre de capacitat a vigilar.

El cost segueix la mateixa forma però no les mateixes partides: els càrrecs de peering són connexió i transferència de dades, mentre que una VPN afegeix hores de gateway i els seus propis càrrecs de transferència. Compareu el total per a la topologia que realment fareu funcionar durant un any, incloent-hi el segon túnel i la supervisió, no el preu d'una connexió avui. Incloeu la feina que ningú factura: algú ha de rotar claus, vigilar l'estat del túnel i respondre a l'alerta a les tres de la matinada quan un gateway es reinicia. Aquesta partida sol decidir la discussió, perquè és l'única que no apareix mai en un pressupost.

Tant se val quin trieu, proveu tres fluxos: el previst, un de denegat que ha de continuar denegat i el cas de recuperació en què el gateway del hub o un peering està caigut. Un model que només explica el camí feliç no s'ha verificat, s'ha demostrat.

Verifiqueu l'elecció contra la seva pròpia afirmació

Escriviu una frase que anomeni el model, la frontera i el propietari, i després comproveu que l'estat desplegat hi encaixa. Per al peering això vol dir els dos estats de peering a Connected, la ruta efectiva mostrant el salt següent de peering per al prefix de destinació i cap gateway al camí. Per a una VPN VNet a VNet vol dir les dues connexions a Connected, claus i polítiques coincidents als dos gateways i una ruta el salt següent de la qual és el gateway de xarxa virtual.

Si les comprovacions discrepen de la frase, arregleu primer la frase. La major part de la confusió en aquests dissenys ve d'un híbrid que ningú no ha descrit: un peering per a la subxarxa de la càrrega de treball, una VPN per a un servei antic i una taula de rutes que en prefereix un en silenci.