Hybride connectiviteit: Connect on-premises met Azure

Dit artikel helpt u bij het kiezen en plannen van de juiste connectiviteitsoptie voor het verbinden van uw on-premises netwerk met Azure virtuele netwerken (VNets).

Wat in dit artikel wordt behandeld

In dit artikel worden de ontwerpbeslissingen beschreven voor het verbinden van on-premises netwerken met Azure VNets met behulp van Azure VPN-gateway of Azure ExpressRoute. U leert wanneer u elke optie gebruikt, hoe deze samenwerken en hoe u uw gateway-implementatie plant. Voor een overzicht op hoog niveau van de hybride connectiviteitsdiensten, zie Wat is hybride connectiviteit?

Wie heeft dit artikel nodig

Lees dit artikel als een of meer van deze voorwaarden van toepassing zijn:

  • Uw Azure workloads moeten communiceren met on-premises systemen, gebruikers of datacenters.
  • U moet kiezen tussen VPN Gateway en ExpressRoute op basis van bandbreedte, latentie, tolerantie of kosten.
  • U hebt een privé- of versleuteld pad nodig voor identiteits-, gegevens-, beheer- of toepassingsafhankelijkheden die buiten Azure blijven.
  • U moet de gatewaytopologie, redundantie of co-existentie tussen VPN en ExpressRoute plannen.

Tip

Volgt u een scenariopad? Selecteer uw scenario bovenaan de pagina voor op maat gemaakte richtlijnen. De volgende kernrichtlijnen zijn van toepassing op alle lezers.

Nadruk op lift-and-shift: Uw gemigreerde workloads moeten communiceren met on-premises systemen. Hybride connectiviteit is uw meest kritieke migratieafhankelijkheid. Zonder een VPN- of ExpressRoute-verbinding kunnen gemigreerde VM's in Azure geen on-premises databases, bestandsshares of identiteitsservices bereiken waarvoor de toepassingen afhankelijk zijn.

Moderniseringsfocus: Uw gemoderniseerde apps hebben mogelijk nog steeds on-premises connectiviteit nodig tijdens de overgangsperiode. Wanneer u workloads migreert naar PaaS-services, blijven sommige afhankelijkheden on-premises totdat de volledige migratie is voltooid. Plan hybride connectiviteit als een brug die je kunt verkleinen of verwijderen terwijl je on-premises afhankelijkheden elimineert.

Cross-cloud focus: Je hebt IPsec VPN-tunnels nodig tussen Azure en AWS of Google Cloud voor versleutelde cross-cloud transit. Toepassingen met afhankelijkheden tussen clouds vereisen veilige, betrouwbare netwerkpaden tussen cloudproviders. Dit connectiviteitsmodel maakt gebruik van Azure VPN-gateway om tunnels te beëindigen van AWS Virtual Private Gateways en Google Cloud VPN-eindpunten.

Azure services en functies

Azure biedt verschillende services voor hybride connectiviteit. Elke service heeft betrekking op verschillende bandbreedte-, latentie-, kosten- en beveiligingsvereisten.

