Scenario met één regio : Private Link en DNS in Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

In dit artikel wordt beschreven hoe u een PaaS-resource via een privé-eindpunt beschikbaar maakt voor een specifieke workload in één regio. In het scenario is de netwerktopologie hub-spoke en is de hub een Azure Virtual WAN-hub.

Belangrijk

Dit artikel maakt deel uit van een reeks over Azure Private Link en Azure DNS in Virtual WAN en bouwt voort op de netwerktopologie die is gedefinieerd in de scenariohandleiding. Lees eerst de overzichtspagina om inzicht te krijgen in de basisnetwerkarchitectuur en de belangrijkste uitdagingen.

Scenario

Afbeelding 1: Scenario met één regio voor Virtual WAN met Private Link en Azure DNS: de uitdaging

Download een Visio-bestand van deze architectuur. In deze sectie wordt het scenario gedefinieerd en wordt de uitdaging voor dit scenario opnieuw gedefinieerd (de uitdaging is hetzelfde als het niet-werkvoorbeeld op de overzichtspagina). De eerste scenarioarchitectuur is gebaseerd op de beginnetwerktopologie die is gedefinieerd in de overzichtshandleiding. Hier volgen de toevoegingen en wijzigingen:

Er is slechts één regio met één virtuele hub.
Er is een Azure Storage-account in de regio waarvoor openbare netwerktoegang is uitgeschakeld. De veronderstelling in dit scenario is dat slechts één workload toegang heeft tot het opslagaccount.
Er is in eerste instantie één virtueel netwerk dat is verbonden met de virtuele hub.
Het virtuele netwerk heeft een workloadsubnet dat een vm-client (virtuele machine) bevat.
Het virtuele netwerk bevat een privé-eindpuntsubnet dat een privé-eindpunt voor het opslagaccount bevat.

Geslaagd resultaat

De Azure Virtual Machine-client kan verbinding maken met het Azure Storage-account via het privé-eindpunt van het opslagaccount dat zich in hetzelfde virtuele netwerk bevindt en alle andere toegang tot het opslagaccount wordt geblokkeerd.

Belemmering

U hebt een DNS-record nodig in de DNS-stroom die de FQDN (Fully Qualified Domain Name) van het opslagaccount kan omzetten in het privé-IP-adres van het privé-eindpunt. Zoals vermeld in het overzicht, is de uitdaging met het scenario tweeledige:

Het is niet mogelijk om een privé-DNS-zone te koppelen die de benodigde DNS-records voor opslagaccounts onderhoudt aan een virtuele hub.
U kunt een privé-DNS-zone koppelen aan het workloadnetwerk, zodat u denkt dat dit werkt. Helaas bepaalt de basislijnarchitectuur dat elk verbonden virtueel netwerk DNS-servers heeft geconfigureerd om te verwijzen naar de Azure Firewall DNS-proxy.

Omdat u een privé-DNS-zone niet kunt koppelen aan een virtuele hub en het virtuele netwerk is geconfigureerd voor het gebruik van de Azure Firewall DNS-proxy, hebben Azure DNS-servers geen mechanisme om de (FQDN) van het opslagaccount om te zetten naar het privé-IP-adres van het privé-eindpunt. Het resultaat is dat de client een onjuist DNS-antwoord ontvangt.

DNS- en HTTP-stromen

Laten we de DNS en resulterende HTTP-aanvraagstromen voor deze workload bekijken. De beoordeling helpt ons bij het visualiseren van de belemmeringen die eerder zijn beschreven.

Afbeelding 2: Scenario met één regio voor Virtual WAN met Private Link en Azure DNS: de uitdaging

Een Visio-bestand van deze architectuur downloaden.

DNS-stroom

De DNS-query van stgworkload00.blob.core.windows.net de client wordt verzonden naar de geconfigureerde DNS-server. Dit is Azure Firewall in de gekoppelde regionale hub.
Azure Firewall proxyt de aanvraag naar Azure DNS. Omdat het niet mogelijk is om een privé-DNS-zone te koppelen aan een virtuele hub, weet Azure DNS niet hoe de FQDN moet worden omgezet in het privé-eindpunt privé-IP-adres. Het weet wel hoe de FQDN moet worden omgezet in het openbare IP-adres van het opslagaccount, zodat het openbare IP-adres van het opslagaccount wordt geretourneerd.

