Distribuera NVA:er med hög tillgänglighet

I den här artikeln beskrivs vanliga sätt att distribuera en uppsättning virtuella nätverksinstallationer (NVA) för hög tillgänglighet i Azure. En NVA styr vanligtvis trafikflödet mellan nätverkssegment som har olika säkerhetsnivåer. Du kan till exempel använda en NVA mellan ett virtuellt perimeternätverk och det offentliga Internet, eller för att ansluta externa platser till Azure via ett virtuellt privat nätverk (VPN) eller programvarudefinierade WAN-enheter (SD-WAN).

Den här artikeln förutsätter att du har en grundläggande förståelse för Azure-nätverk, Azure-lastbalanserare, trafikroutning för virtuella nätverk och användardefinierade vägar (UDR).

Många designmönster använder NVA:er för att inspektera trafik mellan olika säkerhetszoner. Dessa mönster kan använda NVAs för dessa syften:

• För att inspektera utgående trafik från virtuella datorer till Internet och förhindra dataexfiltrering.

• För att inspektera inkommande trafik från Internet till virtuella datorer och förhindra attacker.

• Så här filtrerar du trafik mellan virtuella datorer i Azure för att förhindra laterala flyttningar av komprometterade system.

• För att filtrera trafik mellan lokala system och virtuella Azure-datorer, särskilt om de tillhör olika säkerhetsnivåer. Azure är till exempel värd för perimeternätverket, medan den lokala miljön är värd för de interna programmen.

• För att avsluta VPN eller SD-WAN tunnlar från externa platser, till exempel lokala nätverk eller andra offentliga moln.

Du kan lägga till följande NVA:er i en Azure-design med hjälp av mönstren i den här artikeln:

• Nätverksbrandväggar
• Omvända proxyservrar för Layer-4
• VPN-slutpunkter för Internet Protocol Security (IPsec)
• SD-WAN apparater
• Webbaserade omvända proxyservrar som har brandväggsfunktioner för webbaserade program
• Internetproxy för att begränsa vilka internetsidor som kan nås från Azure
• Layer-7-lastbalanserare

Azure-inbyggda NVA:er, till exempel Azure Firewall och Azure Application Gateway, använder designerna som beskrivs senare i den här artikeln. Du bör förstå dessa alternativ ur ett designperspektiv och för nätverksfelsökning.

NVA:er kräver ofta hög tillgänglighet eftersom de styr kommunikationen mellan nätverkssegment. Om NVA:er blir otillgängliga kan nätverkstrafiken inte flöda och programmen slutar fungera. Schemalagda och oplanerade avbrott stänger ibland av NVA-instanser, liknande andra virtuella datorer i Azure eller i andra moln. NVA-instanserna kan stängas av även om du konfigurerar dem med Azure Premium SSD:er, som tillhandahåller ett serviceavtal på en instans i Azure. Program med hög tillgänglighet kräver minst två NVA:er för att säkerställa anslutningen.

När du väljer det bästa alternativet för att distribuera en NVA till ett virtuellt Azure-nätverk är det viktigaste om NVA-leverantören har utvärderat och verifierat sin design. Leverantören måste också tillhandahålla den NVA-konfiguration som krävs för att integrera NVA i Azure. Om NVA-leverantören har flera designalternativ som stöds bör du överväga följande faktorer för att fatta ditt beslut:

• Konvergenstid: Den tid det tar för varje design att omdirigera trafik från en misslyckad NVA-instans

• Topologistöd: DE NVA-konfigurationer som varje designalternativ stöder, till exempel aktiva/aktiva, aktiva/vänteläge eller skalbara NVA-kluster som har en extra enhet för redundans

• Trafiksymmetri: Om en viss design tvingar NVA att utföra SNAT (Source Network Address Translation) på paketen för att undvika asymmetrisk routning, eller om designen framtvingar trafiksymmetri på annat sätt

Anmärkning

Den här artikeln fokuserar på nav-och-ekersystem. Den här artikeln beskriver inte Azure Virtual WAN eftersom den har mer normativa riktlinjer för distribution av NVA:er, beroende på om en Virtual Wan-hubb stöder en specifik NVA. Mer information finns i NVA:er i en Virtual WAN-hubb.