Dienst Wat het biedt Wanneer gebruikt u het?
Azure VPN-gateway (site-to-site) Versleutelde IPsec-/IKE-tunnel via het openbare internet. Verbindt on-premises VPN-apparaten met Azure. Kleinere organisaties, ontwikkel- en testomgevingen, back-upverbindingspad of hybride scenario's met een beperkt budget.
Azure VPN-gateway (point-to-site) Afzonderlijke clientverbindingen met een Azure VNet. Ondersteunt OpenVPN-, SSTP- en IKEv2-protocollen. Externe beheerders of ontwikkelaars die individuele toegang nodig hebben tot Azure resources. Zie het artikel over externe toegang voor gedetailleerde P2S-richtlijnen.
Azure ExpressRoute Privé-toegewezen verbinding via een connectiviteitsprovider. Verkeer gaat niet via het openbare internet. Hybride productieworkloads, latentiegevoelige toepassingen, grote gegevensoverdrachten en wettelijke of nalevingsvereisten.
ExpressRoute met VPN-failover ExpressRoute als de primaire route met VPN Gateway als back-up bij failover. Vereisten voor hoge beschikbaarheid waarbij downtime van ExpressRoute niet acceptabel is.
ExpressRoute Wereldwijde Bereik Verbindt twee locaties op locatie met elkaar via de Azure-backbone door gebruik te maken van hun respectievelijke ExpressRoute-circuits. Bedrijfsnetwerken met meerdere sites die gebruikmaken van Azure als een transit-backbone. Zie het artikel over meerdere clouds en regio's voor meer informatie.
ExpressRoute Direct 10 Gbps, 100 Gbps of 400 Gbps toegewezen connectiviteit direct naar de netwerkrand van Microsoft. Ondersteunt MACsec Layer 2-versleuteling. De hoogste bandbreedtebehoeften, MACsec-versleutelingsvereisten of wanneer u de overhead van de connectiviteitsprovider moet omzeilen. De optie 400 Gbps is beschikbaar op beperkte locaties en vereist inschrijving.

Note

Point-to-site (P2S) VPN biedt individuele client-toegang, die overlapt met de scope van het remote access-artikel. Dit artikel richt zich op P2S als onderdeel van het hybride connectiviteitslandschap. Raadpleeg het artikel over externe toegang voor ontwikkelaars en beheerders voor richtlijnen voor P2S-implementatie, identiteitsintegratie en clientconfiguratie.

Hoe VPN Gateway werkt

Azure VPN-gateway maakt een versleutelde IPsec-/IKE-tunnel tussen uw on-premises VPN-apparaat en een Azure virtuele netwerkgateway. De volgende stappen beschrijven het site-to-site (S2S) tunnelopzetproces:

  1. Gatewayimplementatie: U implementeert een VPN Gateway-resource in het GatewaySubnet van uw hub-VNet. Azure richt twee of meer gateway-exemplaren in (afhankelijk van de SKU en de actief-actieve configuratie). Het inrichten duurt ongeveer 30–45 minuten.
  2. Definitie van lokale netwerkgateway: U maakt een lokale netwerkgatewayresource in Azure die uw on-premises netwerk vertegenwoordigt. Deze resource geeft het openbare IP-adres van uw on-premises VPN-apparaat en de on-premises adresbereiken op die Azure via de tunnel moeten routeren.
  3. Het maken van verbindingsresources: U maakt een verbindingsresource die de VPN Gateway koppelt aan de lokale netwerkgateway. U geeft de gedeelde sleutel (vooraf gedeelde sleutel) en IPsec/IKE-parameters voor de tunnel op.
  4. IKE Fase 1 (hoofdmodus): De Azure-gateway en uw on-premises apparaat onderhandelen over een beveiligd kanaal. Ze wisselen voorstellen uit voor versleutelingsalgoritmen, integriteitsalgoritmen, Diffie-Hellman groepen en verificatiemethoden. Het resultaat is een IKE Security Association (SA).
  5. IKE Fase 2 (Snelle Modus): Door gebruik te maken van het veilige kanaal uit Fase 1, onderhandelen beide partijen over de IPsec SA-parameters: encryptie-algoritme, integriteitsalgoritme en sleutel-levensduur. Dit proces brengt de IPsec-tunnel tot stand.
  6. Verkeersstromen: Zodra beide fasen zijn voltooid, is de tunnel actief. Verkeer dat overeenkomt met de gedefinieerde adresbereiken wordt versleuteld, ingekapseld in IPsec ESP-pakketten en verzonden via het openbare internet naar het externe eindpunt.

Voor actief-actief-configuraties richt Azure twee gateway-exemplaren in, elk met een eigen openbaar IP-adres. Uw apparaat op locatie zet tunnels op met beide instanties, wat automatische failover mogelijk maakt als één instantie niet beschikbaar wordt.

Hoe ExpressRoute werkt

