Maximaal beschikbare NVA's implementeren

Azure
Firewall
Functies
GitHub

In dit artikel wordt uitgelegd hoe u een set virtuele netwerkapparaten (Network Virtual Appliances of NVA's) voor hoge beschikbaarheid implementeert in Azure.This article shows how to deploy a set of network virtual appliances (NVAs) for high availability 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.An NVA is typically used to control the flow of network traffic from a perimeter network, also known as a DMZ, to other networks or subnets. Zie Microsoft-cloudservices en -netwerkbeveiliging voor meer informatie over het implementeren van een perimeternetwerk (DMZ) in Azure.To learn about implementing a DMZ in Azure, see Microsoft cloud services and network security. Dit artikel bevat een voorbeeldarchitecturen voor alleen inkomend verkeer, alleen uitgaand verkeer en zowel inkomend als uitgaand verkeer.The article includes example architectures for ingress only, egress only, and both ingress and egress.

Vereisten: In dit artikel wordt uitgegaan van basiskennis van Azure-netwerken, Azure load balancers en door de gebruiker gedefinieerde routes (UDR's).Prerequisites: This article assumes a basic understanding of Azure networking, Azure load balancers, and user-defined routes (UDRs).

Architectuur diagrammenArchitecture diagrams

Een NVA kan op veel verschillende architecturen worden geïmplementeerd in een perimeternetwerk.An NVA can be deployed to a DMZ in many different architectures. De volgende afbeelding illustreert bijvoorbeeld het gebruik van één NVA voor inkomend verkeer.For example, the following figure illustrates the use of a single NVA for ingress.

0,30

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.In this architecture, the NVA provides a secure network boundary by checking all inbound and outbound network traffic and passing only the traffic that meets network security rules. Het feit dat al het netwerkverkeer door de NVA moet lopen, betekent echter dat de NVA een zwak punt in het netwerk is.However, the fact that all network traffic must pass through the NVA means that the NVA is a single point of failure in the network. Als de NVA uitvalt, is er geen ander pad voor het netwerkverkeer en zijn alle back-end-subnetten niet beschikbaar.If the NVA fails, there is no other path for network traffic and all the back-end subnets are unavailable.

Als u wilt zorgen dat een NVA maximaal beschikbaar is, dient u meer dan één NVA te implementeren in een beschikbaarheidsset.To make an NVA highly available, deploy more than one NVA into an availability set.

De volgende architecturen beschrijven de resources en configuratie die nodig zijn voor NVA's met een hoge beschikbaarheid:The following architectures describe the resources and configuration necessary for highly available NVAs:

OplossingSolution VoordelenBenefits OverwegingenConsiderations
Load Balancer standaard & HA-poortenLoad Balancer Standard & HA ports Alle TCP-en UDP-stromen worden gebalanceerdBalances all TCP and UDP flows Bevestig met NVA-providers hoe u het beste HA-poorten kunt gebruiken en hoe u kunt zien welke scenario's worden ondersteundConfirm with NVA providers how to best use HA ports and to learn which scenarios are supported
De functie HA-poorten is beschikbaar in alle wereld wijde Azure-regio'sHA ports feature is available in all the global Azure regions
Snelle failover naar gezonde instanties, met per-exemplaar status controlesFast failover to healthy instances, with per-instance health probes
Beperkingen bekijkenReview limitations
Inkomend verkeer met NVA's in laag 7Ingress with layer 7 NVAs Alle NVA-knooppunten zijn actiefAll NVA nodes are active Vereist een NVA die verbindingen kan beëindigen en SNAT kan gebruikenRequires an NVA that can terminate connections and use SNAT
Vereist een afzonderlijke set NVA's voor verkeer dat afkomstig is van internet en van AzureRequires a separate set of NVAs for traffic coming from the Internet and from Azure
Kan alleen worden gebruikt voor verkeer dat afkomstig is van buiten AzureCan only be used for traffic originating outside Azure
Uitgaand verkeer met NVA's in laag 7Egress with layer 7 NVAs Alle NVA-knooppunten zijn actiefAll NVA nodes are active Vereist een NVA die verbindingen kan beëindigen en SNAT (adresomzetting in bronnetwerk) implementeertRequires an NVA that can terminate connections and implements source network address translation (SNAT)
Inkomend/uitgaand verkeer met NVA's in laag 7Ingress-Egress with layer 7 NVAs Alle knooppunten zijn actiefAll nodes are active
Kan verkeer verwerken dat afkomstig is van AzureAble to handle traffic originated in Azure
Vereist een NVA die verbindingen kan beëindigen en SNAT kan gebruikenRequires an NVA that can terminate connections and use SNAT
Vereist een afzonderlijke set NVA's voor verkeer dat afkomstig is van internet en van AzureRequires a separate set of NVAs for traffic coming from the Internet and from Azure
PIP-UDR-schakelingPIP-UDR switch Eén set NVA's voor al het verkeerSingle set of NVAs for all traffic
Kan al het verkeer verwerken (geen limiet voor poortregels)Can handle all traffic (no limit on port rules)
Actief-passiefActive-passive
Vereist een failoverprocesRequires a failover process
PIP-UDR zonder SNATPIP-UDR without SNAT Eén set NVA's voor al het verkeerSingle set of NVAs for all traffic
Kan al het verkeer verwerken (geen limiet voor poortregels)Can handle all traffic (no limit on port rules)
Vereist niet configureren van SNAT voor inkomende aanvragenDoes not require configuring SNAT for inbound requests
Actief-passiefActive-passive
Vereist een failoverprocesRequires a failover process
De logica voor zoeken en failover wordt uitgevoerd buiten het virtuele netwerkProbing and failover logic run outside the virtual network

Inkomend verkeer met NVA's in laag 7Ingress with layer 7 NVAs

De volgende afbeelding toont een architectuur met hoge beschikbaarheid die een perimeternetwerk (DMZ) voor inkomend verkeer achter een internetgerichte load balancer implementeert.The following figure shows a high availability architecture that implements an ingress DMZ behind an internet-facing load balancer. Deze architectuur is ontworpen om verbinding te bieden met Azure-workloads voor verkeer in laag 7, zoals HTTP of HTTPS:This architecture is designed to provide connectivity to Azure workloads for layer 7 traffic, such as HTTP or HTTPS:

i1

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.The benefit of this architecture is that all NVAs are active, and if one fails the load balancer directs network traffic to the other NVA. Beide NVA's routeren verkeer naar de interne load balancer, dus het verkeer blijft stromen zolang er één NVA actief is.Both NVAs route traffic to the internal load balancer so as long as one NVA is active, traffic continues to flow. De NVA's moeten SSL-verkeer dat is bedoeld voor de VM's in de weblaag kunnen beëindigen.The NVAs are required to terminate SSL traffic intended for the web tier VMs. 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.These NVAs cannot be extended to handle on-premises traffic because on-premises traffic requires another dedicated set of NVAs with their own network routes.

Uitgaand verkeer met NVA's in laag 7Egress with layer 7 NVAs

De vorige architectuur kan worden uitgebreid om een DMZ voor uitgaand verkeer te bieden voor aanvragen die afkomstig zijn van de Azure-workload.The previous architecture can be expanded to provide an egress DMZ for requests originating in the 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:The following architecture is designed to provide high availability of the NVAs in the DMZ for layer 7 traffic, such as HTTP or HTTPS:

twee2

In deze architectuur wordt al het verkeer dat afkomstig is van Azure doorgestuurd naar een interne load balancer.In this architecture, all traffic originating in Azure is routed to an internal load balancer. De load balancer verdeelt uitgaande aanvragen tussen een set NVA's.The load balancer distributes outgoing requests between a set of NVAs. Deze NVA's leiden verkeer naar internet met hun afzonderlijke openbare IP-adressen.These NVAs direct traffic to the Internet using their individual public IP addresses.

Inkomend/uitgaand verkeer met NVA's in laag 7Ingress-egress with layer 7 NVAs

In de vorige twee architecturen is er een afzonderlijk perimeternetwerk (DMZ) voor inkomend en uitgaand verkeer.In the two previous architectures, there was a separate DMZ for ingress and egress. 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:The following architecture demonstrates how to create a DMZ that can be used for both ingress and egress for layer 7 traffic, such as HTTP or HTTPS:

4

In deze architectuur verwerken de NVA's inkomende aanvragen van de toepassingsgateway.In this architecture, the NVAs process incoming requests from the application gateway. De NVA's verwerken ook uitgaande aanvragen van de workload-VM's in de back-end-pool van de load balancer.The NVAs also process outgoing requests from the workload VMs in the back-end pool of the 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.Because incoming traffic is routed with an application gateway and outgoing traffic is routed with a load balancer, the NVAs are responsible for maintaining session affinity. 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.That is, the application gateway maintains a mapping of inbound and outbound requests so it can forward the correct response to the original requestor. 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.However, the internal load balancer does not have access to the application gateway mappings, and uses its own logic to send responses to the NVAs. Het is mogelijk dat de load balancer een reactie verzendt naar een NVA die de aanvraag oorspronkelijk niet heeft ontvangen van de toepassingsgateway.It's possible the load balancer could send a response to an NVA that did not initially receive the request from the application gateway. In dit geval moeten de NVA's communiceren en de reactie onderling doorgeven, zodat de juiste NVA de reactie naar de toepassingsgateway kan doorsturen.In this case, the NVAs must communicate and transfer the response between them so the correct NVA can forward the response to the application gateway.

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.You can also solve the asymmetric routing issue by ensuring the NVAs perform inbound source network address translation (SNAT). 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.This would replace the original source IP of the requestor to one of the IP addresses of the NVA used on the inbound flow. Dit zorgt ervoor dat u meerdere NVA's tegelijk kunt gebruiken terwijl de routesymmetrie behouden blijft.This ensures that you can use multiple NVAs at a time, while preserving the route symmetry.

PIP-UDR-schakeling met NVA's in laag 4PIP-UDR switch with layer 4 NVAs

De volgende architectuur laat zien hoe een architectuur met één actieve en één passieve NVA werkt.The following architecture demonstrates an architecture with one active and one passive NVA. Deze architectuur verwerkt zowel inkomend als uitgaand verkeer in laag 4:This architecture handles both ingress and egress for layer 4 traffic:

3D3

Tip

Er is een volledige oplossing voor deze architectuur beschikbaar op github.A complete solution for this architecture is available on GitHub.

Deze architectuur lijkt op de eerste architectuur die in dit artikel wordt besproken.This architecture is similar to the first architecture discussed in this article. Die architectuur omvatte één NVA die inkomende aanvragen van laag 4 accepteert en filtert.That architecture included a single NVA accepting and filtering incoming layer 4 requests. Deze architectuur voegt een tweede passieve NVA toe om een hoge beschikbaarheid te bieden.This architecture adds a second passive NVA to provide high availability. Als de actieve NVA uitvalt, wordt de passieve NVA actief gemaakt en worden UDR en PIP gewijzigd, zodat ze verwijzen naar de NIC's op de nu actieve NVA.If the active NVA fails, the passive NVA is made active and the UDR and PIP are changed to point to the NICs on the now active NVA. Deze wijzigingen in UDR en PIP kunnen handmatig worden uitgevoerd of met behulp van een geautomatiseerd proces.These changes to the UDR and PIP can either be done manually or using an automated process. Het geautomatiseerde proces is meestal daemon of een andere controleservice die wordt uitgevoerd in Azure.The automated process is typically daemon or other monitoring service running in Azure. Hierbij wordt een statustest uitgevoerd op de actieve NVA en wordt de UDR- en PIP-schakeling uitgevoerd wanneer wordt gedetecteerd dat de NVA niet werkt.It queries a health probe on the active NVA and performs the UDR and PIP switch when it detects a failure of the NVA.

In de voorgaande afbeelding ziet u een voorbeeld van een ZooKeeper-cluster dat een daemon voor hoge beschikbaarheid biedt.The preceding figure shows an example ZooKeeper cluster providing a high availability daemon. Een quorum van knooppunten binnen het ZooKeeper-cluster kiest een leider.Within the ZooKeeper cluster, a quorum of nodes elects a leader. Als de leider uitvalt, houden de resterende knooppunten een verkiezing om een nieuwe leider te kiezen.If the leader fails, the remaining nodes hold an election to elect a new leader. Voor deze architectuur voert het leidende knooppunt de daemon uit die het statuseindpunt op de NVA ondervraagt.For this architecture, the leader node executes the daemon that queries the health endpoint on the NVA. Als de NVA niet reageert op de statustest, activeert de daemon de passieve NVA.If the NVA fails to respond to the health probe, the daemon activates the passive NVA. De daemon roept vervolgens de Azure REST API aan om de PIP uit de uitgevallen NVA te verwijderen en te koppelen aan de zojuist geactiveerde NVA.The daemon then calls the Azure REST API to remove the PIP from the failed NVA and attaches it to newly activated NVA. De daemon wijzigt vervolgens de UDR, zodat deze wijst naar het interne IP-adres van de zojuist geactiveerde NVA.The daemon then modifies the UDR to point to the newly activated NVA's internal IP address.

Neem de ZooKeeper-knooppunten niet op in een subnet dat alleen toegankelijk is via een route die de NVA bevat.Do not include the ZooKeeper nodes in a subnet that is only accessible using a route that includes the NVA. Als u dat wel doet, zijn de ZooKeeper-knooppunten niet toegankelijk als de NVA uitvalt.Otherwise, the ZooKeeper nodes are inaccessible if the NVA fails. Mocht de daemon om welke reden dan ook niet werken, dan hebt u geen toegang tot de ZooKeeper-knooppunten om een diagnose van het probleem te stellen.Should the daemon fail for any reason, you won't be able to access any of the ZooKeeper nodes to diagnose the problem.

Zie de bestanden in de github-opslag plaatsvoor een overzicht van de volledige oplossing, inclusief voorbeeld code.To see the complete solution including sample code, see the files in the GitHub repository.

PIP-UDR Nva's zonder SNATPIP-UDR NVAs without SNAT

Deze architectuur maakt gebruik van twee virtuele Azure-machines om de NVA-firewall te hosten in een actief-passieve configuratie die automatische failover ondersteunt, maar geen bron netwerk adres omzetting (SNAT) vereist.This architecture uses two Azure virtual machines to host the NVA firewall in an active-passive configuration that supports automated failover but does not require Source Network Address Translation (SNAT).

PIP-UDR Nva's zonder SNAT-architectuur

Tip

Er is een volledige oplossing voor deze architectuur beschikbaar op github.A complete solution for this architecture is available on GitHub.

Deze oplossing is bedoeld voor Azure-klanten die geen SNAT kunnen configureren voor inkomende aanvragen op hun NVA-firewalls.This solution is designed for Azure customers who cannot configure SNAT for inbound requests on their NVA firewalls. SNAT verbergt het oorspronkelijke IP-adres van de bron client.SNAT hides the original source client IP address. Als u de oorspronkelijke Ip's moet vastleggen of ze wilt gebruiken binnen andere gelaagde beveiligings onderdelen achter uw Nva's, biedt deze oplossing een basis benadering.If you need to log the original IPs or used them within other layered security components behind your NVAs, this solution offers a basic approach.

De failover van UDR-tabel vermeldingen wordt geautomatiseerd door een adres van de volgende hop dat is ingesteld op het IP-adres van een interface op de actieve virtuele machine met NVA-firewall.The failover of UDR table entries is automated by a next-hop address set to the IP address of an interface on the active NVA firewall virtual machine. De logica voor automatische failover wordt gehost in een functie-app die u maakt met behulp van Azure functions.The automated failover logic is hosted in a function app that you create using Azure Functions. De failover-code wordt in Azure Functions uitgevoerd als een serverloze functie.The failover code runs as a serverless function inside Azure Functions. Implementatie is handig, rendabel en gemakkelijk te onderhouden en aan te passen.Deployment is convenient, cost-effective, and easy to maintain and customize. Bovendien wordt de functie-app gehost in Azure Functions, zodat er geen afhankelijkheden zijn in het virtuele netwerk.In addition, the function app is hosted within Azure Functions, so it has no dependencies on the virtual network. Als wijzigingen in het virtuele netwerk van invloed zijn op de NVA-firewalls, blijft de functie-app onafhankelijk worden uitgevoerd.If changes to the virtual network impact the NVA firewalls, the function app continues to run independently. Testen is ook nauw keuriger, omdat deze buiten het virtuele netwerk plaatsvindt met dezelfde route als de inkomende client aanvragen.Testing is more accurate as well, because it takes place outside the virtual network using the same route as the inbound client requests.

Om de beschik baarheid van de NVA-firewall te controleren, controleert de functie-app code deze op een van de volgende twee manieren:To check the availability of the NVA firewall, the function app code probes it in one of two ways:

  • Door de status van de virtuele Azure-machines te bewaken die als host fungeert voor de NVA-firewall.By monitoring the state of the Azure virtual machines hosting the NVA firewall.

  • Door te testen of er een open poort via de firewall naar de back-end-webserver is.By testing whether there is an open port through the firewall to the back-end web server. Voor deze optie moet de NVA een socket via PIP beschikbaar maken voor de functie-app-code die u wilt testen.For this option, the NVA must expose a socket via PIP for the function app code to test.

U kiest het type test dat u wilt gebruiken bij het configureren van de functie-app.You choose the type of probe you want to use when you configure the function app. Zie de bestanden in de github-opslag plaatsvoor een overzicht van de volledige oplossing, inclusief voorbeeld code.To see the complete solution including sample code, see the files in the GitHub repository.

Volgende stappenNext steps