Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit artikel worden veelvoorkomende manieren beschreven om een set virtuele netwerkapparaten (NVA's) te implementeren voor hoge beschikbaarheid in Azure. Een NVA bepaalt doorgaans de verkeersstroom tussen netwerksegmenten met verschillende beveiligingsniveaus. U kunt bijvoorbeeld een NVA gebruiken tussen een virtueel perimeternetwerk en het openbare internet, of externe locaties verbinden met Azure via VPN-apparaten (virtual private network) of softwaregedefinieerde WAN-apparaten (SD-WAN).
In dit artikel wordt ervan uitgegaan dat u basiskennis hebt van Azure-netwerken, Azure-load balancers, routering van virtueel netwerkverkeer en door de gebruiker gedefinieerde routes (UDR's).
Veel ontwerppatronen gebruiken NVA's om verkeer tussen verschillende beveiligingszones te inspecteren. Deze patronen kunnen NVA's (Niet-waarde-toevoegende activiteiten) gebruiken voor de volgende doeleinden:
Om uitgaand verkeer van virtuele machines naar internet te inspecteren en exfiltratie van gegevens te voorkomen.
Om inkomend verkeer van internet naar virtuele machines te inspecteren en aanvallen te voorkomen.
Verkeer filteren tussen virtuele machines in Azure om laterale verplaatsingen van gecompromitteerde systemen te voorkomen.
Verkeer filteren tussen on-premises systemen en virtuele Azure-machines, met name als ze deel uitmaken van verschillende beveiligingsniveaus. Azure host bijvoorbeeld het perimeternetwerk, terwijl de on-premises omgeving als host fungeert voor de interne toepassingen.
VPN- of SD-WAN-tunnels beëindigen vanuit externe locaties, zoals lokale netwerken of andere publieke cloudomgevingen.
U kunt de volgende NVA's toevoegen aan een Azure-ontwerp met behulp van de patronen in dit artikel:
- Netwerkfirewalls
- Omgekeerde proxy's op laag 4
- VPN-eindpunten (Internet Protocol Security) (IPsec)
- SD-WAN apparaten
- Omgekeerde proxy's op internet met webfunctionaliteit voor Web Application Firewall
- Internetproxy's om te beperken welke internetpagina's toegankelijk zijn vanuit Azure
- Load balancers voor laag 7
Azure-systeemeigen NVA's, zoals Azure Firewall en Azure Application Gateway, gebruiken de ontwerpen die verderop in dit artikel worden uitgelegd. U moet deze opties begrijpen vanuit een ontwerpperspectief en voor netwerkproblemen.
NVA's vereisen vaak hoge beschikbaarheid omdat ze de communicatie tussen netwerksegmenten beheren. Als NVA's niet beschikbaar zijn, kan het netwerkverkeer niet meer stromen en werken toepassingen niet meer. Geplande en ongeplande storingen sluiten af en toe NVA-exemplaren af, vergelijkbaar met andere virtuele machines in Azure of in andere clouds. De NVA-exemplaren kunnen worden uitgeschakeld, zelfs als u ze configureert met Azure Premium SSD's, die een service-level overeenkomst voor één exemplaar in Azure bieden. Voor maximaal beschikbare toepassingen zijn ten minste twee NVA's vereist om connectiviteit te garanderen.
Wanneer u de beste optie kiest om een NVA te implementeren in een virtueel Azure-netwerk, is het belangrijkste aspect of de NVA-leverancier het ontwerp heeft geëvalueerd en gevalideerd. De leverancier moet ook de vereiste NVA-configuratie opgeven om de NVA te integreren in Azure. Als de NVA-leverancier meerdere ondersteunde ontwerpopties biedt, moet u rekening houden met de volgende factoren om uw beslissing te nemen:
Convergentietijd: De tijd die nodig is voor elk ontwerp om verkeer om te leiden van een mislukt NVA-exemplaar
Ondersteuning voor topologie: De NVA-configuraties die elke ontwerpoptie ondersteunen, zoals actief/actief, actief/standby of scale-out NVA-clusters met een extra eenheid voor redundantie.
Verkeerssymmetrie: Of een bepaald ontwerp de NVA dwingt om SNAT (Source Network Address Translation) uit te voeren op de pakketten om asymmetrische routering te voorkomen, of als het ontwerp verkeerssymmetrie op andere manieren afdwingt
Opmerking
Dit artikel gaat over hub-and-spoke-ontwerpen. Dit artikel heeft geen betrekking op Azure Virtual WAN , omdat deze meer beschrijvende richtlijnen heeft voor het implementeren van NVA's, afhankelijk van of een Virtual Wan-hub een specifieke NVA ondersteunt. Zie NVA's in een Virtual WAN-hub voor meer informatie.
In de volgende secties worden algemene architecturen beschreven die u kunt gebruiken om NVA's te integreren in een hub-and-spoke-netwerk.
Overzicht van architecturen met hoge beschikbaarheid
| Oplossing | Voordelen | Overwegingen |
|---|---|---|
| Azure Load Balancer | Deze oplossing biedt ondersteuning voor actief/actief- en actief/standbyconfiguraties en het opschalen van NVA’s met een goede convergentietijd. | De NVA moet een poort bieden voor de statustests, met name voor actieve/stand-by-implementaties. Voor stateful apparaten, zoals firewalls die verkeerssymmetrie vereisen, is SNAT vereist voor dataverkeer naar en van internet. |
| Azure Route Server | De NVA moet BGP (Border Gateway Protocol) ondersteunen. Deze oplossing ondersteunt actief/actief, actief/stand-by en uitbreidbare NVA's. | Verkeerssymmetrie vereist SNAT in deze oplossing. |
| Azure Gateway Load Balancer | Verkeerssymmetrie wordt gegarandeerd zonder SNAT. NVA's kunnen worden gedeeld tussen tenants. Deze oplossing heeft een goede convergentietijd en ondersteunt actief/actief, actief/standby en schaalbare NVAs. | Deze oplossing ondersteunt stromen van en naar internet en biedt geen ondersteuning voor East-West stromen. |
| Dynamisch privé-IP-adres en UDR | Voor de NVA zijn geen speciale functies vereist. Deze oplossing garandeert symmetrisch verkeer. | Deze oplossing is alleen bedoeld voor actieve/passieve ontwerpen. Het heeft een hoge convergentietijd van één tot twee minuten. |
Ladingsverdelaar
Het ontwerp van de load balancer maakt gebruik van twee Azure-load balancers om een cluster van NVA's beschikbaar te maken voor de rest van het netwerk. De aanpak is geschikt voor zowel 'stateful-' als 'stateless'-NVA's.
Een interne load balancer leidt intern verkeer van Azure en on-premises om naar de NVA's. Deze interne load balancer is geconfigureerd met regels voor hoge beschikbaarheidspoorten , zodat elke TCP-poort (Transmission Control Protocol) en UDP-poort (User Datagram Protocol) wordt omgeleid naar de NVA-exemplaren.
Een openbare load balancer maakt de NVA's beschikbaar op internet. Poorten met hoge beschikbaarheid zijn voor inkomend verkeer, dus elke TCP/UDP-poort moet worden geopend in een toegewezen taakverdelingsregel.
In het volgende diagram ziet u de volgorde van hops die pakketten van internet naar een toepassingsserver in een virtueel spoke-netwerk nemen. Deze pakketten doorkruisen een firewall-NVA om verkeer van en naar het openbare internet te beheren, ook wel North-South verkeer genoemd.
Download een Visio-bestand van deze architectuur.
Voor het verzenden van verkeer van spokes naar het openbare internet via de NVA's gebruikt dit ontwerp een UDR voor 0.0.0.0/0. De volgende hop is 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. Dit proces treedt zelfs op als de firewall-NVA één netwerkinterfacekaart (NIC) heeft voor zowel de openbare als interne netwerken, omdat het inkomende pakket via de openbare Azure-load balancer gaat en het uitgaande pakket via de interne Azure-load balancer gaat. Beide richtingen van de stroom lopen door verschillende load balancers. Dus als u verkeerssymmetrie nodig hebt, moeten de NVA-exemplaren SNAT uitvoeren om retourverkeer aan te trekken en ervoor te zorgen dat verkeerssymmetrie wordt gegarandeerd. Voor de meeste firewalls is verkeerssymmetrie vereist.
In het volgende diagram ziet u hoe u hetzelfde load balancer-ontwerp gebruikt om verkeer tussen Azure- en on-premises netwerken te inspecteren, of East-West verkeer, waarbij alleen een interne load balancer is vereist. U kunt deze methode ook gebruiken om verkeer tussen de spaken via de NVA's te verzenden.
In de vorige diagrammen weet spoke1 niet over het bereik van spoke2. Daarom verzendt de 0.0.0.0/0 UDR verkeer dat is bedoeld voor 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 doorlopen, selecteert de load balancer hetzelfde NVA-exemplaar voor beide richtingen. Als een NVA-ontwerp met twee NIC's een interne load balancer heeft voor elke communicatierichting, zorgt SNAT voor verkeerssymmetrie. In het vorige North-South diagram ziet u een voorbeeld van dit ontwerp.
In dit ontwerp moeten NVA's met twee NIC's bepalen waar antwoorden op de gezondheidscontroles van de load balancer moeten worden verzonden. Load Balancer gebruikt altijd hetzelfde IP-adres als de bron voor de statuscontroles.168.63.129.16 De NVA moet deze gezondheidscontrolereacties terugsturen via dezelfde interface waarop ze zijn ontvangen. Voor dit proces zijn doorgaans meerdere routeringstabellen in een besturingssysteem vereist, omdat op doel gebaseerde routering de antwoorden via dezelfde NIC verzendt.
De Azure Load Balancer heeft een goede tijdsduur voor convergentie bij afzonderlijke NVA-storingen. U kunt elke vijf seconden gezondheidstests verzenden en het duurt drie mislukte tests om een back-end instantie buiten dienst te verklaren. Het duurt dus meestal 10 tot 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- of UDP-poort of een HTTP-eindpunt opgeven dat alleen reageert op de statustests van de load balancer voor het exemplaar dat zich momenteel in de actieve rol bevindt.
Load balancers voor laag 7
Een specifiek ontwerp voor beveiligingsappliances vervangt de openbare Azure Load Balancer door een Laag-7 load balancer, zoals de Azure Application Gateway, die op zich als een NVA kan worden beschouwd.
In dit scenario hebben de NVA's alleen een interne load balancer nodig voor verkeer afkomstig van de workloadsystemen. Dual-NIC apparaten gebruiken deze methode soms om routeringsproblemen met de statuscontroles van de Azure Load Balancer te voorkomen. Dit ontwerp ondersteunt alleen de Layer-7-protocollen die door de load balancer van Layer-7 worden ondersteund. Dit is doorgaans HTTP en HTTPS.
De NVA moet binnenkomend verkeer verwerken voor protocollen die niet worden ondersteund door de load balancer layer-7. De NVA kan ook uitgaand verkeer verwerken. Zie Firewall en Application Gateway voor virtuele netwerken voor meer informatie.
Routeserver
Route Server is een service waarmee een NVA via BGP kan communiceren met door software gedefinieerde Azure-netwerken. NVA's leren welke IP-adresvoorvoegsels bestaan in virtuele Azure-netwerken. Ze kunnen ook routes injecteren in de effectieve routetabellen van virtuele machines in Azure.
In het vorige diagram maakt elk NVA-exemplaar verbinding met routeserver via BGP. Voor dit ontwerp is geen routetabel in de spoke-subnetten vereist, omdat Route Server de routes programmeert die de NVA's adverteren. Als twee of meer routes worden geprogrammeerd in Azure virtuele machines, gebruiken ze equal-cost multi-path routing om een van de NVA-instances te kiezen voor elke verkeersstroom. Daarom moet u SNAT in dit ontwerp opnemen als u verkeerssymmetrie nodig hebt.
Deze invoegmethode ondersteunt zowel actieve/actieve als actieve/standbyconfiguraties. In een actieve/actieve configuratie maken alle NVA's dezelfde routes bekend aan de Route Server. In een actieve/stand-by-configuratie adverteert één NVA routes met een korter autonoom systeempad (AS) dan de andere. Route Server ondersteunt maximaal acht BGP-aangrenzingen. Dus als u een uitbreidbaar cluster met actieve NVA's gebruikt, ondersteunt dit ontwerp acht NVA-exemplaren maximaal.
Deze installatie heeft een snelle convergentietijd. De keepalive- en holdtime-timers van de BGP-aangrenzing beïnvloeden de convergentietijd. Route Server heeft standaard keepalive timers ingesteld op 60 seconden en holdtime timers ingesteld op 180 seconden. Maar de NVA's kunnen onderhandelen over kortere timers bij het tot stand brengen van BGP-buurrelaties. Als u deze timers te laag instelt, kan dit leiden tot instabiliteit van BGP.
Dit ontwerp is geschikt voor NVA's die moeten communiceren met Azure-routering. Voorbeelden hiervan zijn SD-WAN of IPsec NVA's, die doorgaans goede BGP-ondersteuning hebben. Deze NVA's moeten de voorvoegsels leren die zijn geconfigureerd in virtuele Azure-netwerken of bepaalde routes bekendmaken via ExpressRoute Private Peerings. Deze typen apparaten zijn meestal staatloos, dus verkeerssymmetrie is geen probleem en SNAT is niet vereist.
Gateway Load Balancer
Gateway Load Balancer biedt een manier om NVA's in het gegevenspad in te voegen zonder dat u verkeer hoeft te routeren met behulp van UDR's. Voor virtuele machines die hun workloads beschikbaar maken via een Azure Load Balancer of een openbaar IP-adres, kunt u inkomend en uitgaand verkeer transparant omleiden naar een cluster met NVA's in een ander virtueel netwerk. In het volgende diagram ziet u het pad dat pakketten volgen voor binnenkomend verkeer vanaf het openbare internet als de workloads de toepassing beschikbaar maken via een Azure Load Balancer.
Deze NVA-injectiemethode biedt de volgende voordelen:
Voor deze methode is SNAT niet vereist om verkeerssymmetrie te garanderen.
U kunt dezelfde NVA's gebruiken om verkeer van en naar verschillende virtuele netwerken te inspecteren, wat multitenancy biedt vanuit het NVA-perspectief.
Virtuele netwerkpeering is niet vereist tussen het virtuele NVA-netwerk en de virtuele netwerken van de workload, wat de configuratie vereenvoudigt.
UDR's zijn niet vereist in het virtuele workloadnetwerk, wat ook de configuratie vereenvoudigt.
U kunt service-injectie via Gateway Load Balancer gebruiken voor inkomend verkeer naar een openbare Azure-load balancer, het retourverkeer en uitgaand verkeer van Azure. East-West verkeer tussen virtuele Azure-machines kan Gateway Load Balancer niet gebruiken voor NVA-injectie.
In het NVA-cluster detecteren de gezondheidscontroles van Azure Load Balancer storingen in afzonderlijke NVA-exemplaren, waardoor een snelle convergentietijd van 10 tot 15 seconden mogelijk is.
Dynamisch openbaar IP-adres en UDR-beheer
Het doel van dit ontwerp is om een installatie te hebben die zonder NVA-redundantie functioneert en kan worden gewijzigd als de NVA uitvaltijd ondervindt. In het volgende diagram ziet u hoe een openbaar IP-adres van Azure wordt gekoppeld aan een actieve NVA (NVA1) in het diagram. De UDR's in de spokes gebruiken het IP-adres van de actieve NVA (10.0.0.37) als de volgende hop.
Als de actieve NVA niet meer beschikbaar is, roept de stand-by NVA de Azure-API aan om het openbare IP-adres en de spoke-UDR's opnieuw toe te kennen aan zichzelf of het privé-IP-adres over te nemen. Het kan enkele minuten duren voordat deze API-aanroepen effectief zijn. Dit ontwerp biedt de slechtste convergentietijd tussen de opties in dit artikel.
Dit ontwerp ondersteunt alleen actieve/stand-byconfiguraties, wat kan leiden tot schaalbaarheidsproblemen. Als u de bandbreedte wilt verhogen die door uw NVA's wordt ondersteund, moet u beide instances opschalen.
Voor dit ontwerp is SNAT niet vereist om verkeerssymmetrie te garanderen, omdat er op elk moment slechts één NVA actief is.
Bijdragers
Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.
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.