Azure ExpressRoute maakt een privéverbinding tussen uw on-premises netwerk en Azure via een connectiviteitsprovider. In tegenstelling tot VPN gaat verkeer nooit via het openbare internet. Het connectiviteitsmodel omvat drie netwerkranden:

  • Customer edge (CE): Uw router op uw locatie, bij uw datacenter of colocatiefaciliteit. Dit apparaat is gekoppeld aan de edge-router van de provider met behulp van BGP.
  • Edge provider (PE): De router van de connectiviteitsprovider op hun meet-me-locatie (peeringfaciliteit). De provider stelt een Laag 2- of Laag 3-verbinding in tussen uw CE en hun PE.
  • Microsoft edge (MSEE): Microsoft Enterprise Edge-routers in de peeringfaciliteit. De serviceprovider verbindt de PE met de MSEE, waarmee het privépad naar Azure wordt voltooid.

Wanneer u een ExpressRoute-circuit inricht, stelt de provider redundante verbindingen tussen alle drie de randen in. Azure adverteert de adresvoorvoegsels van uw VNet via BGP naar uw CE-router, en uw CE adverteert lokale routes naar Azure. Met deze bidirectionele route-uitwisseling kan verkeer via het privépad stromen.

ExpressRoute ondersteunt twee peeringtypen:

  • Azure private peering: Verbindt met Azure-VNets (IaaS en PaaS met Private Endpoints). Dit peeringtype is het meest voorkomende voor hybride connectiviteit.
  • Microsoft peering: maakt verbinding met Microsoft 365 en Azure openbare services (zoals Azure Storage openbare eindpunten). Vereist routefilters om specifieke servicevoorvoegsels te selecteren.

Vergelijking van ExpressRoute-SKU

Feature Local Standard Premium
Peeringlocaties Een of twee aangewezen metrolocaties Alle peeringlocaties in een geopolitieke regio Alle peeringlocaties wereldwijd
VNet-verbindingen per circuit Is afhankelijk van de gateway-SKU 10 100
Routevoorvoegsels (Microsoft peering) N/A 4,000 10,000
Connectiviteit tussen regio's Alleen hetzelfde metrogebied Dezelfde geopolitieke regio Elke Azure regio wereldwijd
Ondersteuning voor Global Reach Nee. Yes Yes
Prijzen voor gegevensoverdracht Onbeperkt inkomend en uitgaand verkeer (abonnement op basis van verbruik); inbegrepen bij een onbeperkt abonnement Inkomend verkeer gratis; uitgaand verkeer per zone gefactureerd Inkomend verkeer gratis; uitgaand verkeer per zone gefactureerd
Het beste voor Workloads met een hoge bandbreedte in één regio in de buurt van een peeringlocatie Meerdere locaties binnen één geopolitieke regio Wereldwijde onderneming met workloads in meerdere Azure regio's

Tip

De Local SKU biedt aanzienlijke kostenbesparingen omdat de circuitprijs zowel inkomende als uitgaande dataoverdracht omvat. Kies Lokaal wanneer uw Azure regio zich in of in de buurt van dezelfde metro bevindt als de peeringlocatie.

Vergelijking van de VPN Gateway-SKU’s

Artikelnummer (SKU) Maximum aantal S2S-tunnels Maximum aantal P2S-verbindingen Benchmark voor geaggregeerde doorvoer Zone-redundant
VpnGw1 / VpnGw1AZ 30 250 650 Mbps Alleen AZ-variant
VpnGw2 / VpnGw2AZ 30 500 1,0 Gbps Alleen AZ-variant
VpnGw3 / VpnGw3AZ 30 1,000 2,0 Gbps Alleen AZ-variant
VpnGw4 / VpnGw4AZ 100 5,000 5,0 Gbps Alleen AZ-variant
VpnGw5 / VpnGw5AZ 100 10,000 10,0 Gbps Alleen AZ-variant

Note

