VPN IP privata di Azure su ExpressRoute senza NVA

Il mito è che cifrare il traffico sul peering privato di ExpressRoute richieda un'appliance di rete virtuale. Non è così. Azure supporta una Site-to-Site VPN Gateway il cui endpoint del tunnel è un indirizzo RFC1918 privato trasportato dal circuito, e l'appliance è facoltativa, non strutturale. Ciò che il mito dell'appliance nasconde è la parte che fa davvero male: abilitare l'endpoint privato su un oggetto invece di due, e lasciare che una route di peering diretto vinca silenziosamente sul percorso cifrato.

Da dove viene il mito

L'affermazione ha un'origine rispettabile. Per anni la ricetta pratica per IPsec sul peering privato è stata una NVA, perché il gateway gestito esponeva solo endpoint pubblici. Questo è cambiato, e le risposte scritte prima del cambiamento vengono ancora citate in thread dove nessuno controlla la data. La correzione è stretta: esiste un gateway VPN con indirizzo privato, e cambia l'endpoint, non la logica di routing attorno ad esso.

Niente di tutto questo manda in pensione la NVA. Manda in pensione l'assunto che un'appliance sia l'unica strada verso il requisito.

Abilitate l'endpoint privato su entrambi i livelli

Partite da una connessione di peering privato ExpressRoute funzionante, collegata alla VNet che ospita il gateway VPN. Il lato locale deve già raggiungere gli indirizzi privati pertinenti attraverso quel circuito, perché il tunnel userà quegli indirizzi come trasporto. Poi il prerequisito del gateway: la procedura Microsoft per VPN con IP privato richiede un gateway costruito su una risorsa IP pubblica Standard. L'indirizzamento privato del tunnel non elimina quel requisito, cosa che sorprende chi presume che «privato» significhi «nessun IP pubblico da nessuna parte».

Ora abilitate il flag in entrambi i punti. La configurazione del gateway ha il proprio interruttore per gli IP privati, e la singola connessione Site-to-Site ne ha un secondo che fa usare l'indirizzo privato a quella connessione. Impostarne uno senza l'altro è la configurazione incompleta più comune; il tunnel o non si stabilisce o si stabilisce verso l'endpoint sbagliato.

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

Verificate i nomi delle proprietà rispetto alla versione CLI installata, perché le etichette del portale e le proprietà CLI non hanno sempre la stessa formulazione. Un gateway attivo-attivo espone due indirizzi di tunnel privati, e il dispositivo locale deve avere entrambi i peer configurati se volete che quella ridondanza significhi qualcosa. BGP non è necessario solo per alzare questo tunnel a indirizzo privato, anche se di solito fa parte del modo in cui distribuite i prefissi.

Il secondo mito: un tunnel stabilito cifra il vostro traffico

Due percorsi raggiungono ora la rete applicativa: il percorso diretto del peering privato e il percorso attraverso la VPN. Entrambi funzionano. Solo uno applica questo strato IPsec. Microsoft documenta che, quando prefissi identici sono annunciati su ExpressRoute e sulla VPN, Azure preferisce il percorso diretto ExpressRoute, quindi un tunnel sano con contatori sani non dimostra nulla su dove siano andati i pacchetti dell'applicazione.

I metodi di direzione documentati sono un intervallo coprente su ExpressRoute con un intervallo protetto più specifico sulla VPN, o prefissi disgiunti sui due percorsi. Per esempio, il peering privato potrebbe trasportare 10.40.0.0/16 mentre la VPN annuncia 10.40.12.0/24. Il prefisso più specifico vince e il resto dell'intervallo resta diretto.

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

Fate lo stesso controllo nella direzione locale, perché la preferenza del vostro router decide da dove esce il traffico in uscita. E tenete il trasporto del tunnel stesso sul percorso ExpressRoute; una route che trascina l'endpoint privato del gateway dentro il tunnel rende il tunnel dipendente da se stesso.

Decidete cosa succede quando il tunnel cade

Una route VPN più specifica scompare quando il tunnel cade, mentre la route diretta più ampia resta. Il traffico scorre allora senza cifratura e tutto sembra sano, che è il peggior modo di guasto per un requisito che esiste per garantire la cifratura. Se il requisito vieta quel ripiego, il routing e la politica di accesso devono dirlo esplicitamente invece di affidarsi alla disponibilità del tunnel.

Annotate quali prefissi possono restare raggiungibili direttamente e quali devono fermarsi quando il percorso cifrato è assente. Poi provate il caso consentito con traffico reale e confrontate i contatori di connessione, perché la tabella di routing da sola non vi dirà se il requisito di cifratura vale ancora.

Quella impostazione vi permette anche di valutare una NVA per le sue funzioni reali, come più tunnel, throughput o ispezione del fornitore, invece di comprarne una perché l'endpoint è privato.