HTTP-stroom

Met het DNS-resultaat geeft de client een HTTP-aanvraag stgworkload00.blob.core.windows.netdoor aan het openbare IP-adres van het opslagaccount.
De aanvraag wordt verzonden naar het openbare IP-adres van het opslagaccount. Deze aanvraag mislukt om verschillende redenen:
- De NSG op het workloadsubnet staat dit internetverkeer mogelijk niet toe.
- De Azure Firewall die internetverkeer filtert, heeft waarschijnlijk geen toepassingsregel om deze stroom te ondersteunen.
- Zelfs als zowel de NSG als Azure Firewall wel machtigingen voor deze aanvraagstroom heeft, is het opslagaccount geconfigureerd om alle openbare netwerktoegang te blokkeren. De poging schendt uiteindelijk ons doel om alleen toegang tot het opslagaccount toe te staan via het privé-eindpunt.

Oplossing: een virtuele hub-extensie voor DNS instellen

Een oplossing voor de uitdaging is dat het bedrijfsnetwerkteam een virtuele hub-extensie voor DNS implementeert. De enige verantwoordelijkheid voor de extensie voor de virtuele DNS-hub is het inschakelen van workloadteams die privé-DNS-zones in hun architectuur moeten gebruiken binnen deze beginnende Virtual WAN-hubtopologie.

De DNS-extensie wordt geïmplementeerd als een virtuele netwerk-spoke die is gekoppeld aan de regionale virtuele hub. Het is mogelijk om privé-DNS-zones te koppelen aan dit virtuele netwerk. Het virtuele netwerk bevat ook een privé-Resolver van Azure DNS waarmee services buiten dit virtuele netwerk, zoals Azure Firewall, waarden kunnen opvragen en ontvangen van alle gekoppelde privé-DNS-zones. Hier volgen de onderdelen van een typische virtuele hub-extensie voor DNS, samen met enkele vereiste configuratiewijzigingen:

Een nieuw virtueel spoke-netwerk dat is gekoppeld aan de virtuele hub van de regio. Deze spoke is geconfigureerd zoals elke andere spoke, wat betekent dat standaard-DNS-server en routeringsregels het gebruik van Azure Firewall in de regionale hub afdwingen.
Een privé-dns-resolver-resource wordt geïmplementeerd met een binnenkomend eindpunt in het virtuele spoke-netwerk.
Er wordt een privé-DNS-zoneresource met de naam privatelink.blob.core.windows.net gemaakt.
- Deze zone bevat een A record die wordt toegewezen van de FQDN-naam van het opslagaccount aan het privé-IP-adres van het privé-eindpunt voor het opslagaccount.
- De privé-DNS-zone is gekoppeld aan het virtuele spoke-netwerk.
- Als op rollen gebaseerd toegangsbeheer (RBAC) is toegestaan, kunt u automatische registratie of door de service beheerde vermeldingen gebruiken om deze DNS-records te onderhouden. Zo niet, dan kunt u ze handmatig onderhouden.
In de regionale hub wordt de DNS-server van de Azure Firewall gewijzigd zodat deze verwijst naar het binnenkomende eindpunt van de DNS-privéomzetting.

In het volgende diagram ziet u de architectuur, samen met de DNS- en HTTP-stromen.

Afbeelding 3: Werkende oplossing voor scenario met één regio voor Virtual WAN met Private Link en DNS

Een Visio-bestand van deze architectuur downloaden.

DNS-stroom voor het instellen van een virtuele hub-extensie voor DNS

De DNS-query van stgworkload00.blob.core.windows.net de client wordt verzonden naar de geconfigureerde DNS-server. Dit is Azure Firewall in de gekoppelde regionale hub - 10.100.0.132 in dit geval.