Doorvoerbenchmarks zijn geaggregeerd over alle tunnels en verbindingen. De werkelijke doorvoer is afhankelijk van verkeerspatronen, pakketgrootten en het aantal actieve tunnels. Selecteer altijd de AZ-variant voor productie-implementaties om zone-redundante beschikbaarheid te verkrijgen.

Hoe te kiezen

Gebruik de volgende beslissingstabellen om de juiste connectiviteitsoptie te selecteren en te bepalen waar u uw gateway wilt plaatsen.

VPN Gateway versus ExpressRoute

Consideratie Kies een VPN Gateway ExpressRoute kiezen
Budget Lagere kosten. Gatewaykosten per uur plus kosten voor gegevensoverdracht. Hogere kosten. Providercircuitkosten, gatewaykosten en kosten voor gegevensoverdracht.
Benodigde bandbreedte Maximaal 10 Gbps geaggregeerde doorvoersnelheid (VpnGw5 SKU). De doorvoer van afzonderlijke tunnels is lager. Maximaal 100 Gbps per circuit. ExpressRoute Direct ondersteunt maximaal 400 Gbps.
Latentietolerantie Hogere latentie acceptabel. Verkeer gaat via het openbare internet. Lage, voorspelbare latentie vereist. Verkeer volgt een privépad.
SLA voor betrouwbaarheid Hoger met een actief-actief-gatewayconfiguratie. Hoger voor het circuit, en het hoogst met een implementatie van een zone-redundante gateway (AZ SKU). Zie Azure Service Level Agreements.
Privacy en naleving Het verkeer blijft versleuteld maar doorkruist het openbare internet. Verkeer gaat nooit via het openbare internet.
Implementatiesnelheid Van uren tot dagen. Het inrichten van de gateway duurt ongeveer 45 minuten. Weken tot maanden. Aanschaf van providercircuits vereist inrichting van fysieke infrastructuur.
Bestaand ExpressRoute-circuit Gebruik VPN Gateway als back-uppad naast ExpressRoute. Gebruik dit als het primaire verbindingspad.

Diagram dat een site-to-site VPN-pad over het publieke internet vergelijkt met een ExpressRoute private-peeringpad, beide eindigend bij de hub GatewaySubnet.

Waar woont de gateway?

Topology Plaatsing van de gateway Onderbouwing
Hub-and-spoke Gateway in het hub-VNet Alle spoke-workloads routeren on-premises verkeer via de hub. Centraliseert connectiviteitsbeheer. Zie het hub-and-spoke-artikel.
Enkele werklast (vlak) Gateway in het workload-VNet Eenvoudigere architectuur voor zelfstandige workloads die geen connectiviteit delen met andere VNets.

Opties voor ExpressRoute-veerkracht

De volgende tabel bevat een overzicht van het verhogen van de beschikbaarheid van ExpressRoute. Zie Azure serviceovereenkomsten voor actuele SLA-percentages.

Tolerantieniveau Configuratie SLA
Standard Eén ExpressRoute-circuit met redundante kruisverbindingen. SLA op circuitniveau
Zone-redundante gateway Zet een ExpressRoute-gateway uit door gebruik te maken van een AZ SKU (ErGw1AZ, ErGw2AZ of ErGw3AZ). Instanties zijn verdeeld over beschikbaarheidszones. SLA op gatewayniveau
Maximum Dubbele circuits in verschillende peeringlocaties met zone-redundante gateways en VPN-failover. Hoogste samengestelde beschikbaarheid

Diagram toont on-premises verbonden via een primair ExpressRoute-pad en een gestreept VPN-failoverpad naar de hubgateways en firewall.

Implementatiebeslissing: Gateway-plaatsing voorbeeld

Overweeg een organisatie met een hub-and-spoke-netwerk met drie spoke-VNets voor productie, test en ontwikkeling. Voor de productieworkloads is ExpressRoute vereist voor databasereplicatie met lage latentie, terwijl ontwikkeling gebruikmaakt van VPN Gateway voor kostenefficiëntie.

