Maximaal beschikbare NVA's implementeren

Azure Active Directory
Firewall
Functions
Traffic Manager
Virtual Machines

In dit artikel worden verschillende opties beschreven voor het implementeren van een set virtuele netwerkapparaten (N NVA's) voor hoge beschikbaarheid in Azure. Een NVA wordt meestal gebruikt om de stroom netwerkverkeer van een perimeternetwerk (ook wel een DMZ genoemd) naar andere netwerken of subnetten te regelen. Zie Microsoft-cloudservices en -netwerkbeveiliging voor meer informatie over het implementeren van een perimeternetwerk (DMZ) in Azure. Dit artikel bevat een voorbeeldarchitecturen voor alleen inkomend verkeer, alleen uitgaand verkeer en zowel inkomend als uitgaand verkeer.

Vereisten: In dit artikel wordt uitgegaan van basiskennis van Azure-netwerken, Azure load balancers en door de gebruiker gedefinieerde routes (UDR's).

Conceptueel overzicht van NVA

In de volgende afbeelding ziet u het gebruik van één NVA voor in- en uitverkeer van netwerkverkeer.

0

In deze architectuur biedt de NVA een beveiligde netwerkgrens door al het inkomende en uitgaande netwerkverkeer te controleren en alleen het verkeer door te laten dat voldoet aan netwerkbeveiligingsregels. Het feit dat al het netwerkverkeer door de NVA moet lopen, betekent echter dat de NVA een zwak punt in het netwerk is. Als de NVA uitvalt, is er geen ander pad voor het netwerkverkeer en zijn alle back-end-subnetten niet beschikbaar.

Eén NVA kan een hogere beschikbaarheid hebben als u Premium SSD of Ultra Disk voor alle besturingssysteemschijven en gegevensschijven. Als u nog grotere beschikbaarheidsdoelen wilt bereiken, implementeert u meer dan één NVA in een beschikbaarheidsset of in meerdere Beschikbaarheidszones. Zie SLA voor meer inzicht in de serviceovereenkomst voor afzonderlijke en meerdere VM'Virtual Machines. Het hoogste uptimeniveau wordt bereikt met meerdere NVA-VM's die zijn geïmplementeerd op meerdere Beschikbaarheidszones

Overzicht van HA-architecturen

De volgende architecturen beschrijven de resources en configuratie die nodig zijn voor NVA's met een hoge beschikbaarheid:

Oplossing Voordelen Overwegingen Implementatie
Load Balancer Standard- en HA-poorten Alle TCP- en UDP-stromen in balans brengen Controleer bij NVA-providers hoe ha-poorten het beste kunnen worden gebruikt en welke scenario's worden ondersteund
De functie HA-poorten is beschikbaar in alle azure-regio's wereldwijd
Snelle failover naar gezonde exemplaren, met statustests per exemplaar
Beperkingen bekijken
Klik voor implementatiedetails
Inkomend verkeer met NVA's in laag 7 Alle NVA-knooppunten zijn actief Vereist een NVA die verbindingen kan beëindigen en SNAT kan gebruiken
Vereist een afzonderlijke set NVA's voor verkeer dat afkomstig is van internet en van Azure
Kan alleen worden gebruikt voor verkeer dat afkomstig is van buiten Azure
De laag 7-architectuur voor ingress implementeren
Uitgaand verkeer met NVA's in laag 7 Alle NVA-knooppunten zijn actief Vereist een NVA die verbindingen kan beëindigen en SNAT (adresomzetting in bronnetwerk) implementeert
Het gebruik van SNAT voor uitgaande verbindingen controleren
De laag 7-Egress implementeren
Inkomend/uitgaand verkeer met NVA's in laag 7 Alle knooppunten zijn actief
Kan verkeer verwerken dat afkomstig is van Azure
Vereist een NVA die verbindingen kan beëindigen en SNAT kan gebruiken
Vereist een afzonderlijke set NVA's voor verkeer dat afkomstig is van internet en van Azure
Het gebruik van SNAT voor uitgaande verbindingen controleren
De laag 7 ingress/Egress implementeren
PIP-UDR zonder SNAT Eén set NVA's voor al het verkeer
Kan al het verkeer verwerken (geen limiet voor poortregels)
Het configureren van SNAT voor binnenkomende aanvragen is niet vereist
Actief-passief
Vereist een failoverproces
De logica voor probing en failover wordt buiten het virtuele netwerk uitgevoerd
Openbare IP-adressen controleren
Implementeer de PIP-UDR-switch met NNA's op laag 4 zonder SNAT-architectuur

Load Balancer Standard- en HA-poorten

U kunt een Azure-Standard Load Balancer met HA-poorten voor toepassingen waarvoor taakverdeling van grote aantallen poorten is vereist. Eén taakverdelingsregel vervangt meerdere afzonderlijke taakverdelingsregels, één voor elke poort.

HAPortsArch

De architectuur voor HA-poorten implementeren

Ondersteuning voor HA-poorten en implementatieopties verschilt per NVA-partnerleverancier. Raadpleeg de documentatie Load Balancer Standard & HA-poorten en specifieke NVA-documentatie voor ondersteuning, beperkingen en implementatiedetails.

Inkomend verkeer met NVA's in laag 7

De volgende afbeelding toont een architectuur met hoge beschikbaarheid die een perimeternetwerk (DMZ) voor inkomend verkeer achter een internetgerichte load balancer implementeert. Deze architectuur is ontworpen om verbinding te bieden met Azure-workloads voor verkeer in laag 7, zoals HTTP of HTTPS:

1

Het voordeel van deze architectuur is dat alle NVA's actief zijn. Als er één NVA uitvalt, stuurt de load balancer netwerkverkeer naar de andere NVA. Beide NVA's routeren verkeer naar de interne load balancer, dus het verkeer blijft stromen zolang er één NVA actief is. De NVA's moeten SSL-verkeer dat is bedoeld voor de VM's in de weblaag kunnen beëindigen. Deze NVA's kunnen niet worden uitgebreid voor het verwerken van on-premises verkeer omdat on-premises verkeer een andere speciale set NVA's met hun eigen netwerkroutes vereist.

De laag 7-architectuur voor ingress implementeren

Gebruik de volgende opdracht om een resourcegroep voor de implementatie te maken. Klik op de knop Probeer het om een ingesloten shell te gebruiken.

az group create --name ha-nva-l7i --location eastus

Voer de volgende opdracht uit om de voorbeeldarchitectuur van het laag 7-ingress-voorbeeld te implementeren.

az deployment group create --resource-group ha-nva-l7i \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/ha-nva/azuredeploy.json \
    --parameters deployIngressAppGatewayWebLoadBalancer=true deployEgressLoadBalancerNva=false

Zie de Azure Resource Manager sjablonen (ARM-sjablonen) die worden gebruikt om deze oplossing te implementeren voor gedetailleerde informatie en aanvullende implementatieopties.

Uitgaand verkeer met NVA's in laag 7

De vorige architectuur kan worden uitgebreid om een DMZ voor uitgaand verkeer te bieden voor aanvragen die afkomstig zijn van de Azure-workload. De volgende architectuur is ontworpen met het oog op een hoge beschikbaarheid van de NVA's in het perimeternetwerk voor verkeer in laag 7, zoals HTTP of HTTPS:

2

In deze architectuur wordt al het verkeer dat afkomstig is van Azure omgeleid naar een interne load balancer via de configuratie van de besturingssysteemproxy. De load balancer verdeelt uitgaande aanvragen tussen een set NVA's. Deze NVA's leiden verkeer naar internet met hun afzonderlijke openbare IP-adressen.

De laag 7-Egress implementeren

Gebruik de volgende opdracht om een resourcegroep voor de implementatie te maken. Klik op de knop Probeer het om een ingesloten shell te gebruiken.

az group create --name ha-nva-l7e --location eastus

Voer de volgende opdracht uit om de Laag 7-architectuur Egress implementeren.

az deployment group create --resource-group ha-nva-l7e \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/ha-nva/azuredeploy.json \
    --parameters deployIngressAppGatewayWebLoadBalancer=false deployEgressLoadBalancerNva=true

Zie de Azure Resource Manager sjablonen (ARM-sjablonen) die worden gebruikt om deze oplossing te implementeren voor gedetailleerde informatie en aanvullende implementatieopties.

Ingress/Egress met N NVA's in laag 7

In de vorige twee architecturen is er een afzonderlijk perimeternetwerk (DMZ) voor inkomend en uitgaand verkeer. De volgende architectuur laat zien hoe u een DMZ maakt die kan worden gebruikt voor zowel inkomend als uitgaand verkeer in laag 7, zoals HTTP of HTTPS:

3

In deze architectuur verwerken de NVA's inkomende aanvragen van de toepassingsgateway. De NVA's verwerken ook uitgaande aanvragen van de workload-VM's in de back-end-pool van de load balancer. Omdat inkomend verkeer wordt doorgestuurd met een toepassingsgateway en uitgaand verkeer wordt doorgestuurd met een load balancer, zijn de NVA's verantwoordelijk voor het onderhouden van de sessie-affiniteit. Dat wil zeggen dat de toepassingsgateway de toewijzing van inkomende en uitgaande aanvragen bijhoudt, zodat de juiste reactie naar de oorspronkelijke aanvrager kan worden doorgestuurd. De interne load balancer heeft echter geen toegang tot de toewijzingen van de toepassingsgateway en gebruikt zijn eigen logica om reacties naar de NVA's te verzenden. Het is mogelijk dat de load balancer een reactie verzendt naar een NVA die de aanvraag oorspronkelijk niet heeft ontvangen van de toepassingsgateway. In dit geval moeten de NVA's communiceren en de reactie onderling doorgeven, zodat de juiste NVA de reactie naar de toepassingsgateway kan doorsturen.

Notitie

U kunt het probleem van asymmetrische routering ook oplossen door ervoor te zorgen dat de NVA's SNAT (adresomzetting voor het inkomende bronnetwerk) uitvoeren. Hierbij zou het oorspronkelijke bron-IP-adres van de aanvrager worden vervangen door een van de IP-adressen van de NVA die is gebruikt voor de inkomende stroom. Dit zorgt ervoor dat u meerdere NVA's tegelijk kunt gebruiken terwijl de routesymmetrie behouden blijft.

De laag 7-architectuur voor Egress implementeren

Gebruik de volgende opdracht om een resourcegroep voor de implementatie te maken. Klik op de knop Probeer het om een ingesloten shell te gebruiken.

az group create --name ha-nva-l7ie --location eastus

Voer de volgende opdracht uit om de voorbeeldarchitectuur voor in- en Egress laag 7 te implementeren.

az deployment group create --resource-group ha-nva-l7ie \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/ha-nva/azuredeploy.json

Zie de Azure Resource Manager sjablonen (ARM-sjablonen) die worden gebruikt om deze oplossing te implementeren voor gedetailleerde informatie en aanvullende implementatieopties.

PIP-UDR-switch met N NVA's in laag 4 zonder SNAT

Deze architectuur maakt gebruik van twee virtuele Azure-machines voor het hosten van de NVA-firewall in een actief-passief-configuratie die automatische failover ondersteunt, maar geen Bronnetwerkadresvertaling (SNAT) vereist.

5

Deze oplossing is ontworpen voor Azure-klanten die SNAT niet kunnen configureren voor inkomende aanvragen op hun NVA-firewalls. SNAT verbergt het IP-adres van de oorspronkelijke bronclient. Als u de oorspronkelijke IP's wilt inloggen of wilt gebruiken binnen andere gelaagde beveiligingsonderdelen achter uw NBU's, biedt deze oplossing een basisbenadering.

De failover van UDR-tabelgegevens wordt geautomatiseerd door een 'volgende hop'-adres dat is ingesteld op het IP-adres van een interface op de actieve virtuele NVA-firewallmachine. De geautomatiseerde failoverlogica wordt gehost in een functie-app die u maakt met behulp Azure Functions. De failovercode wordt uitgevoerd als een serverloze functie binnen Azure Functions. Implementatie is handig, rendabel en eenvoudig te onderhouden en aan te passen. Bovendien wordt de functie-app gehost binnen Azure Functions, zodat deze geen afhankelijkheden heeft van het virtuele netwerk. Als wijzigingen in het virtuele netwerk van invloed zijn op de NVA-firewalls, blijft de functie-app onafhankelijk van elkaar worden uitgevoerd. Testen is ook nauwkeuriger, omdat deze buiten het virtuele netwerk plaatsvindt met behulp van dezelfde route als de inkomende clientaanvragen.

Om de beschikbaarheid van de NVA-firewall te controleren, test de functie-app deze op een van de volgende twee manieren:

  • Door de status te bewaken van de virtuele Azure-machines die als host voor de NVA-firewall worden gebruikt.

  • Door te testen of er een open poort via de firewall naar de back-endwebserver is. Voor deze optie moet de NVA een socket via PIP beschikbaar maken om de code van de functie-app te testen.

U kiest het type test dat u wilt gebruiken wanneer u de functie-app configureert.

Implementeer de PIP-UDR-switch met NNA's op laag 4 zonder SNAT-architectuur

Voor deze implementatie zijn verschillende implementatiestappen en handmatige configuratie vereist. Zie de opslagplaats GitHub meer informatie.

Volgende stappen