Afbeelding 4: CONFIGURATIE van DNS-servers voor het virtuele netwerk van de workload
Azure Firewall proxyt de aanvraag naar de regionale Azure DNS Private Resolver in de hub-extensie - 10.200.1.4 in dit geval, het privé-IP-adres van het binnenkomende EINDPUNT van de DNS-privéomzetting.

Schermopname van het Azure Firewall-beleid waarbij DNS-proxy is ingeschakeld en de DNS-servers zijn ingesteld op Aangepast. De ingangspunten naar het privé-IP-adres van het invoereindpunt van de DNS-privé-resolver.

Afbeelding 5: DNS-configuratie in Azure Firewall-beleid
Dns Private Resolver proxyt de aanvraag naar Azure DNS. Omdat een privé-DNS-zone is gekoppeld aan het virtuele netwerk met het binnenkomende eindpunt, kan Azure DNS records gebruiken in die gekoppelde privé-DNS-zones.

Afbeelding 6: Privé-DNS zone-koppelingen voor virtueel netwerk
Azure DNS raadpleegt de gekoppelde privé-DNS-zone en zet de FQDN van stgworkload00.blob.core.windows.net op 10.1.2.4, het IP-adres van het privé-eindpunt voor het opslagaccount. Dit antwoord wordt verstrekt aan Azure Firewall DNS, dat vervolgens het privé-IP-adres van het opslagaccount naar de client retourneert.

Afbeelding 7: Privé-DNS zone met de A-record voor het privé-eindpunt van het opslagaccount

HTTP-stroom

Met het DNS-resultaat in hand, het privé-IP-adres van het opslagaccount, geeft de client een HTTP-aanvraag uit aan stgworkload00.blob.core.windows.net.
De aanvraag wordt verzonden naar het privé-IP-adres (10.1.2.4) van het opslagaccount. Deze aanvraag routeert zonder conflicterende beperkingen voor de lokale netwerkbeveiligingsgroepen in het clientsubnet of het subnet van het privé-eindpunt. Het is belangrijk om te weten dat, hoewel Azure Firewall privéverkeer beveiligt, de aanvraag niet wordt gerouteerd via Azure Firewall, omdat het privé-eindpunt zich in hetzelfde virtuele netwerk bevindt als de client. Dit betekent dat er geen Azure Firewall-vergoedingen hoeven te worden gemaakt voor dit scenario.
Er wordt een privéverbinding met het opslagaccount tot stand gebracht via de Private Link-service. Het opslagaccount staat alleen toegang tot het privénetwerk toe en accepteert de HTTP-aanvraag.

Virtuele hub-extensie voor DNS-overwegingen

Houd rekening met de volgende richtlijnen bij het implementeren van de extensie voor uw onderneming.

Het implementeren van de DNS-extensie is geen taak voor het workloadteam. Deze taak is een bedrijfsnetwerkfunctie en moet een implementatiebeslissing met deze personen zijn.
De DNS-extensie en privé-DNS-zones moeten bestaan voordat u een PaaS-service toevoegt waarvoor u DNS-records voor privé-eindpunten wilt configureren.
De virtuele hub-extensie is een regionale resource, vermijd verkeer tussen regio's en stel een hub-extensie per regionale hub in waar DNS-omzetting van privé-eindpunten wordt verwacht.

Virtueel spoke-netwerk

Volgens het principe van één verantwoordelijkheid mag het virtuele netwerk voor de DNS-extensie alleen de resources bevatten die vereist zijn voor DNS-omzetting en mag het niet worden gedeeld met andere resources.
Het virtuele netwerk voor de DNS-extensie moet dezelfde configuratierichtlijnen volgen onder Spoke-netwerken toevoegen.

Azure DNS Private Resolver

Elke regio moet één DNS-extensie voor de virtuele hub hebben met één dns-privéomzetting.
De privé-dns-resolver vereist alleen een binnenkomend eindpunt en geen uitgaande eindpunten voor dit scenario. Het privé-IP-adres voor het binnenkomende eindpunt is ingesteld voor de aangepaste DNS-service in het Azure Firewall-beleid (zie afbeelding 5).
Voor een hogere tolerantie en betere belastingsafhandeling kunt u meerdere exemplaren van privé-DNS-resolver per regio implementeren, waarbij azure DNS-proxy is geconfigureerd met meerdere IP-adressen voor proxied-omzetting.