I följande avsnitt beskrivs vanliga arkitekturer som du kan använda för att integrera NVA:er i ett hub-and-spoke-nätverk.

Översikt över arkitekturer med hög tillgänglighet

Lösning	Fördelar	Överväganden
Azure Load Balancer	Den här lösningen stöder aktiva/aktiva- och aktiv/passiv-konfigurationer samt utskalerade NVA:er med bra konvergenstid.	NVA måste tillhandahålla en port för hälsoavsökningarna, särskilt för aktiva/väntelägesdistributioner. För tillståndskänsliga enheter, till exempel brandväggar som kräver trafiksymmetri, kräver flöden till och från Internet SNAT.
Azure Route Server	NVA måste ha stöd för Border Gateway Protocol (BGP). Den här lösningen stöder aktiva/aktiva, aktiva/väntelägesbaserade och utskalningsbaserade NVA:er.	Trafiksymmetri kräver SNAT i den här lösningen.
Azure Gateway Load Balancer	Trafiksymmetri garanteras utan SNAT. NVA:er kan delas mellan klienter. Den här lösningen har god konvergenstid och stöder aktiva/aktiva, aktiva/vänteläge och utskalningsbaserade NVA:er.	Den här lösningen stöder flöden till och från Internet och stöder inte East-West flöden.
Dynamisk privat IP-adress och UDR	NVA kräver inte särskilda funktioner. Den här lösningen garanterar symmetrisk trafik.	Den här lösningen är endast avsedd för aktiv/passiv design. Den har en hög konvergenstid på en till två minuter.

Lastbalanserare

Load Balancer-designen använder två Azure-lastbalanserare för att exponera ett kluster med NVA:er för resten av nätverket. Metoden passar både tillståndskänsliga och tillståndslösa NVA:er.

• En intern lastbalanserare omdirigerar intern trafik från Azure och lokalt till NVA:erna. Den här interna lastbalanseraren är konfigurerad med regler för portar med hög tillgänglighet så att varje TCP-port (Transmission Control Protocol) och UDP-port (User Datagram Protocol) omdirigeras till NVA-instanserna.

• En offentlig lastbalanserare exponerar NVA:erna för Internet. Portar med hög tillgänglighet gäller för inkommande trafik, så varje TCP/UDP-port måste öppnas i en dedikerad belastningsutjämningsregel.

Följande diagram visar sekvensen av hopp som paket tar från internet till en applikationsserver i ett virtuellt spoke-nätverk. Dessa paket passerar en brandväggs-NVA för att styra trafiken till och från internet, även kallad North-South-trafik.

Det här diagrammet visar en hubb och två ekrar. Hubben innehåller ett gateway-undernät och NVA-undernät. Gateway-undernätet innehåller en VPN- eller Azure ExpressRoute-gateway. NVA-undernätet innehåller en intern Azure-lastbalanserare och NVA:er. Varje eker innehåller en applikationsserver. Spoke2 har en anteckning som läser ekervägstabellen 0.0.0.0/0 till 10.0.0.36 och inaktiverar gatewayspridning. Inkommande trafik flödar från det offentliga Internet till NVA:erna via den offentliga Azure-lastbalanseraren. Den här trafiken flödar sedan till appservern i Spoke2. Returnera trafikflöden från den här appservern till NVA:erna via den interna Azure-lastbalanseraren. Den här trafiken flödar sedan till det offentliga Internet.

Ladda ned en Visio-fil med den här arkitekturen.

För att skicka trafik från ekrar till det offentliga internet via NVA:erna använder den här designen en UDR för 0.0.0.0/0. Nästa hopp är den interna lastbalanserarens IP-adress.

