Designfas 2: Anslut ivitet med virtuella Azure-nätverk
Privata Azure VMware Solution-moln ansluter till virtuella Azure-nätverk via hanterade Azure ExpressRoute-kretsar. Mer information finns i ExpressRoute-kretsar och privata moln för Azure VMware Solution. I Hub-spoke Azure-nätverk (inklusive nätverk som har skapats med Azure Virtual WAN) ger anslutning av ett privat molns hanterade krets till en ExpressRoute-gateway i hubbnätverket (eller Virtual WAN-hubben) Layer 3-anslutning med det privata molnet. Att framtvinga säkerhetsprinciper för att selektivt tillåta eller neka anslutningar mellan resurser är dock ofta ett krav. Det här kravet kan finnas mellan:
- Virtuella Azure-nätverk och virtuella datorer som körs i det privata azure VMware Solution-molnet.
- Virtuella Azure-nätverk och Azure VMware Solution privata molns hanteringsslutpunkter.
Även om både virtuella Azure-nätverk och vSphere/NSX-T tillhandahåller inbyggda konstruktioner för nätverkssegmentering, är brandväggslösningar som distribueras som virtuella nätverksinstallationer (NVA) i virtuella Azure-nätverk ofta det bästa alternativet i miljöer i företagsskala. Den här artikeln fokuserar på en konfiguration av virtuella nätverk som gör att du kan dirigera trafik mellan privata moln och virtuella Azure-nätverk med hjälp av anpassade nästa hopp, till exempel brandväggs-NVA:er.
Valet du gör i den här designfasen beror på vilket alternativ du valde i designfas 1 för lokal anslutning. Faktum är att den hanterade ExpressRoute-kretsen som ansluter ett privat moln till ett virtuellt Azure-nätverk också kan spela en roll i anslutningen till lokala platser. Så är fallet om du väljer överföring via privat ExpressRoute-peering under designfas 1. Det här flödesschemat visar processen för att välja ett alternativ för anslutning till virtuella Azure-nätverk:
Mer information om anslutning med virtuella Azure-nätverk finns i något av följande avsnitt. Välj det avsnitt som matchar hybridanslutningsalternativet som du valde under designfas 1.
Överföring via privat ExpressRoute-peering används för lokal trafik
När du använder överföring via privat ExpressRoute-peering för anslutning till lokala platser dirigeras trafiken via NVA:er (vanligtvis Azure Firewall eller brandväggslösningar från tredje part) i hubbnätverket. Trafik från lokala platser går in i det virtuella Azure-nätverket via ExpressRoute-gatewayen (ansluten till den kundägda kretsen) och dirigeras till brandväggens NVA. Efter inspektionen vidarebefordras trafiken (om den inte tas bort av brandväggen) till det privata molnet via den hanterade ExpressRoute-kretsen.
I motsatt riktning går trafik från det privata molnet in i det virtuella hubbnätverket eller det extra virtuella nätverket, beroende på vilket implementeringsalternativ som valdes under designfas 1 (enskilt virtuellt nätverk eller extra virtuellt nätverk). Den dirigeras sedan via ExpressRoute-gatewayen som är ansluten till den hanterade kretsen och till brandväggens NVA. Efter inspektionen vidarebefordras trafiken (om den inte tas bort av brandväggen) till det lokala målet via den kundägda ExpressRoute-kretsen.
De enskilda alternativen för virtuellt nätverk och extra virtuella nätverk omfattar både routningskonfiguration som gör att all trafik från ett privat moln vidarebefordras till brandväggens NVA:er i hubbnätverket, oavsett mål (virtuellt Azure-nätverk eller lokala platser). Brandväggsregler för att tillåta eller släppa anslutningar mellan virtuella datorer som körs i det privata molnet och Azure-resurser måste läggas till i brandväggsprincipen.
ExpressRoute Global Reach används för lokal trafik
När du använder ExpressRoute Global Reach för anslutning till lokala platser transporterar ExpressRoute-gatewayanslutningen mellan hubbnätverket och det privata molnet endast trafik till Azure-resurser. Om du vill dirigera trafiken via en brandväggsenhet måste du implementera följande konfiguration:
- I traditionella hub-spoke-nätverk måste du lägga till användardefinierade vägar (UDR) i det virtuella hubbnätverkets GatewaySubnet för alla mål (IP-prefix) i Azure som måste nås via NVA:erna. Nästa hopp-IP-adress för UDR:erna är brandväggens VIP (brandväggens privata IP-adress när du använder Azure Firewall).
- I hub-spoke-nätverk som är baserade på Virtual WAN med navintegrerade NVA:er (Azure Firewall eller säkerhetslösningar från tredje part) måste du lägga till anpassade statiska vägar till Virtual WAN-hubbens standardrutttabell. En UDR krävs för varje IP-prefix som måste nås via NVA:erna från Azure VMware Solution. Nästa hopp för dessa UDF:er måste vara brandväggen eller NVA:s VIP. Du kan också aktivera och konfigurera virtual WAN-routnings- och routningsprinciper på skyddade Virtual WAN-hubbar.
VPN:er för IPSec används för lokal trafik
När du använder IPSec VPN för anslutning till lokala platser måste du konfigurera ytterligare routning för att dirigera anslutningar mellan ett privat moln och resurser i virtuella Azure-nätverk via brandväggs-NVA:er:
- I traditionella hub-spoke-nätverk måste du lägga till UDR i hubbnätverkets GatewaySubnet för alla mål (IP-prefix) i Azure som måste nås via NVA:erna. Nästa hopp-IP-adress för UDR:erna är brandväggens VIP (brandväggens privata IP-adress när du använder Azure Firewall).
- I hub-spoke-nätverk som baseras på Virtual WAN med hubbintegrerade NVA:er (Azure Firewall eller säkerhetslösningar från tredje part) måste du lägga till anpassade statiska vägar till Virtual WAN-hubbens standardrutttabell för varje uppsättning mål (IP-prefix) som måste nås via NVA:erna från Azure VMware Solution. För varje UDR måste nästa hopp vara brandväggen eller NVA:s VIP. Du kan också aktivera och konfigurera virtual WAN-routnings- och routningsprinciper på skyddade Virtual WAN-hubbar.
Nästa steg
Läs mer om inkommande internetanslutning.