Afbeelding 8: Binnenkomende eindpunten voor de privé-DNS-resolver
Volg de beperkingen voor het virtuele netwerk voor de DNS Private Resolver.
De netwerkbeveiligingsgroep in het subnet voor het binnenkomende EINDPUNT van de DNS-privéomzetting mag alleen UDP-verkeer van de regionale hub naar poort 53 toestaan. U moet al het andere binnenkomende en uitgaande verkeer blokkeren.

Privé-DNS-zone

Omdat de privé-resolver van Azure DNS DNS via Azure DNS omzet, kan Azure DNS alle privé-DNS-zones ophalen die zijn gekoppeld aan het virtuele netwerk van het binnenkomende subnet.

Koppel de privé-DNS-zone aan de extensie van de virtuele hub voor het virtuele DNS-netwerk.
Volg de richtlijnen voor het beheren van privé-DNS-zones voor privé-eindpunten.
Als u verwacht dat PaaS-resourceeigenaren hun eigen vermeldingen beheren, configureert u RBAC dienovereenkomstig of implementeert u een oplossing, zoals de oplossing van Private Link en DNS-integratie op schaal.

Scenariooverwegingen

Nu een goed beheerde DNS-extensie voor virtuele hubs is ingesteld, gaan we terug naar de workload en gaan we een aantal extra punten aan de slag om de succesvolle resultatendoelstellingen in dit scenario te bereiken.

Opslagaccount

Openbare netwerktoegang instellen: uitgeschakeld onder netwerkconnectiviteit om ervoor te zorgen dat het opslagaccount alleen toegankelijk is via privé-eindpunten.
Voeg een privé-eindpunt toe aan een toegewezen privé-eindpuntsubnet in het virtuele netwerk van de workload.
Azure Diagnostics verzenden naar de Log Analytics-werkruimte van de workload. U kunt de toegangslogboeken gebruiken om configuratieproblemen op te lossen.

Beveiliging van privé-eindpunten

Een vereiste van deze oplossing is om de blootstelling van dit opslagaccount te beperken. Zodra u openbare internettoegang tot uw PaaS-resource hebt verwijderd, moet u de beveiliging van privénetwerken aanpakken.

Wanneer Azure Firewall privéverkeer in een Virtual WAN-stertopologie beveiligt, wordt de standaardinstelling van Azure Firewall ingesteld op het weigeren van spoke-to-spoke-connectiviteit. Met deze standaardinstelling voorkomt u dat workloads in andere spoke-netwerken toegang hebben tot privé-eindpunten (en andere resources) in het virtuele netwerk van de workload. Verkeer volledig binnen een virtueel netwerk wordt niet gerouteerd via Azure Firewall. Als u de toegang binnen het virtuele netwerk wilt beheren en gedetailleerdere beveiliging wilt toevoegen, moet u de volgende aanbevelingen voor netwerkbeveiligingsgroepen (NSG) volgen.

Maak een toepassingsbeveiligingsgroep (ASG) om resources te groeperen die vergelijkbare binnenkomende of uitgaande toegangsbehoeften hebben. In dit scenario gebruikt u een ASG voor de client-VM's die toegang nodig hebben tot opslag en één voor opslagaccounts die worden geopend. Zie een toepassingsbeveiligingsgroep (ASG) configureren met een privé-eindpunt.
Zorg ervoor dat het subnet met de workload-VM een NSG heeft.
Zorg ervoor dat het subnet met de privé-eindpunten een NSG heeft.

NSG-regels voor subnet met workload-VM

Naast andere netwerkregels die uw workload nodig heeft, configureert u de volgende regels.

Regels voor uitgaand verkeer:
- Reken-ASG toegang geven tot opslagaccount ASG.
- Sta reken-ASG toe aan het privé-IP-adres van azure Firewall voor de regionale hub voor UDP op poort 53.

*Afbeelding 9: NSG-regels voor workloadsubnet

NSG-regels voor subnet met privé-eindpunten