Aanbevolen plaatsing:

  1. Zet zowel een ExpressRoute-gateway als een VPN Gateway in het GatewaySubnet van de hub VNet (vereist een /26-subnet voor co-existentie).
  2. Verbind de productie- en staging-spokes via VNet-peering met de hub, met gatewaytransit ingeschakeld. Deze spaken gebruiken de ExpressRoute-route voor on-premises-verbindingen.
  3. Verbind de spoke voor ontwikkeling met de hub met gatewaytransit ingeschakeld. Configureer routetabellen zodat ontwikkeling van verkeer met voorkeur gebruikmaakt van de VPN-tunnel, waardoor de kosten voor ExpressRoute-gegevensoverdracht worden verminderd.
  4. Configureer de VPN-verbinding als een failoverpad voor productie als het ExpressRoute-circuit te maken heeft met een storing van een provider.

Deze aanpak centraliseert gatewaybeheer in één hub, minimaliseert het aantal benodigde gatewayresources en stemt elke spoke af op het juiste connectiviteitsniveau voor de werklastvereisten.

Kostenoverwegingen

VPN Gateway en ExpressRoute hebben verschillende prijsmodellen. Als u deze modellen begrijpt, kunt u de uitgaven optimaliseren.

Kostenonderdeel VPN Gateway ExpressRoute
Gateway-uurtarief Kosten per uur op basis van SKU (VpnGw1 is de goedkoopste) Kosten per uur op basis van gateway-SKU (ErGw1AZ is de goedkoopste)
Circuit-/aansluitkosten Geen circuitkosten; alleen de gateway en gegevensoverdracht Maandelijkse poortkosten betaald aan Microsoft, plus providerkosten voor het fysieke circuit
Gegevensoverdracht: inkomend Gratis Gratis
Gegevensoverdracht: uitgaand Wordt per GB in rekening gebracht tegen de standaardtarieven voor uitgaand Azure-dataverkeer Abonnement op basis van verbruik: kosten per GB. Onbeperkt abonnement: vast maandelijks tarief. Lokale SKU: opgenomen
Providerkosten Geen (gebruikt openbaar internet) Maandelijkse kosten voor de connectiviteitsprovider voor poort en cross-connect
Gebruikelijk maandelijks bereik $140–$2.500 (alleen voor de gateway; dataverkeer verschilt) $500–$15.000+ (gateway + circuit + provider; is afhankelijk van bandbreedte en SKU)

Tips voor kostenoptimalisering:

  • Gebruik de lokale SKU voor ExpressRoute wanneer uw workloads zich in hetzelfde metrogebied bevinden als de peeringlocatie. Deze keuze elimineert uitgaande kosten voor gegevensoverdracht.
  • Kies het abonnement met datalimiet voor ExpressRoute als uw uitgaande gegevensoverdracht minder is dan ongeveer 10 TB/maand. Gebruik het onbeperkte abonnement voor workloads met een hoger volume.
  • Zet VPN Gateway uit als failover in plaats van als een tweede ExpressRoute-circuit als je een beperkt budget hebt maar toch redundantie nodig hebt.
  • Geef uw VPN Gateway SKU de juiste grootte. Start met VpnGw2AZ voor de meeste productieworkloads en schaal alleen op als u merkt dat de doorvoer consequent verzadigd raakt.
  • Controleer uw gatewaygebruik maandelijks. Metrische gegevens van Azure Monitor tonen de tunneldoorvoer en het aantal verbindingen, zodat u overgedimensioneerde gateways kunt identificeren.

Ontwerpoverwegingen

