Inserimento di route predefinito nelle reti virtuali spoke
Una delle architetture più comuni in Azure è la progettazione hub-spoke, in cui i carichi di lavoro distribuiti in una rete virtuale spoke inviano traffico attraverso dispositivi di rete condivisa presenti nella rete virtuale hub. Le route definite dall'utente devono in genere essere configurate nelle reti virtuali spoke per indirizzare il traffico verso i dispositivi di sicurezza nell'hub. Tuttavia, questa progettazione richiede agli amministratori di gestire queste route tra molti spoke.
Il server di route di Azure offre un punto centralizzato in cui le appliance virtuali di rete possono annunciare le route che inserisce nelle reti virtuali spoke. In questo modo, gli amministratori non devono creare e aggiornare le tabelle di route nelle reti virtuali spoke.
Topologia
Il diagramma seguente illustra una progettazione hub-spoke semplice con una rete virtuale hub e due reti virtuali spoke. Nell'hub sono state distribuite un'appliance virtuale di rete e un server di route. Senza il server di route, le route definite dall'utente devono essere configurate in ogni spoke. Queste route definite dall'utente contengono in genere una route predefinita per 0.0.0.0/0 che invia tutto il traffico dalle reti virtuali spoke attraverso l'appliance virtuale di rete. Questo scenario può essere usato, ad esempio, per controllare il traffico a scopo di sicurezza.
Con il server di route nella rete virtuale dell'hub, non è necessario usare route definite dall'utente. L'appliance virtuale di rete annuncia i prefissi di rete al server di route, che li inserisce in modo che vengano visualizzati nelle route effettive di qualsiasi macchina virtuale distribuita nella rete virtuale hub o nelle reti virtuali spoke con peering con la rete virtuale hub con l'impostazione Usa il gateway o il server di route della rete virtuale remota.
Connessione ivity all'ambiente locale tramite l'appliance virtuale di rete
Se l'appliance virtuale di rete viene usata per fornire connettività alla rete locale tramite VPN IPsec o tecnologie SD-WAN, lo stesso meccanismo può essere usato per attirare il traffico dagli spoke all'appliance virtuale di rete. Inoltre, l'appliance virtuale di rete può apprendere dinamicamente i prefissi di Azure dal server di route di Azure e annunciarli con un protocollo di routing dinamico in locale. Il diagramma seguente descrive questa configurazione:
Controllo del traffico privato tramite l'appliance virtuale di rete
Le sezioni precedenti illustrano il traffico controllato dall'appliance virtuale di rete inserendo una 0.0.0.0/0 route predefinita dall'appliance virtuale di rete al server di route. Tuttavia, se si vuole esaminare solo il traffico spoke-to-spoke e spoke-to-premise tramite l'appliance virtuale di rete, è consigliabile considerare che il server di route di Azure non annuncia una route con lo stesso prefisso o più lungo rispetto allo spazio di indirizzi della rete virtuale appreso dall'appliance virtuale di rete. In altre parole, il server di route di Azure non inserisce questi prefissi nella rete virtuale e non verranno programmati nelle schede di interfaccia di rete delle macchine virtuali nelle reti virtuali hub o spoke.
Il server di route di Azure, tuttavia, annuncia una subnet più grande rispetto allo spazio di indirizzi della rete virtuale appreso dall'appliance virtuale di rete. È possibile annunciare dall'appliance virtuale di rete una supernet di ciò che si ha nella rete virtuale. Ad esempio, se la rete virtuale usa lo spazio 10.0.0.0/16di indirizzi RFC 1918 , l'appliance virtuale di rete può annunciare 10.0.0.0/8 al server di route di Azure e questi prefissi verranno inseriti nelle reti virtuali hub-spoke. Questo comportamento della rete virtuale viene fatto riferimento in Informazioni su BGP con Gateway VPN.
Importante
Se si ha uno scenario in cui i prefissi con la stessa lunghezza vengono annunciati da ExpressRoute e dall'appliance virtuale di rete, Azure preferisce e programma le route apprese da ExpressRoute. Per ulteriori informazioni, vedi la sezione successiva.
Connessione ivity to on-premises through virtual network gateways
Se esiste una VPN o un gateway ExpressRoute nella stessa rete virtuale del server di route e dell'appliance virtuale di rete per fornire la connettività alle reti locali, le route apprese da questi gateway verranno programmate anche nelle reti virtuali spoke. Queste route sostituiscono la route predefinita (0.0.0.0/0) inserita dal server di route, perché sarebbero più specifiche (maschere di rete più lunghe). Il diagramma seguente descrive la progettazione precedente, in cui è stato aggiunto un gateway ExpressRoute.
Non è possibile configurare le subnet nelle reti virtuali spoke per apprendere solo le route dal server di route di Azure. La disabilitazione di "Propaga route del gateway" in una tabella di route associata a una subnet impedisce l'inserimento di entrambi i tipi di route (route dal gateway di rete virtuale e le route dal server di route di Azure) nelle schede di interfaccia di rete in tale subnet.
Per impostazione predefinita, il server di route annuncia anche tutti i prefissi appresi dall'appliance virtuale di rete a ExpressRoute. Ciò potrebbe non essere necessario, ad esempio a causa dei limiti di route di ExpressRoute o del server di route stesso. In tal caso, l'appliance virtuale di rete può annunciare le route al server di route, inclusa la community no-advertise BGP (con valore 65535:65282). Quando il server di route riceve le route con questa community BGP, le inserisce nelle subnet, ma non le annuncia ad altri peer BGP( ad esempio ExpressRoute o gateway VPN o altre appliance virtuali di rete).
Coesistenza SDWAN con ExpressRoute e Firewall di Azure
Un caso specifico della progettazione precedente è quando i clienti inseriscono il Firewall di Azure nel flusso di traffico per controllare tutto il traffico che passa alle reti locali, tramite ExpressRoute o tramite appliance SD-WAN/VPN. In questo caso, tutte le subnet spoke hanno tabelle di route che impediscono agli spoke di apprendere qualsiasi route da ExpressRoute o dal server di route e hanno route predefinite (0.0.0.0/0) con il Firewall di Azure come hop successivo, come illustrato nel diagramma seguente:
La subnet Firewall di Azure apprende le route provenienti sia da ExpressRoute che dall'appliance virtuale di rete VPN/SDWAN e decide se inviare il traffico in un modo o nell'altro. Come descritto nella sezione precedente, se l'appliance NVA annuncia più di 200 route al server di route, deve inviare le route BGP contrassegnate con la community no-advertiseBGP . In questo modo, i prefissi SDWAN non verranno inseriti in locale tramite Express-Route.
Simmetria del traffico
Se più istanze dell'appliance virtuale di rete vengono usate in uno scenario attivo/attivo per una migliore resilienza o scalabilità, la simmetria del traffico è un requisito se le appliance virtuali di rete devono mantenere lo stato delle connessioni. Questo è, ad esempio, il caso dei firewall di nuova generazione.
- Per la connettività dalle macchine virtuali di Azure alla rete Internet pubblica, l'appliance virtuale di rete usa SNAT (Source Network Address Translation) in modo che il traffico in uscita venga originato dall'indirizzo IP pubblico dell'appliance virtuale di rete, ottenendo quindi la simmetria del traffico.
- Per il traffico in ingresso da Internet ai carichi di lavoro in esecuzione in macchine virtuali, oltre alla conversione degli indirizzi di rete di destinazione (DNAT), le appliance virtuali di rete dovranno eseguire la conversione degli indirizzi di rete di origine (SNAT), per assicurarsi che il traffico restituito dalle macchine virtuali venga atterrato nella stessa istanza dell'appliance virtuale di rete che ha elaborato il primo pacchetto.
- Per la connettività da Azure ad Azure, poiché la macchina virtuale di origine prende la decisione di routing indipendentemente dalla destinazione, SNAT è necessario oggi per ottenere la simmetria del traffico.
È possibile distribuire più istanze dell'appliance virtuale di rete anche in una configurazione attiva/passiva, ad esempio se una di esse annuncia route peggiori (con un percorso AS più lungo) rispetto all'altra. In questo caso, il server di route di Azure inserisce solo la route preferita nelle macchine virtuali della rete virtuale e la route meno preferita verrà usata solo quando l'istanza di appliance virtuale di rete primaria interrompe la pubblicità tramite BGP.
Server di route diversi per annunciare le route ai gateway Rete virtuale e alle reti virtuali
Come illustrato nelle sezioni precedenti, il server di route di Azure ha un doppio ruolo:
- Apprende e annuncia le route da e verso i gateway di rete virtuale (VPN ed ExpressRoute)
- Configura le route apprese nella rete virtuale e nelle reti virtuali con peering diretto
Questa doppia funzionalità è spesso interessante, ma a volte può essere dannosa per determinati requisiti. Ad esempio, se il server di route viene distribuito in una rete virtuale con un'appliance virtuale di rete che annuncia una route 0.0.0.0/0 e un prefissi di gateway ExpressRoute dall'ambiente locale, verranno configurate tutte le route (sia la versione 0.0.0.0/0 dell'appliance virtuale di rete che i prefissi locali) nelle macchine virtuali nella rete virtuale e nelle reti virtuali con peering diretto. Di conseguenza, poiché i prefissi locali saranno più specifici di 0.0.0.0/0, il traffico tra l'appliance virtuale di rete locale e Azure ignora l'appliance virtuale di rete. Se non si vuole, le sezioni precedenti di questo articolo hanno illustrato come disabilitare la propagazione BGP nelle subnet della macchina virtuale e configurare le route definite dall'utente.
Esiste tuttavia un approccio alternativo e più dinamico. È possibile usare server di route di Azure diversi per diverse funzionalità: uno di essi sarà responsabile dell'interazione con i gateway di rete virtuale e l'altro per interagire con il routing di rete virtuale. Il diagramma seguente illustra una possibile progettazione per questa operazione:
Il server di route 1 nell'hub viene usato per inserire i prefissi dalla rete SDWAN in ExpressRoute. Poiché le reti virtuali spoke sono sottoposte a peering con la rete virtuale dell'hub senza usare il gateway o il server di route della rete virtuale remota (nel peering reti virtuali spoke) e Usare il gateway o il server di route della rete virtuale (transito del gateway nel peering reti virtuali hub), le reti virtuali spoke non imparano queste route (né i prefissi SDWAN né i prefissi ExpressRoute).
Per propagare le route alle reti virtuali spoke, l'appliance virtuale di rete usa Route Server 2, distribuita in una nuova rete virtuale ausiliaria. L'appliance virtuale di rete propaga solo una singola 0.0.0.0/0 route a Route Server 2. Poiché le reti virtuali spoke sono sottoposte a peering con questa rete virtuale ausiliaria con Usare il gateway o il server di route della rete virtuale remota (nel peering reti virtuali spoke) e Usare il gateway o il server di route della rete virtuale (transito del gateway nel peering reti virtuali hub), la 0.0.0.0/0 route verrà appresa da tutte le macchine virtuali negli spoke.
L'hop successivo per la 0.0.0.0/0 route è l'appliance virtuale di rete, quindi le reti virtuali spoke devono comunque essere sottoposte a peering alla rete virtuale dell'hub. Un altro aspetto importante da notare è che la rete virtuale dell'hub deve essere con peering alla rete virtuale in cui viene distribuito Il server di route 2, altrimenti non sarà in grado di creare l'adiacenza BGP.
Se il traffico da ExpressRoute alle reti virtuali spoke deve essere inviato a un'appliance virtuale di rete del firewall per l'ispezione, è comunque necessaria una tabella di route in GatewaySubnet. In caso contrario, il gateway di rete virtuale ExpressRoute invierà pacchetti alle macchine virtuali usando le route apprese dal peering reti virtuali. Le route in questa tabella di route devono corrispondere ai prefissi spoke e l'hop successivo deve essere l'indirizzo IP dell'appliance virtuale di rete del firewall (o il servizio di bilanciamento del carico davanti alle appliance virtuali di rete del firewall, per la ridondanza). L'appliance virtuale di rete del firewall può essere la stessa dell'appliance virtuale di rete SDWAN nel diagramma precedente oppure può essere un dispositivo diverso, ad esempio Firewall di Azure, poiché l'appliance virtuale di rete SDWAN può annunciare le route con l'hop successivo che punta ad altri indirizzi IP. Il diagramma seguente illustra questa progettazione con l'aggiunta di Firewall di Azure:
Nota
Per qualsiasi traffico proveniente dall'ambiente locale destinato agli endpoint privati, questo traffico ignora l'appliance virtuale di rete del firewall o Firewall di Azure nell'hub. Ciò comporta tuttavia un routing asimmetrico (che può causare la perdita di connettività tra endpoint locali ed endpoint privati) come endpoint privati inoltrano il traffico locale al firewall. Per garantire la simmetria del routing, abilitare i criteri di rete tabella di route per gli endpoint privati nelle subnet in cui vengono distribuiti gli endpoint privati.
Questa progettazione consente l'inserimento automatico di route nelle reti virtuali spoke senza interferenze da altre route apprese da ExpressRoute, VPN o un ambiente SDWAN e dall'aggiunta di appliance virtuali di rete del firewall per l'ispezione del traffico.
Contenuto correlato
- Altre informazioni sul supporto del server di route di Azure per ExpressRoute e VPN di Azure.
- Informazioni su come configurare il peering tra il server di route di Azure e l'appliance virtuale di rete.