NVA's met hoge beschikbaarheid implementeren

In dit artikel worden de meest voorkomende opties beschreven voor het implementeren van een set virtuele netwerkapparaten (NVA's) voor hoge beschikbaarheid in Azure. Een NVA wordt doorgaans gebruikt om de verkeersstroom tussen netwerksegmenten te beheren die zijn geclassificeerd met verschillende beveiligingsniveaus, bijvoorbeeld tussen een De-Militarized Zone (DMZ) Virtual Network en het openbare internet, of om externe locaties te verbinden met Azure, zoals VPN- of SDWAN- (Software-Defined WAN)-apparaten.

Er zijn veel ontwerppatronen waarbij NVA's worden gebruikt om verkeer tussen verschillende beveiligingszones te inspecteren, bijvoorbeeld:

• Uitgaand verkeer van virtuele machines naar internet controleren en exfiltratie van gegevens voorkomen.
• Om inkomend verkeer van internet naar virtuele machines te inspecteren en aanvallen te voorkomen.
• Als u verkeer tussen virtuele machines in Azure wilt filteren, voorkomt u laterale verplaatsingen van gecompromitteerde systemen.
• Als u verkeer wilt filteren tussen on-premises systemen en virtuele Azure-machines, als ze worden beschouwd als behorend tot verschillende beveiligingsniveaus. (Bijvoorbeeld als Azure als host fungeert voor de DMZ en on-premises de interne toepassingen.)
• Vpn- of SDWAN-tunnels beëindigen vanaf externe locaties, zoals on-premises netwerken of andere openbare clouds.

Er zijn veel voorbeelden van NVA's, waaronder de volgende:

• Netwerkfirewalls
• Reverse-proxy's in Laag 4
• IPsec VPN-eindpunten
• SDWAN-apparaten
• Omgekeerde proxy's op internet met webtoepassingsfirewallfunctionaliteit
• Internetproxy's om te beperken welke internetpagina's kunnen worden geopend vanuit Azure
• Load balancers voor laag 7

Al deze NVA's kunnen worden ingevoegd in een Azure-ontwerp met de patronen die in dit artikel worden beschreven. Zelfs virtuele netwerkapparaten van Azure van derden, zoals Azure Firewall en Azure Application Gateway de ontwerpen gebruiken die verderop in dit artikel worden uitgelegd. Inzicht in deze opties is zowel vanuit een ontwerpperspectief als bij het oplossen van netwerkproblemen essentieel.

De eerste vraag die moet worden beantwoord, is waarom hoge beschikbaarheid voor virtuele netwerkapparaten is vereist. De reden hiervoor is dat deze apparaten de communicatie tussen netwerksegmenten beheren. Als ze niet beschikbaar zijn, kan het netwerkverkeer niet stromen en werken toepassingen niet meer. Geplande en ongeplande storingen brengen af en toe NVA-exemplaren uit (zoals elke andere virtuele machine in Azure of een andere cloud). De exemplaren worden neergehaald, zelfs als deze NVA's zijn geconfigureerd met Premium Managed Disks om een SLA met één exemplaar in Azure te bieden. Daarom vereisen maximaal beschikbare toepassingen ten minste een tweede NVA die connectiviteit kan garanderen.

vereisten: in dit artikel wordt uitgegaan van basiskennis van Azure-netwerken, Azure Load Balancersen Virtual Network Traffic Routing (UDR's).

Wanneer u de beste optie kiest om een virtueel netwerkapparaat te implementeren in een Azure-VNet, is het belangrijkste aspect waarmee u rekening moet houden of de NVA-leverancier dat specifieke ontwerp heeft gecontroleerd en gevalideerd. De leverancier moet ook de vereiste NVA-configuratie opgeven die nodig is om de NVA te integreren in Azure. Als de NVA-leverancier verschillende alternatieven biedt als ondersteunde ontwerpopties voor een NVA, kunnen deze factoren van invloed zijn op de beslissing:

• Convergentietijd: hoe lang duurt het in elk ontwerp om het verkeer weg te sturen van een mislukt NVA-exemplaar?
• Topologieondersteuning: welke NVA-configuraties ondersteunt elke ontwerpoptie? Actief/actief, actief/stand-by NVA-clusters met n+1 redundantie?
• Verkeerssymmetrie: dwingt een bepaald ontwerp de NVA om SNAT (Source Network Address Translation) uit te voeren op de pakketten om asymmetrische routering te voorkomen? Of wordt verkeerssymmetrie op andere manieren afgedwongen?

In de volgende secties in het document worden de meest voorkomende architecturen beschreven die worden gebruikt om NVA's te integreren in een hub- en spoke-netwerk.

Overzicht van HA-architecturen

In de volgende architecturen worden de resources en configuratie beschreven die nodig zijn voor hoogbeschikbare NVA's.

Load Balancer-ontwerp

In dit ontwerp worden twee Azure Load Balancers gebruikt om een cluster met NVA's beschikbaar te maken voor de rest van het netwerk. De benadering wordt vaak gebruikt voor stateful en stateless NVA's:

• Een interne load balancer wordt gebruikt om intern verkeer van Azure en on-premises om te leiden naar de NVA's. Deze interne load balancer is geconfigureerd met regels voor HA-poorten, zodat elke TCP/UDP-poort wordt omgeleid naar de NVA-exemplaren.
• Een openbare load balancer maakt de NVA's beschikbaar op internet. Omdat HA-poorten voor binnenkomend verkeer zijn, moet elke afzonderlijke TCP/UDP-poort worden geopend in een toegewezen taakverdelingsregel.

In het volgende diagram wordt de volgorde beschreven van hops die pakketten van internet naar een toepassingsserver in een spoke-VNet volgen die een firewall-NVA doorkruist om verkeer van/naar het openbare internet te beheren (ook wel noord-/zuidverkeer genoemd):

Download een Visio-bestand van deze architectuur.

Het mechanisme voor het verzenden van verkeer van spokes naar het openbare internet via de NVA's is een User-Defined Route voor 0.0.0.0/0 met het IP-adres van de interne Load Balancer.

Voor verkeer tussen Azure en het openbare internet gaat elke richting van de verkeersstroom over een andere Azure Load Balancer. Dit gebeurt zelfs als de firewall NVA één NIC heeft voor zowel de openbare als interne netwerken, omdat het toegangsbeheerpakket via de openbare ALB gaat en het uitgaande pakket via de interne ALB gaat. Omdat beide richtingen van de stroom door verschillende load balancers lopen, als verkeerssymmetrie vereist is, zoals meestal het geval is bij de meeste firewalls, moet SNAT (Source Network Address Translation) worden uitgevoerd door de NVA-exemplaren om het retourverkeer aan te trekken en verkeersasymmetrie te voorkomen.

Hetzelfde ontwerp met load balancers kan ook worden gebruikt om verkeer tussen Azure- en on-premises netwerken (oost/west) te inspecteren, waarbij alleen een interne load balancer betrokken is:

Het mechanisme voor het verzenden van verkeer tussen spokes via de NVA's is precies hetzelfde, dus er is geen ander diagram beschikbaar. In de bovenstaande voorbeelddiagrammen, omdat spoke1 niet weet over het bereik van spoke2, verzendt de 0.0.0.0/0 UDR verkeer dat is geadresseerd aan spoke2, naar de interne Azure Load Balancer van de NVA.

Voor verkeer tussen on-premises netwerken en Azure of tussen virtuele Azure-machines wordt verkeerssymmetrie gegarandeerd in NVA's met één NIC door de interne Azure Load Balancer: wanneer beide richtingen van een verkeersstroom dezelfde Azure Load Balancer doorkruisen, wordt hetzelfde NVA-exemplaar gekozen door de load balancer. In het geval van NVA's met dubbele NIC's waarbij er een interne load balancer is voor elke zin van de communicatie, moet de verkeerssymmetrie worden verstrekt via SNAT, zoals in het bovenstaande voorbeeld noord/zuid.

Een andere uitdaging waarmee NVA's met twee NIC's te maken krijgen in dit ontwerp, is waar de antwoorden naar de statuscontroles van de load balancer moeten worden teruggestuurd. Azure Load Balancer gebruikt altijd hetzelfde IP-adres als de bron voor de statuscontroles (168.63.129.16). De NVA moet het antwoord kunnen verzenden naar de bron van de statuscontrole van dit IP-adres op dezelfde interface die ze hebben ontvangen. Hiervoor zijn doorgaans meerdere routeringstabellen in een besturingssysteem vereist, omdat op doel gebaseerde routering het antwoord naar de statuscontroles altijd via dezelfde NIC zou verzenden.

De Azure Load Balancer heeft een goede convergentietijd in afzonderlijke NVA-storingen. Omdat de statustests elke 5 seconden kunnen worden verzonden en er drie mislukte tests nodig zijn om een back-endexemplaren buiten de service te declareren, duurt het meestal 10-15 seconden voordat de Azure Load Balancer verkeer naar een ander NVA-exemplaar convergeert.

Deze installatie ondersteunt zowel actieve/actieve als actieve/stand-byconfiguraties. Voor actieve/stand-byconfiguraties moeten de NVA-exemplaren een TCP/UDP-poort of HTTP-eindpunt aanbieden dat alleen reageert op de statustests van de Load Balancer voor het exemplaar dat zich in de actieve rol bevindt.

L7 load balancers gebruiken

Een bepaald geval van dit ontwerp voor beveiligingsapparaten is het vervangen van de openbare Azure Load Balancer door een load balancer van Laag-7, zoals de Azure Application Gateway- (die als een NVA afzonderlijk kunnen worden beschouwd). In dit geval vereisen de NVA's alleen een interne Load Balancer voor verkeer dat afkomstig is van de workloadsystemen. Dit mechanisme wordt soms gebruikt door dual-NIC-apparaten om het routeringsprobleem te voorkomen met de statuscontroles van de Azure Load Balancer die in de vorige sectie worden beschreven. Een beperking van dit ontwerp is dat het alleen ondersteuning biedt voor de Layer-7-protocollen die worden ondersteund door de Load Balancer layer-7, meestal HTTP(S).

De NVA moet binnenkomend verkeer opnemen voor protocollen die niet worden ondersteund door uw Layer-7-load balancer, plus mogelijk al het uitgaand verkeer. Zie Firewall en Application Gateway voor virtuele netwerkenvoor meer informatie over deze configuratie bij het gebruik van Azure Firewall als NVA en Azure Application Gateway als reverse-proxy voor layer-7 web.

Azure Route Server

Azure Route Server is een service waarmee een NVA kan communiceren met Azure SDN via Border Gateway Protocol (BGP). Niet alleen leren de NVA's welke IP-voorvoegsels bestaan in de Azure-VNets, maar ze kunnen routes injecteren in de effectieve routetabellen van de virtuele machines in Azure.

In het bovenstaande diagram wordt elk NVA-exemplaar gekoppeld via BGP met de Azure Route Server. Er is geen routetabel vereist in de spoke-subnetten, omdat Azure Route Server de routes programma's die door de NVA's worden geadverteerd. Als twee of meer routes worden geprogrammeerd in de virtuele Azure-machines, gebruiken ze ECMP (Equal Cost MultiPathing) om een van de NVA-exemplaren te kiezen voor elke verkeersstroom. Als gevolg hiervan is SNAT een must in dit ontwerp als verkeerssymmetrie een vereiste is.

Deze invoegmethode ondersteunt zowel actief/actief (alle NVA's adverteren dezelfde routes naar de Azure Route Server) als actief/stand-by (één NVA adverteert routes met een korter AS-pad dan het andere). De Azure Route Server ondersteunt maximaal 8 BGP-aangrenzingen. Als u dus een scale-outcluster met actieve NVA's gebruikt, ondersteunt dit ontwerp maximaal 8 NVA-exemplaren.

Convergentietijd is snel in deze installatie en wordt beïnvloed door de keepalive- en holdtime-timers van de BGP-aangrenzing. Hoewel de Azure Route Server standaard keepalive- en holdtime-timers heeft (respectievelijk 60 seconden en 180 seconden), kunnen de NVA's lagere timers onderhandelen tijdens de aangrenzingsinstelling van BGP. Als u deze timers te laag instelt, kan dit leiden tot instabiliteit van BGP.

Dit ontwerp is de meest voorkomende optie voor NVA's die moeten communiceren met Azure-routering, bijvoorbeeld SDWAN- of IPsec-NVA's die doorgaans goede BGP-ondersteuning hebben en de voorvoegsels moeten leren die zijn geconfigureerd in Azure VNets, of bepaalde routes adverteren via persoonlijke ExpressRoute-peerings. Dit type apparaten is meestal staatloos, zodat verkeerssymmetrie geen probleem is en dus is SNAT niet vereist.

Gateway Load Balancer

Azure Gateway Load Balancer is een nieuwe manier om NVA's in het gegevenspad in te voegen zonder dat u verkeer hoeft te sturen met User-Defined Routes. Voor virtuele machines die hun workloads beschikbaar maken via een Azure Load Balancer of een openbaar IP-adres, kan binnenkomend en uitgaand verkeer transparant worden omgeleid naar een cluster met NVA's in een ander VNet. In het volgende diagram wordt het pad beschreven dat pakketten volgen voor inkomend verkeer vanaf het openbare internet, voor het geval de workloads de toepassing beschikbaar maken via een Azure Load Balancer:

Een van de belangrijkste voordelen van deze NVA-injectiemethode is dat Source Network Address Translation (SNAT) niet is vereist om verkeerssymmetrie te garanderen. Een ander voordeel van deze ontwerpoptie is dat dezelfde NVA's kunnen worden gebruikt om verkeer naar/van verschillende VNets te inspecteren, waardoor multitenancy vanuit het NVA-perspectief wordt bereikt. Er is geen VNet-peering vereist tussen het NVA-VNet en de workload-VNets en er zijn geen User-Defined routes vereist in het workload-VNet, wat de configuratie aanzienlijk vereenvoudigt.

Service-injectie met de Gateway Load Balancer kan worden gebruikt voor inkomende stromen die een openbare Azure Load Balancer (en hun retourverkeer) raken, en voor uitgaande stromen die afkomstig zijn uit Azure. East-West verkeer tussen virtuele Azure-machines kan geen gebruik maken van de Gateway Load Balancer voor NVA-injectie.

In het NVA-cluster worden statuscontroles van Azure Load Balancer gebruikt om fouten in afzonderlijke NVA-exemplaren te detecteren, waardoor een snelle convergentietijd (10-15 seconden) wordt bereikt.

PIP-UDR wijzigen

Het idee achter dit ontwerp is het instellen dat vereist is zonder NVA-redundantie en het moet worden gewijzigd voor het geval de NVA uitvaltijd ondervindt. In het onderstaande diagram ziet u hoe een openbaar IP-adres van Azure is gekoppeld aan de actieve NVA (NVA1) en de User-Defined Routes in de spokes het actieve IP-adres van de NVA hebben als volgende hop (10.0.0.37).

Als de actieve NVA niet beschikbaar was, roept de stand-by NVA de Azure-API aan om het openbare IP-adres en de spoke-User-Defined Routes naar zichzelf te verplaatsen (of het privé-IP-adres ook te verplaatsen). Het kan enkele minuten duren voordat deze API-aanroepen effectief zijn. Daarom biedt dit ontwerp de slechtste convergentietijd van alle opties in dit document.

Een andere beperking van dit ontwerp is dat alleen actieve/stand-byconfiguraties worden ondersteund, wat kan leiden tot schaalbaarheidsproblemen: als u de bandbreedte wilt verhogen die wordt ondersteund door uw NVA's, is de enige optie met dit ontwerp het omhoog schalen van beide exemplaren.

Een voordeel van dit ontwerp is dat er geen SNAT (Source Network Address Translation) nodig is om verkeerssymmetrie te garanderen, omdat er op een bepaald moment slechts één NVA actief is.

Bijdragers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteurs:

• Keith Mayer | Principal Cloud Solution Architect
• Telmo Sampaio | Principal Service Engineering Manager
• Jose Moreno- | Hoofdtechnicus

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Meer informatie over het implementeren van een beveiligd hybride netwerk met behulp van Azure Firewall.
• perimeternetwerken - Cloud Adoption Framework-
• Cloud DMZ - Cloud Adoption Framework