Distribuera NVA:er med hög tillgänglighet

Den här artikeln förklarar de vanligaste alternativen för att distribuera en uppsättning virtuella nätverksinstallationer (NVA) för hög tillgänglighet i Azure. En NVA används vanligtvis för att styra trafikflödet mellan nätverkssegment som klassificerats med olika säkerhetsnivåer, till exempel mellan ett virtuellt De-Militarized zone (DMZ) och det offentliga Internet, eller för att ansluta externa platser till Azure, till exempel VPN- eller SDWAN-apparater (Software-Defined WAN).

Det finns många designmönster där NVA:erna används för att inspektera trafik mellan olika säkerhetszoner, till exempel:

• 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.
• För att filtrera trafik mellan virtuella datorer i Azure för att förhindra laterala flyttningar av komprometterade system.
• Om du vill filtrera trafik mellan lokala system och virtuella Azure-datorer, om de anses tillhöra olika säkerhetsnivåer. (Om Azure till exempel är värd för DMZ och lokala interna program.)
• Så här avslutar du VPN- eller SDWAN-tunnlar från externa platser, till exempel lokala nätverk eller andra offentliga moln.

Det finns många exempel på NVA:ar, bland annat följande:

• Nätverksbrandväggar
• Layer-4 omvända proxyservrar
• IPsec VPN-slutpunkter
• SDWAN-apparater
• Webbaserade omvända proxyservrar med brandväggsfunktioner för webbprogram
• Internetproxy för att begränsa vilka internetsidor som kan nås från Azure
• Layer-7-lastbalanserare

Alla dessa NVA:er kan infogas i en Azure-design med de mönster som beskrivs i den här artikeln. Även virtuella nätverksinstallationer från första part i Azure, till exempel Azure Firewall och Azure Application Gateway, använda designerna som beskrivs senare i den här artikeln. Att förstå de här alternativen är viktigt både ur ett designperspektiv och när du felsöker nätverksproblem.

Den första frågan som ska besvaras är varför hög tillgänglighet för virtuella nätverksinstallationer krävs. Orsaken är att dessa enheter styr kommunikationen mellan nätverkssegment. Om de inte är tillgängliga kan nätverkstrafiken inte flöda och programmen slutar fungera. Schemalagda och oplanerade avbrott kommer ibland att ta bort NVA-instanser (som andra virtuella datorer i Azure eller något annat moln). Instanserna tas bort även om dessa NVA:er har konfigurerats med Premium Managed Disks för att tillhandahålla ett serviceavtal med en enda instans i Azure. Därför kräver program med hög tillgänglighet minst en andra NVA som kan säkerställa anslutningen.

Förutsättningar: Den här artikeln förutsätter en grundläggande förståelse för Azure-nätverk, Azure Load Balancersoch Routning av virtuell nätverkstrafik (UDR).

När du väljer det bästa alternativet för att distribuera en virtuell nätverksinstallation till ett virtuellt Azure-nätverk är det viktigaste att tänka på om NVA-leverantören har granskat och verifierat den specifika designen. Leverantören måste också tillhandahålla den NVA-konfiguration som krävs för att integrera NVA i Azure. Om NVA-leverantören erbjuder olika alternativ som designalternativ som stöds för en NVA kan dessa faktorer påverka beslutet:

• Konvergenstid: hur lång tid tar det för varje design att styra trafiken bort från en misslyckad NVA-instans?
• Topologistöd: vilka NVA-konfigurationer stöder varje designalternativ? Aktiva/aktiva, aktiva/vänteläge, skalbara NVA-kluster med n+1 redundans?
• Trafiksymmetri: tvingar en viss design NVA att utföra SNAT (Source Network Address Translation) på paketen för att undvika asymmetrisk routning? Eller tillämpas trafiksymmetrin på annat sätt?

I följande avsnitt i dokumentet beskrivs de vanligaste arkitekturerna som används för att integrera NVA:er i ett hubb- och ekernätverk.

Översikt över HA-arkitekturer

Följande arkitekturer beskriver de resurser och den konfiguration som krävs för nva:er med hög tillgänglighet:

Load Balancer-design

Den här designen använder två Azure Load Balancers för att exponera ett kluster av NVA:er för resten av nätverket. Metoden används ofta både för tillståndskänsliga och tillståndslösa NVA:er:

• En intern lastbalanserare används för att omdirigera intern trafik från Azure och lokalt till NVA:erna. Den här interna lastbalanseraren har konfigurerats med HA-portregler, så att varje TCP/UDP-port omdirigeras till NVA-instanserna.
• En offentlig lastbalanserare exponerar NVA:erna för Internet. Eftersom HA-portar är för inkommande trafik måste varje enskild TCP/UDP-port öppnas i en dedikerad belastningsutjämningsregel.

