Peering de Azure ou VPN de VNet a VNet? Decida antes de encamiñar

Azure ofrécelle polo menos dúas formas de conectar dúas redes virtuais, e non son axustes intercambiables do mesmo obxecto. O peering une as VNet no backbone de Microsoft sen pasarela; unha VPN de VNet a VNet sitúa unha relación IPsec entre dúas pasarelas que vostede desprega, dimensiona e supervisa. A decisión redúcese a tres condicións, e se non pode responder as tres antes de engadir unha ruta, está a piques de construír unha volta para un modelo que nunca elixiu.

Tres condicións que deciden o modelo

A primeira é se algo do requisito necesita unha fronteira IPsec que sexa súa e que poida sinalar. A segunda é se os espazos de enderezos están limpos e as dúas VNet só necesitan falar entre si. A terceira é quen é dono de calquera ruta transitiva e da factura da pasarela. Respóndallas nesa orde, porque a primeira pode eliminar o peering por atractiva que pareza a segunda.

O que comparten ambos os modelos é unha regra de enderezo dura: os espazos de enderezos das VNet non deben solaparse. Nin o peering nin unha VPN de VNet a VNet son unha forma admitida de facer inequívocos dous rangos idénticos, e un solapamento esixe un deseño de mapeo ou un redeseño, non outro tipo de conexión.

Condición 1: necesita unha fronteira IPsec que sexa súa?

O peering transporta o tráfico polo backbone privado de Azure e non require unha pasarela VPN para a propia conexión emparellada. Iso é unha afirmación sobre o transporte, non unha afirmación sobre cifrado que poida entregar a un auditor como «usamos IPsec». Se o requisito nomea un túnel configurado polo cliente, unha política IKE concreta ou unha fronteira que remata en equipamento que vostede controla, o peering non o cumpre, por privado que sexa o backbone.

Unha VPN de VNet a VNet si proporciona esa fronteira: dúas pasarelas, unha relación IPsec/IKE, claves compartidas e toda a superficie operativa que conleva. Vostede herda o estado do túnel, a capacidade da pasarela, os límites de SKU e a supervisión que demostra que o túnel está activo. Esa é a resposta correcta cando o requisito trata especificamente desa fronteira, descrita na visión xeral do peering como un tipo de conexión distinto do peering.

Sexa igual de coidadoso na dirección contraria. «Necesitamos cifrado entre VNet» a miúdo sátiase co TLS propio da carga de traballo, e entón unha pasarela é un custo sen requisito detrás. Escriba a frase que lerá o auditor antes de escoller o mecanismo.

Condición 2: a topoloxía é directa ou algo necesita transitar?

O peering non é transitivo. Dúas VNet emparelladas cun concentrador non quedan por iso conectadas entre si, e unha ruta que parece funcionar nunha dirección adoita ser un peering que alcanzou Connected só nun lado. Ambos os lados deben existir e ambos deben mostrar Connected, e iso é o primeiro que hai que comprobar cando o tráfico desaparece en silencio.

Se o requisito é alcanzar a rede local a través dun concentrador, o tránsito de pasarela é un deseño aparte con roles concretos: o concentrador posúe a pasarela, o peering do spoke permite o tránsito de pasarela e o spoke debe permitir o tráfico reenviado. Son propiedades do peering, non consecuencias automáticas de conectar as 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

A táboa de rutas efectiva é a resposta honesta a «existe o camiño?». Mostra o tipo de seguinte salto que a plataforma usará realmente, así que un peering que parece configurado pero non está conectado aparece como unha ruta ausente ou incorrecta en lugar de como un misterio.

Condición 3: quen é dono do camiño transitivo e da factura?

Cada salto adicional ten un dono. Con peering, unha VNet nova significa un par de peering novo en ambos os lados e, para o tránsito, un concentrador que segue reenviando tráfico e unha táboa de rutas que segue apuntando a el. Cunha VPN, unha VNet nova significa outra pasarela ou outra conexión sobre unha existente, co seu propio teito de capacidade que vixiar.

O custo segue a mesma forma pero non as mesmas partidas: os cargos de peering son conexión e transferencia de datos, mentres que unha VPN engade horas de pasarela e os seus propios cargos de transferencia. Compare o total para a topoloxía que realmente executará durante un ano, incluído o segundo túnel e a supervisión, non o prezo dunha conexión hoxe. Inclúa o traballo que ninguén factura: alguén ten que rotar claves, vixiar o estado do túnel e responder á alerta ás tres da mañá cando se reinicia unha pasarela. Esa partida adoita decidir a discusión, porque é a única que nunca aparece nun orzamento.

Elixa o que elixa, probe tres fluxos: o previsto, un denegado que debe seguir denegado e o caso de recuperación no que a pasarela do concentrador ou un peering está caído. Un modelo que só explica o camiño feliz non se verificou, demostrouse.

Verifique a elección contra a súa propia afirmación

Escriba unha frase que nomee o modelo, a fronteira e o dono, e despois comprobe que o estado despregado encaixa con ela. Para o peering iso significa ambos os estados de peering en Connected, a ruta efectiva mostrando o seguinte salto de peering para o prefixo de destino e ningunha pasarela no camiño. Para unha VPN de VNet a VNet significa ambas as conexións en Connected, claves e directivas coincidentes en ambas as pasarelas e unha ruta cuxo seguinte salto é a pasarela de rede virtual.

Se as comprobacións contradín a frase, corrixa primeiro a frase. A maior parte da confusión nestes deseños vén dun híbrido que ninguén describiu: un peering para a subrede da carga de traballo, unha VPN para un servizo herdado e unha táboa de rutas que prefire un deles en silencio.