Voor lift-and-shift-migraties is VPN Gateway in het hub-VNet doorgaans de eerste connectiviteitsresource die u implementeert:

  • De VPN Gateway in het hub-VNet. Implementeer VPN Gateway in de GatewaySubnet van de hub. Alle spoke-workloads hebben via gatewaytransit toegang tot on-premises resources. Site-to-site VPN is doorgaans de eerste keuze omdat het binnen enkele uren kan worden geïmplementeerd, in plaats van de weken die het inrichten van een ExpressRoute-circuit vergt.
  • Bandbreedte aanpassen aan de toepassingsvereisten. Verzamel bandbreedtevereisten voor elke migratieworkload. Tel de maximale behoefte aan gelijktijdige doorvoer bij elkaar op en selecteer een VPN Gateway SKU die dit totaal ondersteunt. Begin met VpnGw2AZ voor de meeste productieworkloads. Als uw aggregaties groter zijn dan 1 Gbps, evalueert u ExpressRoute of een hogere VPN Gateway-laag.
  • Plan ExpressRoute als vervolgstap. Veel organisaties beginnen met VPN tijdens de eerste migratiegolven en voegen vervolgens ExpressRoute toe voor productieworkloads waarvoor voorspelbare latentie of hogere bandbreedte is vereist. De hub GatewaySubnet ondersteunt beide gateway-types tegelijkertijd.

Voor gemoderniseerde architecturen met implementaties in meerdere regio's plant u zone-redundante gateways in beide regio's:

  • Zone-redundante VPN-gateways in beide regio's. Implementeer een VPN Gateway met een AZ-SKU (VpnGw2AZ of hoger) in de hubs van zowel de primaire als de back-upregio. Zone-redundante implementatie distribueert gateway-exemplaren over beschikbaarheidszones en biedt een SLA voor hogere beschikbaarheid voor het gatewayonderdeel. Zie Azure serviceovereenkomsten voor specifieke SLA-percentages.
  • Capaciteit voor storing in één regio. De grootte van elke regionale gateway aanpassen om de volledige belasting van het verkeer onafhankelijk te verwerken. Als één regio uitvalt, wordt al het hybride verkeer gerouteerd via de gateway van de overlevende regio. Vermijd het onder inrichten van de gateway van de back-upregio.
  • Overgangsplanning. Hybride connectiviteit in een moderniseringsscenario is vaak tijdelijk. Aangezien PaaS-services on-premises afhankelijkheden vervangen, kunt u de capaciteit van de gateway verminderen of gateways verwijderen zodra alle workloads cloudeigen zijn.

Voor connectiviteit tussen clouds brengt VPN Gateway versleutelde tunnels tot stand met andere cloudproviders:

  • VPN-verbindingen met de virtuele privégateway van AWS. Site-naar-site-VPN-verbindingen maken van Azure VPN-gateway naar virtuele AWS-privégateways. Configureer BGP voor dynamische routering tussen Azure VNets en AWS VPN's. Elke AWS VPN-tunnel ondersteunt maximaal 1,25 Gbps (AWS-side limit); meerdere tunnels of ECMP gebruiken voor een hogere geaggregeerde doorvoer.
  • VPN-verbindingen met Google Cloud VPN. Site-naar-site-VPN-verbindingen maken van Azure VPN-gateway naar Google Cloud VPN (HA VPN). Google Cloud HA VPN biedt twee tunneleindpunten voor redundantie. Configureer BGP-peering voor automatische routedoorgifte tussen Azure en Google Cloud.
  • Implementeren binnen Virtual WAN of hub. Als u Virtual WAN als uw transitmodel hebt gekozen, implementeert u VPN-verbindingen vanuit de Virtual WAN hub in plaats van een zelfstandige VPN Gateway. Als je voor een traditionele hub-spoke kiest, implementeer dan in de hubGatewaySubnet. Beide benaderingen ondersteunen dezelfde IPsec/IKE-tunnels naar AWS en Google Cloud.

Prerequisites