Följande diagram beskriver sekvensen av hopp som paket från Internet till en programserver i ett virtuellt ekernätverk skulle följa genom att gå igenom en brandväggs-NVA för att styra trafik till/från det offentliga Internet (kallas även nord-/sydtrafik):

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

Mekanismen för att skicka trafik från ekrar till det offentliga Internet via NVA:erna är en User-Defined Route för 0.0.0.0/0 med nästa hopp den interna Lastbalanserarens IP-adress.

För trafik mellan Azure och det offentliga Internet korsar varje riktning av trafikflödet en annan Azure Load Balancer. Detta inträffar även om brandväggs-NVA har ett enda nätverkskort för både offentliga och interna nätverk, eftersom inkommande paket går igenom den offentliga ALB och utgående paket går igenom den interna ALB. Eftersom båda riktningarna för flödet som går genom olika lastbalanserare, om trafiksymmetri krävs, vilket vanligtvis är fallet i de flesta brandväggar, måste SNAT (Source Network Address Translation) utföras av NVA-instanserna för att locka returtrafiken och undvika trafikasymmetri.

Samma design med lastbalanserare kan också användas för att inspektera trafik mellan Azure och lokala nätverk (öst/väst), där endast en intern lastbalanserare ingår:

Mekanismen för att skicka trafik mellan ekrar via NVA:erna är exakt densamma, så inget annat diagram tillhandahålls. I exempeldiagrammen ovan, eftersom spoke1 inte känner till spoke2-intervallet, skickar 0.0.0.0/0 UDR trafik adresserad till spoke2 till NVA:s interna Azure Load Balancer.

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 Load Balancer: när båda riktningarna för ett trafikflöde passerar samma Azure Load Balancer väljs samma NVA-instans av lastbalanseraren. När det gäller nva:er med dubbla nätverkskort där det finns en intern lastbalanserare för varje kommunikationskänsla måste trafiksymmetrin tillhandahållas via SNAT som i exemplet Nord/Syd ovan.

En annan utmaning som NVA:er med dubbla nätverkskort står inför i den här designen är var svaren ska skickas tillbaka till lastbalanserarens hälsokontroller. Azure Load Balancer använder alltid samma IP-adress som källa för hälsokontrollerna (168.63.129.16). NVA måste kunna skicka svaret till hälsokontrollens källa från den här IP-adressen i samma gränssnitt som de togs emot. Detta kräver vanligtvis flera routningstabeller i ett operativsystem, eftersom målbaserad routning alltid skickar svaret till hälsokontrollerna via samma nätverkskort.

Azure Load Balancer har en bra konvergenstid vid enskilda NVA-avbrott. Eftersom hälsoavsökningar kan skickas var 5:e sekund och det tar tre misslyckade avsökningar att deklarera en serverdelsinstans ur tjänst, tar det vanligtvis 10–15 sekunder för Azure Load Balancer 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 erbjuda en TCP/UDP-port eller HTTP-slutpunkt som endast svarar på Load Balancer-hälsoavsökningarna för den instans som är i den aktiva rollen.

Använda L7-lastbalanserare

Ett särskilt fall av den här designen för säkerhetsinstallationer är att ersätta den offentliga Lastbalanseraren i Azure med en Layer-7-lastbalanserare, till exempel Azure Application Gateway- (som kan betraktas som en NVA på egen hand). I det här fallet kräver nva:erna bara en intern lastbalanserare för trafik som kommer från arbetsbelastningssystemen. Den här mekanismen används ibland av enheter med dubbla nätverkskort för att undvika routningsproblemet med Azure Load Balancers hälsokontroller som beskrivs i föregående avsnitt. En begränsning i den här designen är att den endast stöder Layer-7-protokollen som stöds av Layer-7-lastbalanseraren, vanligtvis HTTP(S).

NVA bör ta inkommande trafik för protokoll som inte stöds av din Layer-7-lastbalanserare, plus potentiellt all utgående trafik. Mer information om den här konfigurationen när du använder Azure Firewall som NVA och Azure Application Gateway som Layer-7 web reverse-proxy finns i Firewall och Application Gateway för virtuella nätverk.

Azure Route Server

Azure Route Server är en tjänst som gör att en NVA kan interagera med Azure SDN via Border Gateway Protocol (BGP). Nva:erna lär sig inte bara vilka IP-prefix som finns i de virtuella Azure-nätverken, utan de kan inte bara mata in vägar i de effektiva routningstabellerna för de virtuella datorerna i Azure.

I diagrammet ovan peerkopplas varje NVA-instans över BGP med Azure Route Server. Ingen routningstabell krävs i ekerundernäten, eftersom Azure Route Server programmerar de vägar som annonseras av NVA:erna. Om två eller flera vägar programmeras på de virtuella Azure-datorerna använder de EcMP (Equal Cost MultiPathing) för att välja en av NVA-instanserna för varje trafikflöde. Därför är SNAT ett måste i den här designen om trafiksymmetri är ett krav.