För trafik mellan Azure och det offentliga Internet korsar varje riktning av trafikflödet en annan Azure-lastbalanserare. Den här processen inträffar även om brandväggs-NVA har ett enda nätverkskort (NIC) för både offentliga och interna nätverk eftersom inkommande paket går via den offentliga Azure-lastbalanseraren och utgående paket går via den interna Azure-lastbalanseraren. Båda riktningarna i flödet går igenom olika lastbalanserare. Så om du behöver trafiksymmetri måste NVA-instanserna utföra SNAT för att locka till sig returtrafik och säkerställa trafiksymmetri. De flesta brandväggar kräver trafiksymmetri.

Följande diagram visar hur du använder samma lastbalanserardesign för att kontrollera trafiken mellan Azure och lokala nätverk, eller East-West trafik, som endast omfattar en intern lastbalanserare. Du kan också använda den här metoden för att skicka trafik mellan ekrar via NVA:erna.

Det här diagrammet visar en hubb och två ekrar. Hubben innehåller ett gateway-undernät och NVA-undernät. Gateway-undernätet innehåller en VPN- eller ExpressRoute-gateway. NVA-undernätet innehåller en intern Azure-lastbalanserare och NVA:er. Varje eker innehåller en applikationsserver. Spoke2 har en anteckning som läser ekervägstabellen 0.0.0.0/0 till 10.0.0.36 och inaktiverar gatewayspridning. Inkommande trafik flödar från lokalt till NVA:erna via VPN- eller ExpressRoute-gatewayen och sedan den interna Azure-lastbalanseraren. Den här trafiken flödar sedan till appservern i Spoke2. Returnera trafikflöden från den här appservern till NVA:erna via den interna Azure-lastbalanseraren. Den här trafiken flödar sedan till en lokal plats via VPN- eller ExpressRoute-gatewayen.

I de föregående diagrammen känner spoke1 inte till spoke2:s räckvidd. 0.0.0.0/0 Udr skickar därför trafik som är avsedd för spoke2 till NVA:s interna Azure-lastbalanserare.

För trafik mellan lokala nätverk och Azure, eller mellan virtuella Azure-datorer, garanteras trafiksymmetrin i enstaka nätverkskorts-NVA:er av den interna Azure-lastbalanseraren. När båda riktningarna för ett trafikflöde passerar samma Azure-lastbalanserare väljer lastbalanseraren samma NVA-instans för båda riktningarna. Om en NVA-design med dubbla nätverkskort har en intern lastbalanserare för varje kommunikationsriktning garanterar SNAT trafiksymmetri. Föregående North-South diagram innehåller ett exempel på den här designen.

I den här designen måste NVA:er med dubbla NIC:er avgöra var de ska skicka svaren på lastbalansarens hälsokontroller. Load Balancer använder alltid samma IP-adress som källan för hälsokontrollerna, som är 168.63.129.16. NVA måste skicka tillbaka dessa hälsokontrollsvar via samma gränssnitt som de togs emot på. Den här processen kräver vanligtvis flera routningstabeller i ett operativsystem eftersom målbaserad routning skickar svaren via samma nätverkskort.

Azure-lastbalanseraren har en bra konvergenstid vid enskilda NVA-avbrott. Du kan skicka hälsoavsökningar var femte sekund och det krävs tre misslyckade avsökningar för att deklarera att en serverdelsinstans är ur drift. Det tar därför vanligtvis 10 till 15 sekunder för Azure-lastbalanseraren att konvergera trafik till en annan NVA-instans.

Den här konfigurationen stöder både aktiva/aktiva och aktiva/väntelägeskonfigurationer. För aktiva/väntelägeskonfigurationer måste NVA-instanserna ange antingen en TCP- eller UDP-port eller en HTTP-slutpunkt som endast svarar på lastbalanserarens hälsoavsökningar för den instans som för närvarande är i den aktiva rollen.

Layer-7-lastbalanserare

En specifik design för säkerhetsinstallationer ersätter den offentliga Azure-lastbalanseraren med en Layer-7-lastbalanserare, till exempel Azure Application Gateway, som kan betraktas som en nva själv.