Voordat u hybride connectiviteit implementeert, moet u controleren of aan de volgende vereisten is voldaan:

  • Virtueel netwerk met een GatewaySubnet: Uw VNet moet een toegewezen subnet GatewaySubnet bevatten met een minimale grootte van /27 (of /26 als u expressRoute- en VPN-gateways wilt gebruiken). Zie het artikel VNets en subnetten voor richtlijnen voor het plannen van VNets en subnetten.
  • On-premises VPN-apparaat (voor VPN Gateway): een compatibel VPN-apparaat dat IKEv2 en IPsec ondersteunt. Microsoft onderhoudt een lijst met gevalideerde VPN-apparaten.
  • Connectiviteitsproviderrelatie (voor ExpressRoute): Een contract met een ExpressRoute-connectiviteitsprovider of ExpressRoute Direct-poorttoewijzing. Voor het inrichten van providers is een uitwisseling van servicesleutels en configuratie van fysieke verbindingen vereist.
  • Planning van IP-adressen: Niet-overlappende adresbereiken tussen on-premises- en Azure-netwerken. Plan gatewaysubnetadressen als onderdeel van uw algehele IP-strategie. Zie het artikel over IP-planning.
  • Border Gateway Protocol (BGP) ondersteuning: ExpressRoute vereist BGP, en het wordt aanbevolen voor dynamische routering van VPN Gateway. Controleer of uw on-premises apparatuur BGP ondersteunt.

Beveiligingsoverwegingen

Hybride connectiviteit introduceert beveiligingsgrenzen waarvoor zorgvuldige planning is vereist. Elk verbindingstype heeft verschillende bedreigingsprofielen en risicobeperkingsstrategieën.

ExpressRoute-verkeer is niet standaard versleuteld

ExpressRoute biedt een privépad, maar versleutelt standaard geen verkeer op de netwerklaag. Dit gebrek aan encryptie betekent dat iedereen met fysieke toegang tot de infrastructuur van de provider theoretisch het verkeer zou kunnen onderscheppen. Houd rekening met de volgende versleutelingsopties op basis van uw risicoprofiel:

  • MACsec (laag 2): Alleen beschikbaar op ExpressRoute Direct. Versleutelt verkeer op de fysieke koppeling tussen uw edge-routers en de edge van Microsoft. Je moet MACsec expliciet inschakelen na poortprovisioning. Deze optie biedt versleuteling op lijnsnelheid met minimale extra latentie.
  • IPsec via ExpressRoute (laag 3): Voer een VPN-tunnel uit via de persoonlijke ExpressRoute-peeringverbinding voor end-to-end-versleuteling. Deze benadering werkt met elk ExpressRoute-circuit en versleutelt verkeer via zowel het providernetwerk als de Microsoft backbone. De VPN Gateway SKU beperkt de doorvoersnelheid.
  • Versleuteling van toepassingslaag: Gebruik TLS/HTTPS op toepassingsniveau. Deze benadering is onafhankelijk van het verbindingstype en beschermt gegevens, ongeacht het onderliggende transport. Dit is de meest voorkomende en aanbevolen minimale versleuteling voor alle hybride workloads.

Voor de meeste organisaties biedt de combinatie van het ExpressRoute-privépad plus TLS op de toepassingslaag voldoende beveiliging. Voeg MACsec of IPsec alleen toe via ExpressRoute wanneer wettelijke vereisten netwerklaagversleuteling vereisen voor gegevens die worden overgedragen.

Asymmetrische routering verstoort firewalls met statusbewaking

Wanneer u meerdere connectiviteitspaden gebruikt, zoals ExpressRoute en VPN, kan verkeer verschillende binnenkomende en uitgaande paden volgen. Stateful firewalls verwijderen retourverkeer dat binnenkomt op een andere interface dan de oorspronkelijke aanvraag. Plan uw routering om symmetrische paden te garanderen of gebruik routetabellen en BGP-kenmerken om de verkeersstroom te beheren.

