VPN IP privada de Azure sobre ExpressRoute sen NVA

O mito di que cifrar o tráfico sobre o emparellamento privado de ExpressRoute require un dispositivo virtual de rede. Non é así. Azure admite unha Site-to-Site VPN Gateway cuxo extremo do túnel é un enderezo RFC1918 privado transportado polo circuíto, e o dispositivo é opcional, non estrutural. O que o mito do dispositivo oculta é a parte que realmente doe: activar o extremo privado nun obxecto en lugar de dous, e deixar que unha ruta de emparellamento directo gañe en silencio sobre a ruta cifrada.

De onde veu o mito

A afirmación ten unha orixe respectable. Durante anos, a receita práctica para IPsec sobre emparellamento privado era unha NVA, porque a pasarela xestionada só expuña extremos públicos. Iso cambiou, e as respostas escritas antes do cambio aínda se citan en fíos onde ninguén comproba a data. A corrección é estreita: existe unha pasarela VPN con enderezo privado, e cambia o extremo, non a lóxica de enrutamento ao seu redor.

Nada disto xubila a NVA. Xubila a suposición de que un dispositivo é o único camiño cara ao requisito.

Active o extremo privado nos dous niveis

Comece por unha conexión de emparellamento privado de ExpressRoute que funcione e estea vinculada á VNet que contén a pasarela VPN. O lado local xa debe alcanzar os enderezos privados pertinentes a través dese circuíto, porque o túnel usará eses enderezos como transporte. Despois o requisito previo da pasarela: o procedemento de Microsoft para VPN de IP privada esixe unha pasarela construída sobre un recurso IP público Standard. O direccionamento privado do túnel non elimina ese requisito, o que sorprende a quen supón que «privado» significa «ningún IP público en ningún sitio».

Agora active o indicador nos dous lugares. A configuración da pasarela ten o seu propio interruptor para IP privadas, e a conexión Site-to-Site individual ten un segundo que fai que esa conexión use o enderezo privado. Poñer un e non o outro é a configuración incompleta máis habitual; o túnel ou non se establece ou se establece contra o extremo equivocado.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Confirme os nomes das propiedades coa versión de CLI que teña instalada, porque as etiquetas do portal e as propiedades da CLI non sempre comparten redacción. Unha pasarela activa-activa expón dous enderezos privados de túnel, e o dispositivo local necesita ambos os pares configurados se quere que esa redundancia signifique algo. BGP non é necesario só para levantar este túnel de enderezo privado, aínda que adoita formar parte de como distribúe os prefixos.

O segundo mito: un túnel establecido cifra o seu tráfico

Dous camiños chegan agora á rede de aplicacións: o camiño directo de emparellamento privado e o camiño a través da VPN. Ambos funcionan. Só un aplica esta capa IPsec. Microsoft documenta que, cando se anuncian prefixos idénticos por ExpressRoute e pola VPN, Azure prefire o camiño directo de ExpressRoute, así que un túnel san con contadores sans non demostra nada sobre onde foron os paquetes da aplicación.

Os métodos de dirección documentados son un rango que cobre ExpressRoute cun rango protexido máis específico na VPN, ou prefixos disxuntos nos dous camiños. Como ilustración, o emparellamento privado podería levar 10.40.0.0/16 mentres a VPN anuncia 10.40.12.0/24. O prefixo máis específico gaña e o resto do rango permanece directo.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Faga a mesma comprobación na dirección local, xa que a preferencia do seu enrutador decide por onde sae o tráfico de saída. E manteña o transporte propio do túnel no camiño de ExpressRoute; unha ruta que arrastre o extremo privado da pasarela dentro do túnel fai que o túnel dependa de si mesmo.

Decida que ocorre cando o túnel cae

Unha ruta VPN máis específica desaparece cando o túnel cae, mentres que a ruta directa máis ampla permanece. O tráfico flúe entón sen cifrar e todo parece san, que é o peor modo de fallo para un requisito que existe para garantir o cifrado. Se o requisito prohibe esa caída, o enrutamento e a política de acceso deben dicilo explicitamente en lugar de confiar na dispoñibilidade do túnel.

Anote que prefixos poden seguir sendo accesibles directamente e cales deben deterse cando falta o camiño cifrado. Despois probe o caso permitido con tráfico real e compare os contadores de conexión, porque a táboa de rutas por si soa non lle dirá se o requisito de cifrado segue cumpríndose.

Ese planteamento tamén lle permite avaliar unha NVA polas súas funcións reais, como varios túneles, rendemento ou inspección do provedor, en lugar de comprar unha porque o extremo sexa privado.