Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
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.
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.
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.
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.
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.
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.