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 dmz-nätverk (De-Militarized Zone) och det offentliga Internet.
Det finns ett antal 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.)
Det finns många exempel på NVA:er, till exempel nätverksbrandväggar, Layer-4 omvända proxyservrar, IPsec VPN-slutpunkter, 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 och många andra. Alla 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änder designerna som beskrivs senare i den här artikeln. Att förstå dessa alternativ ä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 kan och kommer ibland att ta bort NVA-instanser (som alla 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 Balancers och 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?
Följande avsnitt i dokumentet beskriver de vanligaste arkitekturerna som används för att integrera NVA:er i ett hubb- och ekernätverk.
Kommentar
Den här artikeln fokuserar på hubb- och ekerdesign. Virtual WAN omfattas inte eftersom Virtual WAN är mycket mer normativt för hur NVA:er distribueras, beroende på om en specifik NVA stöds i Virtual WAN-hubbarna. Mer information finns i Virtuella nätverksinstallationer i Virtual WAN-hubben .
Översikt över HA-arkitekturer
Följande arkitekturer beskriver de resurser och den konfiguration som krävs för NVA med hög tillgänglighet:
| Lösning | Förmåner | Att tänka på |
|---|---|---|
| Azure Load Balancer | Stöder aktiva/aktiva, aktiva/vänteläges- och skalbara NVA:er. Mycket bra konvergenstid | NVA måste tillhandahålla en port för hälsoavsökningarna, särskilt för aktiva/väntelägesdistributioner. Flöden till/från Internet kräver SNAT för symmetri |
| Azure Route Server | NVA måste ha stöd för BGP. Stöder aktiva/aktiva, aktiva/vänteläges- och skalbara NVA:er. | Trafiksymmetri kräver SNAT |
| Gateway Load Balancer | Trafiksymmetri garanteras utan SNAT. NVA:er kan delas mellan klienter. Mycket bra konvergenstid. Stöder aktiva/aktiva, aktiva/vänteläges- och skalbara NVA:er. | Stöder flöden till/från Internet, inga öst-väst-flöden |
| Ändra PIP/UDR | Ingen särskild funktion krävs av NVA. Garanterar symmetrisk trafik | Endast för aktiv/passiv design. Hög konvergenstid på 1–2 minuter |
Load Balancer-design
Den här designen använder två Azure Load Balancers för att exponera ett kluster med NVA:er för resten av nätverket:
- En intern lastbalanserare används för att omdirigera intern trafik från Azure och lokalt till NVA:erna. Den här interna lastbalanseraren är konfigurerad 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:
Ladda ned en Visio-fil med den här arkitekturen.
Mekanismen för att skicka trafik från ekrar till det offentliga Internet via NVA:erna är en användardefinierad väg 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 kommer varje riktning i trafikflödet att korsa en annan Azure Load Balancer (inkommande paket via den offentliga ALB och utgående paket via den interna ALB). Om trafiksymmetri krävs måste därför SNAT (Source Network Address Translation) utföras av NVA-instanserna för att locka till sig returtrafiken och undvika trafikasymmetri.
Den här designen kan även användas för att inspektera trafik mellan Azure och lokala nätverk:
Mekanismen för att skicka trafik mellan ekrar via NVA:erna är exakt densamma, så det finns inget ytterligare diagram. I exempeldiagrammen ovan, eftersom spoke1 inte känner till spoke2-intervallet, 0.0.0.0/0 skickar 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 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.
Azure Load Balancer har en mycket bra konvergenstid vid enskilda NVA-avbrott. Eftersom hälsoavsökningarna 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 dock erbjuda en TCP/UDP-port eller HTTP-slutpunkt som inte svarar på Lastbalanserarens hälsoavsökningar om inte instansen är i den aktiva rollen.
Använda L7-lastbalanserare
Ett särskilt fall av den här designen ä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 framför dem, eftersom trafik från Application Gateway kommer att hämtas inifrån det virtuella nätverket och trafikasymmetri inte är ett problem.
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 Brandvägg 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). Inte bara NVA:erna får lära sig vilka IP-prefix som finns i de virtuella Azure-nätverken, utan de kommer att kunna 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 är programmerade 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) samt 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 högst 8 NVA-instanser.
Konvergenstiden är ganska 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 VPN-avslutnings-NVA:er som behöver lära sig prefixen som konfigurerats i virtuella Azure-nätverk eller annonsera vissa vägar via privata ExpressRoute-peerings.
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 användardefinierade 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 användardefinierade 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) samt för utgående flöden med ursprung i Azure. Trafik mellan virtuella Azure-datorer i öst-väst 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 mycket 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 de användardefinierade vägarna 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 de användardefinierade ekervägarna 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.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudsakliga författare:
- Keith Mayer | Huvudarkitekt för molnlösning
- Telmo Sampaio | Principal Service Engineering Manager
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.
Nästa steg
- Lär dig hur du implementerar ett säkert hybridnätverk med Hjälp av Azure Firewall.
- Perimeternätverk – Cloud Adoption Framework
- Cloud DMZ – Cloud Adoption Framework