Het wordt aanbevolen om privé-eindpunten beschikbaar te maken in een klein, toegewezen subnet binnen het verbruikende virtuele netwerk. Een van de redenen is dat u door de gebruiker gedefinieerde routes en netwerkbeveiligingsgroepsbeleid voor privé-eindpunten kunt toepassen voor extra verkeersbeheer en -beveiliging.

In dit scenario kan een zeer beperkende netwerkbeveiligingsgroep worden toegepast.

Regels voor inkomend verkeer:
- Reken-ASG toegang geven tot opslagaccount ASG
- Al het andere verkeer weigeren
Regels voor uitgaand verkeer:
- Al het verkeer weigeren

*Afbeelding 10: NSG-regels voor subnet van privé-eindpunt

Beveiliging van privé-eindpunten in actie

In de volgende afbeelding ziet u hoe het volgen van de overwegingen die zijn beschreven, diepgaande beveiliging kan bieden. Het diagram toont een tweede spoke virtueel netwerk met een tweede VM. Deze workload heeft geen toegang tot het privé-eindpunt.

Afbeelding 11: Werkende oplossing voor scenario met één regio voor Virtual WAN met Private Link en DNS

Een Visio-bestand van deze architectuur downloaden.

DNS-stroom

De DNS-stroom is precies hetzelfde als in de oplossingsstroom.

Wat belangrijk is om te markeren, is dat de FQDN wordt omgezet in het privé-IP-adres en niet het openbare IP-adres. Deze oplossing betekent dat alle spokes altijd het privé-IP-adres van deze service ontvangen. In een ander scenario wordt beschreven hoe u deze benadering kunt gebruiken om een PaaS-service te delen over meerdere verbruikende workloads. Voor dit scenario met één workload is dit geen probleem.

HTTP-stroom

Met het DNS-resultaat in hand, het privé-IP-adres van het opslagaccount, geeft de client een HTTP-aanvraag uit aan stgworkload00.blob.core.windows.net.
De aanvraag wordt verzonden naar het privé-IP-adres van het opslagaccount. Deze aanvraag mislukt om verschillende redenen:
- Azure Firewall is geconfigureerd om privéverkeer te beveiligen, zodat de aanvraag wordt verwerkt. Tenzij Azure Firewall een netwerk- of toepassingsregel heeft om de stroom toe te staan, blokkeert Azure Firewall de aanvraag.
- U hoeft Azure Firewall niet in de hub te gebruiken om privéverkeer te beveiligen. Als uw netwerk bijvoorbeeld privéverkeer tussen regio's ondersteunt, is de netwerkbeveiligingsgroep op het subnet van het privé-eindpunt nog steeds geconfigureerd om al het verkeer te blokkeren dat niet de reken-ASG-bronnen binnen het virtuele netwerk bevat die als host fungeert voor de workload.

Samenvatting

In dit artikel wordt een scenario geïntroduceerd waarin een VM-client verbinding maakt met het Azure Storage-account via het privé-eindpunt van het opslagaccount. Het eindpunt bevindt zich in hetzelfde virtuele netwerk als de client. Alle andere toegang tot het opslagaccount wordt geblokkeerd. Voor dit scenario is een DNS-record in de DNS-stroom vereist die de FQDN (Fully Qualified Domain Name) van het opslagaccount kan omzetten in het privé-IP-adres van het privé-eindpunt.

De beginnetwerktopologie voor dit scenario introduceert twee uitdagingen:

Het is niet mogelijk om een privé-DNS-zone te koppelen aan de vereiste DNS-records voor het opslagaccount aan de virtuele hub.
Het koppelen van een privé-DNS-zone aan het workloadsubnet werkt niet. Voor de beginnetwerktopologie moeten standaard DNS-server- en routeringsregels het gebruik van Azure Firewall in de regionale hub afdwingen.

De voorgestelde oplossing is dat het bedrijfsnetwerkteam een virtuele hub-extensie voor DNS implementeert. Met deze extensie kan het bedrijfsnetwerkteam gedeelde DNS-services beschikbaar maken voor workload-spokes waarvoor ze zijn vereist.

Delen via

Scenario met één regio : Private Link en DNS in Azure Virtual WAN