VPN IP privada d'Azure sobre ExpressRoute sense cap NVA

El mite diu que xifrar el trànsit sobre el peering privat d'ExpressRoute requereix un aparell virtual de xarxa. No és així. Azure admet una Site-to-Site VPN Gateway el punt final del túnel de la qual és una adreça RFC1918 privada que es transporta pel circuit, i l'aparell és opcional, no estructural. El que el mite de l'aparell amaga és la part que realment fa mal: activar el punt final privat en un objecte en lloc de dos, i deixar que una ruta de peering directa guanyi silenciosament sobre el camí xifrat.

D'on venia el mite

L'afirmació té un origen respectable. Durant anys, la recepta pràctica per a IPsec sobre peering privat era una NVA, perquè la passarel·la gestionada només exposava punts finals públics. Això va canviar, i les respostes escrites abans del canvi encara es citen en fils on ningú no comprova la data. La correcció és estreta: existeix una passarel·la VPN amb adreça privada, i canvia el punt final, no la lògica d'encaminament al seu voltant.

Res d'això no jubila la NVA. Jubila la suposició que un aparell és l'única via cap al requisit.

Activeu el punt final privat als dos nivells

Comenceu per una connexió de peering privat d'ExpressRoute que funcioni i estigui enllaçada a la VNet que conté la passarel·la VPN. El costat local ja ha d'arribar a les adreces privades rellevants a través d'aquest circuit, perquè el túnel farà servir aquestes adreces com a transport. Després, el requisit previ de la passarel·la: el procediment de Microsoft per a VPN amb IP privada requereix una passarel·la construïda sobre un recurs IP públic Standard. L'adreçament privat del túnel no elimina aquest requisit, cosa que sorprèn qui assumeix que «privat» vol dir «cap IP pública enlloc».

Ara activeu la marca als dos llocs. La configuració de la passarel·la té el seu propi commutador per a les IP privades, i la connexió Site-to-Site individual en té un segon que fa que aquesta connexió utilitzi l'adreça privada. Posar-ne un i no l'altre és la configuració incompleta més habitual; el túnel o no s'estableix o s'estableix cap al punt final equivocat.

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}'

Confirmeu els noms de les propietats amb la versió de CLI que teniu instal·lada, perquè les etiquetes del portal i les propietats de la CLI no sempre comparteixen la mateixa redacció. Una passarel·la activa-activa exposa dues adreces privades de túnel, i el dispositiu local necessita tots dos parells configurats si voleu que aquesta redundància signifiqui alguna cosa. BGP no cal només per aixecar aquest túnel d'adreça privada, tot i que normalment forma part de com distribuïu els prefixos.

El segon mite: un túnel establert xifra el vostre trànsit

Ara hi ha dos camins cap a la xarxa d'aplicacions: el camí directe de peering privat i el camí a través de la VPN. Tots dos funcionen. Només un aplica aquesta capa IPsec. Microsoft documenta que quan s'anuncien prefixos idèntics per ExpressRoute i per la VPN, Azure prefereix el camí directe d'ExpressRoute, de manera que un túnel sa amb comptadors sans no demostra res sobre on han anat els paquets de l'aplicació.

Els mètodes de direcció documentats són un rang que cobreix ExpressRoute amb un rang protegit més específic a la VPN, o prefixos disjunts als dos camins. Com a il·lustració, el peering privat podria portar 10.40.0.0/16 mentre la VPN anuncia 10.40.12.0/24. El prefix més específic guanya i la resta del rang es queda directe.

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

Feu la mateixa comprovació en la direcció local, perquè la preferència del vostre encaminador decideix per on surt el trànsit de sortida. I manteniu el transport propi del túnel al camí d'ExpressRoute; una ruta que arrossegui el punt final privat de la passarel·la dins del túnel fa que el túnel depengui de si mateix.

Decidiu què passa quan el túnel cau

Una ruta VPN més específica desapareix quan el túnel cau, mentre que la ruta directa més àmplia es manté. Llavors el trànsit circula sense xifrar i tot sembla sa, que és el pitjor mode de fallada per a un requisit que existeix per garantir el xifratge. Si el requisit prohibeix aquesta retirada, l'encaminament i la política d'accés ho han de dir explícitament en lloc de confiar en la disponibilitat del túnel.

Anoteu quins prefixos poden quedar directament accessibles i quins han d'aturar-se quan el camí xifrat no hi és. Després proveu el cas permès amb trànsit real i compareu els comptadors de connexió, perquè la taula de rutes sola no us dirà si el requisit de xifratge encara es compleix.

Aquest plantejament també us permet avaluar una NVA per les seves funcions reals, com ara múltiples túnels, rendiment o inspecció del proveïdor, en lloc de comprar-ne una perquè el punt final és privat.