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 DMZ-virtueel netwerk (De-Forestized Zone) en het openbare internet.
Er zijn een aantal 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.)
Er zijn veel voorbeelden van NVA's, zoals netwerkfirewalls, Layer-4 reverse-proxy's, IPsec VPN-eindpunten, webgebaseerde reverseproxy's met webtoepassingsfirewallfunctionaliteit, internetproxy's om te beperken welke internetpagina's kunnen worden geopend vanuit Azure, Layer-7 load balancers en vele andere. Ze kunnen allemaal 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-toepassing Gateway, gebruiken de ontwerpen 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 kunnen en zullen af en toe NVA-exemplaren uitvallen (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 ervan uitgegaan dat u basiskennis hebt van Azure-netwerken, Azure Load Balancers en UDR's (Virtual Network Traffic Routing ).
Wanneer u de beste optie kiest om een virtueel netwerkapparaat te implementeren in een Azure-VNet, is het belangrijkste aspect om te overwegen 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.
Notitie
Dit artikel is gericht op Hub & Spoke-ontwerpen. Virtual WAN wordt niet behandeld, omdat Virtual WAN veel meer prescriptief is voor de implementatie van NVA's, afhankelijk van of een specifieke NVA wordt ondersteund in de Virtual WAN-hubs. Zie Virtuele netwerkapparaten in de Virtual WAN-hub voor meer informatie.
Overzicht van HA-architecturen
De volgende architecturen beschrijven de resources en configuratie die nodig zijn voor NVA's met een hoge beschikbaarheid:
| Oplossing | Vergoedingen | Overwegingen |
|---|---|---|
| Azure-belastingsverdeling | Ondersteunt actieve/actieve, actieve/stand-by- en scale-out NVA's. Zeer goede convergentietijd | De NVA moet een poort bieden voor de statustests, met name voor actieve/stand-by-implementaties. Stromen naar/van internet vereisen SNAT voor symmetrie |
| Azure Route Server | De NVA moet BGP ondersteunen. Ondersteunt actieve/actieve, actieve/stand-by- en scale-out NVA's. | Voor verkeerssymmetrie is SNAT vereist |
| Gateway Load Balancer | Verkeerssymmetrie gegarandeerd zonder SNAT. NVA's kunnen worden gedeeld tussen tenants. Zeer goede convergentietijd. Ondersteunt actieve/actieve, actieve/stand-by- en scale-out NVA's. | Ondersteunt stromen van/naar internet, geen oost-west-stromen |
| PIP/UDR wijzigen | Er is geen speciale functie vereist voor de NVA. Garandeert symmetrisch verkeer | Alleen voor actieve/passieve ontwerpen. Hoge convergentietijd van 1-2 minuten |
Load Balancer-ontwerp
In dit ontwerp worden twee Azure Load Balancers gebruikt om een cluster van NVA's beschikbaar te maken voor de rest van het netwerk:
- 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 ha-poortenregels, 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 zouden volgen:
Een Visio-bestand van deze architectuur downloaden.
Het mechanisme voor het verzenden van verkeer van spokes naar het openbare internet via de NVA's is een door de gebruiker gedefinieerde route voor 0.0.0.0/0 met de volgende hop het IP-adres van de interne Load Balancer.
Voor verkeer tussen Azure en het openbare internet kruist elke richting van de verkeersstroom een andere Azure Load Balancer (het ingangspakket via de openbare ALB en het uitgaande pakket via de interne ALB). Als verkeerssymmetrie vereist is, moet SNAT (Source Network Address Translation) worden uitgevoerd door de NVA-exemplaren om het retourverkeer aan te trekken en verkeerssymmetrie te voorkomen.
Dit ontwerp kan ook worden gebruikt om verkeer tussen Azure- en on-premises netwerken te inspecteren:
Het mechanisme voor het verzenden van verkeer tussen spokes via de NVA's is precies hetzelfde, dus er wordt geen extra diagram opgegeven. In de bovenstaande voorbeelddiagrammen, omdat spoke1 niet weet over het bereik van spoke2, stuurt 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 door de interne Azure Load Balancer: wanneer beide richtingen van een verkeersstroom dezelfde Azure Load Balancer doorlopen, wordt hetzelfde NVA-exemplaar gekozen.
De Azure Load Balancer heeft een zeer goede convergentietijd in geval van 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 echter een TCP/UDP-poort of HTTP-eindpunt bieden dat niet reageert op de statustests van de Load Balancer, tenzij het exemplaar de actieve rol heeft.
L7 load balancers gebruiken
Een bepaald geval van dit ontwerp is het vervangen van de openbare Load Balancer van Azure door een load balancer van Laag-7, zoals de Azure-toepassing-gateway (die als een NVA zelfstandig kan worden beschouwd). In dit geval hebben de NVA's alleen een interne Load Balancer nodig, omdat verkeer van de Application Gateway afkomstig is van binnen het VNet en asymmetrie van verkeer geen probleem is.
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 netwerken voor meer informatie over deze configuratie bij het gebruik van Azure Firewall als NVA en Azure-toepassing 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 de NVA's leren welke IP-voorvoegsels aanwezig zijn 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 programmeert die door de NVA's worden geadverteerd. Als twee of meer routes zijn geprogrammeerd in de virtuele Azure-machines, gebruiken ze Equal Cost MultiPathing (ECMP) 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 de andere). De Azure Route Server ondersteunt maximaal 8 BGP-aangrenzingen. Als u daarom een scale-outcluster met actieve NVA's gebruikt, biedt dit ontwerp ondersteuning voor maximaal 8 NVA-exemplaren.
Convergentietijd is vrij 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 NVA's voor VPN-beëindiging die de voorvoegsels moeten leren die zijn geconfigureerd in Azure VNets, of bepaalde routes moeten adverteren via persoonlijke ExpressRoute-peerings.
Gateway Load Balancer
Azure Gateway Load Balancer is een nieuwe manier om NVA's in het gegevenspad in te voegen zonder verkeer te hoeven sturen met door de gebruiker gedefinieerde 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-VNet(s) en er zijn geen door de gebruiker gedefinieerde 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, evenals voor uitgaande stromen die afkomstig zijn uit Azure. Oost-west-verkeer tussen virtuele Azure-machines kan geen gebruikmaken van de Gateway Load Balancer voor NVA-injectie.
In het NVA-cluster worden statuscontroletests van Azure Load Balancer gebruikt om fouten in afzonderlijke NVA-exemplaren te detecteren, waardoor een zeer 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 Azure-IP-adres is gekoppeld aan de actieve NVA (NVA1) en de door de gebruiker gedefinieerde 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 door de gebruiker gedefinieerde spokeroutes opnieuw toe te kennen (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.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Belangrijkste auteurs:
- Keith Mayer | Principal Cloud Solution Architect
- Telmo Sampaio | Principal Service Engineering Manager
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.