I det här scenariot kräver NVA:erna bara en intern lastbalanserare för trafik från arbetsbelastningssystemen. Dual-NIC enheter använder ibland den här metoden för att undvika routningsproblem med Azure-lastbalanserarens hälsokontroller. Den här designen stöder endast Layer-7-protokollen som Layer-7-lastbalanseraren stöder, vilket vanligtvis är HTTP och HTTPS.

NVA ska hantera inkommande trafik för protokoll som Layer-7-lastbalanseraren inte stöder. NVA kan också hantera utgående trafik. Mer information finns i Brandvägg och Application Gateway för virtuella nätverk.

Routserver

Route Server är en tjänst som gör det möjligt för en NVA att interagera med programvarudefinierade Azure-nätverk via BGP. NVA:er lär sig vilka IP-adressprefix som finns i virtuella Azure-nätverk. De kan också mata in vägar i de effektiva routningstabellerna för virtuella datorer i Azure.

Det här diagrammet visar en hubb och två ekrar. Hubben innehåller ett gatewayundernät, NVA-undernät och routningsserverundernät. Gateway-undernätet innehåller en VPN- eller ExpressRoute-gateway. NVA-undernätet innehåller två NVA:er. Routningsserverns undernät innehåller Routningsserver. Varje eker innehåller en applikationsserver. Spoke2 har en anteckning som säger "Spoke effektiva rutter 0.0.0.0/0 till 10.0.0.37 och 0.0.0.0/0 till 10.0.0.38." Inkommande trafik flödar från det offentliga Internet till NVA1 via den offentliga Azure-lastbalanseraren. Den här trafiken flödar sedan till appservern i Spoke2. Returnera trafikflöden från den här appservern till NVA1 och sedan till det offentliga Internet. BGP-anslutning förbinder NVA1, NVA2 och Route Server. NVA2 och Route Server är anslutna via eBGP.

I föregående diagram ansluter varje NVA-instans till Route Server via BGP. Den här designen kräver ingen routningstabell i ekerundernäten eftersom Route Server programmerar de vägar som NVA:erna annonserar. Om två eller flera vägar är programmerade på de virtuella Azure-datorerna använder de routning med samma kostnad för flera vägar för att välja en av NVA-instanserna för varje trafikflöde. Därför måste du inkludera SNAT i den här designen om du behöver trafiksymmetri.

Den här insättningsmetoden stöder både aktiva/aktiva och aktiva/väntelägeskonfigurationer. I en aktiv/aktiv konfiguration annonserar alla NVA:er samma vägar till Routningsservern. I en aktiv/väntelägeskonfiguration annonserar en NVA vägar med en kortare sökväg för autonomt system (AS) än den andra. Route Server stöder högst åtta BGP-adjacencies. Så om du använder ett utskalningskluster med aktiva NVA:er stöder den här designen högst åtta NVA-instanser.

Den här konfigurationen har en snabb konvergenstid. Keepalive- och holdtime-timrarna för BGP-anslutning påverkar konvergenstiden. Route Server har keepalive-timers inställda på 60 sekunder och holdtime-timers inställda på 180 sekunder. Men NVA:erna kan förhandla om lägre timers under BGP-angränsande etablering. Om du ställer in dessa timers för lågt kan det leda till BGP-instabilitet.

Den här designen passar NVA:er som behöver interagera med Azure-routning. Exempel är SD-WAN eller IPsec NVA:er, som vanligtvis har bra BGP-stöd. Dessa NVA:er behöver lära sig prefixen som konfigurerats i virtuella Azure-nätverk eller annonsera vissa rutter via privata ExpressRoute-peerings. Dessa typer av apparater är vanligtvis tillståndslösa, så trafiksymmetri utgör inget problem och SNAT behövs inte.

Gateway-belastningsutjämnare

Gateway Load Balancer är ett sätt att infoga NVA:er i datasökvägen utan att behöva dirigera trafik med hjälp av UDR. För virtuella datorer som exponerar sina arbetsbelastningar via en Azure-lastbalanserare eller en offentlig IP-adress kan du omdirigera inkommande och utgående trafik transparent till ett kluster med NVA:er som finns i ett annat virtuellt nätverk. Följande diagram visar den sökväg som paket följer för inkommande trafik från det offentliga Internet om arbetsbelastningarna exponerar programmet via en Azure-lastbalanserare.