Den här insättningsmetoden stöder både aktiv/aktiv (alla NVA:er annonserar samma vägar till Azure Route Server) och aktiv/vänteläge (en NVA annonserar vägar med en kortare AS-sökväg än den andra). Azure Route Server stöder högst 8 BGP-adjacencies. Om du använder ett utskalningskluster med aktiva NVA:er stöder den här designen därför högst 8 NVA-instanser.

Konvergenstiden är snabb i den här konfigurationen och påverkas av keepalive- och holdtime-timers för BGP-angränsande. Medan Azure Route Server har standardtimers för keepalive och holdtime (60 sekunder respektive 180 sekunder), kan NVA:erna förhandla om lägre timers under BGP-angränsande etableringen. Om du ställer in dessa timers för lågt kan det leda till BGP-instabilitet.

Den här designen är det vanligaste alternativet för NVA:er som behöver interagera med Azure-routning, till exempel SDWAN eller IPsec NVA:er som vanligtvis har bra BGP-stöd och behöver lära sig prefixen som konfigurerats i virtuella Azure-nätverk eller annonsera vissa vägar via privata ExpressRoute-peerings. Den här typen av apparater är vanligtvis tillståndslös, så att trafiksymmetri inte är ett problem och därför krävs inte SNAT.

Gateway Load Balancer

Azure Gateway Load Balancer är ett nytt sätt att infoga NVA:er i datasökvägen utan att behöva styra trafik med User-Defined Vägar. För virtuella datorer som exponerar sina arbetsbelastningar via en Azure Load Balancer eller en offentlig IP-adress kan inkommande och utgående trafik omdirigeras transparent till ett kluster med NVA:er som finns i ett annat VNet. I följande diagram beskrivs den sökväg som paket följer för inkommande trafik från det offentliga Internet om arbetsbelastningarna exponerar programmet via en Azure Load Balancer:

En av de största fördelarna med den här NVA-inmatningsmetoden är att SNAT (Source Network Address Translation) inte krävs för att garantera trafiksymmetri. En annan fördel med det här designalternativet är att samma NVA:er kan användas för att inspektera trafik till/från olika virtuella nätverk, vilket ger flera klientorganisationer ur NVA-perspektivet. Ingen VNet-peering krävs mellan det virtuella NVA-nätverket och de virtuella arbetsbelastningsnätverken, och inga User-Defined vägar krävs i det virtuella arbetsbelastningsnätverket, vilket avsevärt förenklar konfigurationen.

Tjänstinmatning med Gateway Load Balancer kan användas för inkommande flöden som når en offentlig Lastbalanserare i Azure (och deras returtrafik) och för utgående flöden med ursprung i Azure. East-West trafik mellan virtuella Azure-datorer kan inte utnyttja Gateway Load Balancer för NVA-inmatning.

I NVA-klustret används Hälsokontrollavsökningar i Azure Load Balancer för att identifiera enskilda NVA-instansfel, vilket ger en snabb konvergenstid (10–15 sekunder).

Ändra PIP-UDR

Tanken bakom den här designen är att ha den konfiguration som skulle krävas utan NVA-redundans och få den ändrad om NVA skulle drabbas av stilleståndstid. Diagrammet nedan visar hur en offentlig IP-adress i Azure är associerad med den aktiva NVA (NVA1) och User-Defined Routes i ekrarna har den aktiva NVA:ns IP-adress som nästa hopp (10.0.0.37).

Om den aktiva NVA:n blev otillgänglig anropar standby-NVA Azure-API:et för att mappa om den offentliga IP-adressen och ekern User-Defined Vägar till sig själv (eller flytta även den privata IP-adressen). Dessa API-anrop kan ta några minuter att vara effektiva, vilket är anledningen till att den här designen erbjuder den sämsta konvergenstiden för alla alternativ i det här dokumentet.

En annan begränsning i den här designen är att endast aktiva/väntelägeskonfigurationer stöds, vilket kan leda till skalbarhetsproblem: om du behöver öka bandbredden som stöds av dina NVA:er är det enda alternativet med den här designen att skala upp båda instanserna.

En fördel med den här designen är att ingen SNAT (Source Network Address Translation) krävs för att garantera trafiksymmetri, eftersom det bara finns en NVA aktiv vid en viss tidpunkt.

Bidragsgivare

Den här artikeln underhålls av Microsoft. Texten skrevs ursprungligen av följande bidragsgivare.

Huvudsakliga författare:

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

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Lär dig hur du implementera ett säkert hybridnätverk med hjälp av Azure Firewall.
• perimeternätverk – Cloud Adoption Framework
• Cloud DMZ – Cloud Adoption Framework