Risicobeperkingsstrategieën zijn onder andere:

  • Configureer BGP AS-path prepending op het back-uppad om ervoor te zorgen dat dit minder de voorkeur krijgt.
  • Gebruik routetabellen (UDR's) op subnetten om verkeer via een specifieke gateway af te dwingen.
  • Configureer BGP-communities en lokale voorkeur om de routekeuze deterministisch te beïnvloeden.
  • Test failoverscenario’s om te controleren of het verkeer terugkeert via hetzelfde pad als waarlangs het is binnengekomen.

Waarschuwing voor GatewaySubnet NSG

Caution

Pas geen netwerkbeveiligingsgroepen (NSG's) toe op het GatewaySubnet, tenzij u de impact volledig begrijpt. Onjuist geconfigureerde NSG-regels op gatewaysubnet kunnen alle hybride connectiviteit verbreken. De gateway vereist specifieke communicatie tussen besturingsvlakken die NSG-regels per ongeluk kunnen blokkeren.

Als u NSG's moet toepassen op de GatewaySubnet, sta dan minimaal verkeer van de GatewayManager-servicetag en de AzureLoadBalancer-servicetag toe. Raadpleeg de gatewaydocumentatie voor de volledige lijst met vereiste regels voordat u wijzigingen aanbrengt.

Site-to-site VPN-versleuteling

IKEv2/IPsec versleutelt altijd site-to-site VPN-verkeer tijdens het transport. U configureert de versleutelingsalgoritmen en de belangrijkste sterke punten als onderdeel van het IPsec-/IKE-beleid voor de verbinding. Gebruik aangepaste beleidsregels om specifieke cryptografische algoritmen af te dwingen in plaats van te vertrouwen op standaardwaarden.

Aanbevolen aangepaste beleidsinstellingen voor productieworkloads:

  • IKE-fase 1: AES-256-versleuteling, SHA-256-integriteit, DH-groep 14 of hoger
  • IKE-fase 2 (IPsec): AES-256-GCM-versleuteling, PFS-groep 14 of hoger
  • Standaard SA-levensduur: 28.800 seconden (IKE), 3.600 seconden (IPsec)

Vermijd het gebruik van afgeschafte algoritmen (DES, 3DES, MD5, SHA-1, DH Group 1/2), hoewel Azure ze nog steeds ondersteunt voor achterwaartse compatibiliteit.

Point-to-site VPN-authenticatie

P2S VPN ondersteunt Microsoft Entra ID verificatie met MFA-integratie (MultiFactor Authentication). Deze optie biedt op identiteit gebaseerd toegangsbeheer voor afzonderlijke clients die verbinding maken met Azure. P2S VPN ondersteunt ook certificaatgebaseerde en RADIUS-authenticatie.

Kies de verificatiemethode op basis van uw vereisten:

Method Ideaal voor Beveiligingspostuur
Microsoft Entra ID Organisaties gebruiken al Microsoft Entra ID met Microsoft Entra Voorwaardelijke toegang Sterkste: ondersteunt MFA, apparaatcompatibiliteit en beleid op basis van risico's
Op basis van certificaten Omgevingen zonder Microsoft Entra ID of voor machine-naar-machine-verbindingen Sterk: vereist PKI-infrastructuur- en certificaatlevenscyclusbeheer
RADIUS Integratie met bestaande on-premises identiteitssystemen (NPS, derden) Varieert: is afhankelijk van de configuratie van de RADIUS-server en back-endverificatie

Meer informatie

Volgende stappen 

Tip

Zelf verkennen? Ga terug naar de overzichtsnavigator om uw volgende artikel per mogelijkheid te vinden.

De volgende stap in uw lift-and-shift-traject:

Veilige beheerderstoegang tot uw VM's instellen: Implementeer Azure Bastion in uw hub-VNet, zodat beheerders RDP/SSH kunnen gebruiken voor gemigreerde VM's zonder openbare IP-blootstelling.

Vervolgens in uw moderniseringstraject:

Ontwerp uw binnenkomende internetpatronen: Bepaal hoe klantgericht verkeer uw Front Door-, Traffic Manager- en Application Gateway-eindpunten bereikt.

De volgende stap in uw cross-cloudtraject:

Plan DNS-omschakeling en naamresolutie: Breng uw bestaande DNS-records in kaart, verlaag de TTL's en configureer Privé-DNS Resolver voor cross-cloud naamresolutie.