Det här diagrammet visar ett virtuellt NVA-nätverk och ett virtuellt appnätverk. Det virtuella NVA-nätverket innehåller Gateway Load Balancer och NVAs. Det virtuella appnätverket innehåller en webbserver. Användarflödet går från Internet till webbservern via en offentlig Standard Azure-lastbalanserare. Flödet som styrs av Gateway Load Balancer går från den offentliga Standard Azure-lastbalanseraren till Gateway Load Balancer och sedan till NVA:erna. Det här flödet vänder riktningar och går från NVA:erna till Gateway Load Balancer och sedan till den offentliga Standard Azure-lastbalanseraren.

Den här NVA-inmatningsmetoden ger följande fördelar:

• Den här metoden kräver inte SNAT för att garantera trafiksymmetri.

• Du kan använda samma NVA:er för att inspektera trafik till och från olika virtuella nätverk, som möjliggör multitenans ur NVA-perspektivet.

• Virtuell nätverkssammanlänkning krävs inte mellan det virtuella NVA-nätverket och de virtuella arbetslatsnätverken, vilket förenklar konfigurationen.

• UDF:er krävs inte i det virtuella arbetsbelastningsnätverket, vilket också förenklar konfigurationen.

Du kan använda tjänstinmatning via Gateway Load Balancer för inkommande trafik till en offentlig Azure-lastbalanserare, dess returtrafik och utgående trafik från Azure. East-West trafik mellan virtuella Azure-datorer kan inte använda Gateway Load Balancer för NVA-inmatning.

Azure-lastbalanserarens hälsokontrollsonder identifierar fel i enskilda NVA-instanser i NVA-klustret, vilket ger en snabb konvergenstid på 10 till 15 sekunder.

Dynamisk offentlig IP-adress och UDR-hantering

Målet med den här designen är att ha en konfiguration som fungerar utan NVA-redundans och kan ändras om NVA upplever stilleståndstid. Följande diagram visar hur en offentlig IP-adress i Azure associeras med en aktiv NVA (NVA1 i diagrammet). UDR:erna i ekrarna använder den aktiva NVA:ns IP-adress (10.0.0.37) som nästa hopp.

Det här diagrammet visar en hubb och två ekrar. Hubben innehåller ett gateway-undernät och NVA-undernät. Gateway-undernätet innehåller en VPN- eller ExpressRoute-gateway. NVA-undernätet innehåller två NVA:er. NVA1 är märkt som aktiv och NVA2 är märkt som vänteläge. Varje eker innehåller en applikationsserver. Spoke2 har en anteckning som läser ekervägstabellen 0.0.0.0/0 till 10.0.0.37 och inaktiverar gatewayspridning. Inkommande trafik flödar från Internet till NVA1 via en offentlig IP-adress. Den här trafiken flödar sedan till Spoke2. Returnera trafikflöden från Spoke2 till NVA1 och sedan till Internet.

Om den aktiva NVA:n blir otillgänglig, anropar standby-NVA:n Azure-API:et för att remappa den offentliga IP-adressen och spoke-UDR:erna till standby-NVA:n eller ta över den privata IP-adressen. Dessa API-anrop kan ta flera minuter att vara effektiva. Den här designen ger den sämsta konvergenstiden bland alternativen i den här artikeln.

Den här designen stöder endast aktiva/väntelägeskonfigurationer, vilket kan leda till skalbarhetsproblem. Om du behöver öka bandbredden som dina NVA:er stöder måste du skala upp båda instanserna.

Den här designen kräver inte SNAT för att garantera trafiksymmetri eftersom endast en NVA är aktiv vid en viss tidpunkt.

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudsakliga författare:

• Keith Mayer | Huvudarkitekt för molnlösning
• Telmo Sampaio | Principal Service Engineering Manager
• Jose Moreno | Huvudtekniker

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

• Perimeternätverk

Relaterad resurs

• Implementera ett säkert hybridnätverk med hjälp av Azure Firewall