Handleiding voor Private Link en DNS in Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

Met Azure Private Link hebben clients rechtstreeks vanuit particuliere virtuele netwerken toegang tot PaaS-services (Platform as a Service) zonder openbare IP-adressen te gebruiken. Voor elke service configureert u een privé-eindpunt dat gebruikmaakt van een privé-IP-adres van uw netwerk. Clients kunnen vervolgens het privé-eindpunt gebruiken om privé verbinding te maken met de service.

Clients blijven de FQDN(Fully Qualified Domain Name) van een service gebruiken om er verbinding mee te maken. U configureert DNS in uw netwerk om de FQDN van de service om te stellen op het privé-IP-adres van het privé-eindpunt.

Uw netwerkontwerp en, met name uw DNS-configuratie, zijn belangrijke factoren bij het ondersteunen van privé-eindpuntconnectiviteit met services. Dit artikel is een van een reeks artikelen die richtlijnen bieden voor het implementeren van verschillende Private Link-scenario's. Zelfs als geen van de scenario's exact overeenkomt met uw situatie, moet u de ontwerpen kunnen aanpassen aan uw behoeften.

Netwerktopologie starten

De beginnetwerktopologie is een netwerkarchitectuur die fungeert als uitgangspunt voor alle scenario's in deze reeks artikelen. De architectuur is een typisch hub-spoke-netwerk dat gebruikmaakt van Azure Virtual WAN.

Afbeelding 1: Netwerktopologie starten voor alle privé-eindpunten en DNS-scenario's

Download een Visio-bestand van deze architectuur. Deze topologie heeft de volgende kenmerken:

Het is een hub-spoke-netwerk dat is geïmplementeerd met Azure Virtual WAN.
Er zijn twee regio's, elk met een regionale met Azure Firewall beveiligde virtuele hub.
Elke beveiligde regionale virtuele hub heeft de volgende beveiligingsinstellingen voor Azure Virtual Network-verbindingen:
- Internetverkeer: beveiligd door Azure Firewall : al het verkeer naar internet stroomt via de regionale hubfirewall.
- Privéverkeer: beveiligd door Azure Firewall: al het verkeer dat van spoke naar spoke stroomt via de regionale hubfirewall.
Elke regionale virtuele hub wordt beveiligd met Azure Firewall. De regionale hubfirewalls hebben de volgende instellingen:
- DNS-servers: standaard (opgegeven in Azure): de regionale hubfirewall maakt expliciet gebruik van Azure DNS voor FQDN-omzetting in regelverzamelingen.
- DNS-proxy: ingeschakeld : de regionale hubfirewall reageert op DNS-query's op poort 53. Hiermee worden query's doorgestuurd naar Azure DNS voor niet-cachewaarden.
- De firewall registreert regelevaluaties en DNS-proxyaanvragen naar een Log Analytics-werkruimte die zich in dezelfde regio bevindt. Logboekregistratie van deze gebeurtenissen is een algemene vereiste voor netwerkbeveiligingslogboekregistratie.
Elke verbonden virtuele netwerk-spoke heeft de standaard-DNS-server geconfigureerd als het privé-IP-adres van de regionale hubfirewall. Anders kan de evaluatie van de FQDN-regel niet worden gesynchroniseerd.

Routering voor meerdere regio's

Beveiligde Virtual WAN-hubs bieden beperkte ondersteuning voor connectiviteit tussen hubs wanneer er meerdere beveiligde virtuele hubs zijn. Deze beperking is van invloed op scenario's met meerdere hubs, regio's en regio's. De netwerktopologie vereenvoudigt daarom niet rechtstreeks het filteren van privéverkeer tussen regio's via Azure Firewall. Ondersteuning voor deze mogelijkheid wordt geleverd met behulp van routeringsintentie en routeringsbeleid voor Virtual WAN-hubs. Deze functionaliteit is momenteel beschikbaar als preview.

Voor deze reeks artikelen wordt ervan uitgegaan dat intern beveiligd verkeer niet meerdere hubs doorkruist. Verkeer dat meerdere hubs moet doorlopen, moet dit doen op een parallelle topologie die privéverkeer niet filtert via een beveiligde virtuele hub, maar in plaats daarvan doorgeeft.

Spoke-netwerken toevoegen

Wanneer u spoke-netwerken toevoegt, volgen ze de beperkingen die zijn gedefinieerd in de beginnetwerktopologie. Elk spoke-netwerk is gekoppeld aan de standaardroutetabel die zich in de regionale hub bevindt en de firewall is geconfigureerd om zowel internet- als privéverkeer te beveiligen. In de volgende schermopname ziet u een configuratievoorbeeld:

Afbeelding 2: Beveiligingsconfiguratie voor virtuele netwerkverbindingen in de virtuele hub

Belangrijke uitdagingen

De beginnetwerktopologie zorgt voor uitdagingen voor het configureren van DNS voor privé-eindpunten.

Hoewel het gebruik van Virtual WAN u een beheerde hub-ervaring biedt, is het nadeel dat er beperkte mogelijkheden zijn om de configuratie van de virtuele hub te beïnvloeden of de mogelijkheid om meer onderdelen eraan toe te voegen. Met een traditionele stertopologie kunt u workloads in spokes isoleren terwijl u algemene netwerkservices, zoals DNS-records, deelt in de zelfbeheerde hub. Doorgaans koppelt u de privé-DNS-zone aan het hubnetwerk, zodat Azure DNS IP-adressen voor privé-eindpunten voor clients kan omzetten.

Het is echter niet mogelijk om privé-DNS-zones te koppelen aan Virtual WAN-hubs, dus elke DNS-resolutie die binnen de hub plaatsvindt, is niet op de hoogte van privézones. Dit is een probleem voor Azure Firewall, de geconfigureerde DNS-provider voor workload-spokes, die DNS gebruikt voor FQDN-omzetting.

Wanneer u Virtual WAN-hubs gebruikt, lijkt het intuïtief dat u privé-DNS-zones koppelt aan de virtuele spoke-netwerken waar workloads DNS-omzetting verwachten. Zoals aangegeven in de architectuur is DNS-proxy echter ingeschakeld op de regionale firewalls en wordt verwacht dat alle spokes hun regionale firewall gebruiken als hun DNS-bron. Azure DNS wordt aangeroepen vanuit de firewall in plaats van vanuit het netwerk van de werkbelasting, zodat alle privé-DNS-zonekoppelingen in het workloadnetwerk niet worden gebruikt in de resolutie.

Notitie

Als u de regionale firewall wilt configureren als dns-provider van de spoke, stelt u de aangepaste DNS-server in het virtuele spoke-netwerk in op het privé-IP-adres van de firewall in plaats van op de normale Azure DNS-waarde.

Gezien de complexiteit die het gevolg is van het inschakelen van DNS-proxy op de regionale firewalls, gaan we de redenen bekijken om deze in te schakelen.

Netwerkregels van Azure Firewall ondersteunen op FQDN-gebaseerde limieten om uitgaand verkeer nauwkeuriger te beheren dat toepassingsregels niet verwerken. Voor deze functie is vereist dat de DNS-proxy is ingeschakeld. Een veelvoorkomend gebruik is het beperken van NTP-verkeer (Network Time Protocol) naar bekende eindpunten, zoals time.windows.com.
Beveiligingsteams kunnen profiteren van logboekregistratie van DNS-aanvragen. Azure Firewall heeft ingebouwde ondersteuning voor logboekregistratie van DNS-aanvragen, zodat alle spoke-resources Azure Firewall gebruiken als hun DNS-provider zorgt voor een brede dekking van logboekregistratie.

Om de uitdagingen te illustreren, beschrijven de volgende secties twee configuraties. Er is een eenvoudig voorbeeld dat werkt en een complexer voorbeeld dat dat niet doet, maar de fout is instructief.

Werkend scenario

Het volgende voorbeeld is een eenvoudige configuratie van een privé-eindpunt. Een virtueel netwerk bevat een client die het gebruik van een PAAS-service via een privé-eindpunt vereist. Een privé-DNS-zone die is gekoppeld aan het virtuele netwerk heeft een A-record waarmee de FQDN van de service wordt omgezet in het privé-IP-adres van het privé-eindpunt. In het volgende diagram ziet u de stroom.

Afbeelding 3: Een basis-DNS-configuratie voor privé-eindpunten

Een Visio-bestand van deze architectuur downloaden.

De client geeft een aanvraag voor stgworkload00.blob.core.windows.net uit.
Azure DNS, de geconfigureerde DNS-server voor het virtuele netwerk, wordt opgevraagd voor het IP-adres voor stgworkload00.blob.core.windows.net.

Als u de volgende opdracht uitvoert vanaf de virtuele machine (VM), ziet u dat de VM is geconfigureerd voor het gebruik van Azure DNS (168.63.129.16) als dns-provider.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
De privé-DNS-zone privatelink.blob.core.windows.net is gekoppeld aan het VNet workload, zodat Azure DNS records van workload-VNet in het antwoord opneemt.
Omdat er een A-record bestaat in de privé-DNS-zone die de FQDN, stgworkload00.privatelink.blob.core.windows.net, toe te voegen aan het privé-IP-adres van het privé-eindpunt, wordt het privé-IP-adres 10.1.2.4 geretourneerd.

Als u de volgende opdracht uitvoert vanaf de VIRTUELE machine, wordt de FQDN van het opslagaccount omgezet in het privé-IP-adres van het privé-eindpunt.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
De aanvraag wordt uitgegeven aan het privé-IP-adres van het privé-eindpunt, dat in dit geval 10.1.2.4 is.
De aanvraag wordt gerouteerd via Private Link naar het opslagaccount.

Het ontwerp werkt omdat Azure DNS:

Is de geconfigureerde DNS-server voor het virtuele netwerk.
Is op de hoogte van de gekoppelde privé-DNS-zone.
Hiermee worden DNS-query's omgezet met behulp van de waarden van de zone.

Scenario zonder werk

Het volgende voorbeeld is een naïeve poging om privé-eindpunten te gebruiken in de beginnende netwerktopologie. Het is niet mogelijk om een privé-DNS-zone te koppelen aan een Virtual WAN-hub. Wanneer clients daarom zijn geconfigureerd voor het gebruik van de firewall als hun DNS-server, worden de DNS-aanvragen doorgestuurd naar Azure DNS vanuit de virtuele hub, die geen gekoppelde privé-DNS-zone heeft. Azure DNS weet niet hoe de query moet worden omgezet door de standaardwaarde op te geven. Dit is het openbare IP-adres.

Afbeelding 4: Een naïeve poging om privé-eindpunten te gebruiken in de beginnende netwerktopologie

Een Visio-bestand van deze architectuur downloaden.

De client geeft een aanvraag voor stgworkload00.blob.core.windows.net uit.

Als u de volgende opdracht uitvoert vanaf de VIRTUELE machine, ziet u dat de VM is geconfigureerd voor het gebruik van de firewall van de virtuele hub als de DNS-provider.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
De firewall heeft DNS-proxy ingeschakeld met de standaardinstelling voor het doorsturen van aanvragen naar Azure DNS. De aanvraag wordt doorgestuurd naar Azure DNS.
Azure DNS kan stgworkload00.blob.core.windows.net niet omgezet in het privé-IP-adres van het privé-eindpunt, omdat:
1. Een privé-DNS-zone kan niet worden gekoppeld aan een Virtual WAN-hub.
2. Azure DNS is niet op de hoogte van een privé-DNS-zone die is gekoppeld aan het virtuele netwerk van de workload, omdat de geconfigureerde DNS-server voor het virtuele workloadnetwerk Azure Firewall is. Azure DNS reageert met het openbare IP-adres van het opslagaccount.
Als u de volgende opdracht uitvoert vanaf de virtuele machine, wordt de FQDN van het opslagaccount omgezet in het openbare IP-adres van het opslagaccount.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
Omdat Azure Firewall DNS-query's proxyt, kunnen we ze registreren. Hieronder ziet u een voorbeeld van azure Firewall DNS-proxylogboeken.
```
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
```
De client ontvangt het privé-IP-adres voor het Private Link-eindpunt niet en kan geen privéverbinding met het opslagaccount tot stand brengen.

Het bovenstaande gedrag wordt verwacht. Het is het probleem dat de scenario's aanpakken.

Scenario's

Hoewel oplossingen voor dit probleem vergelijkbaar zijn, laten veelvoorkomende workloadscenario's zien hoe de oplossingen voldoen aan de vereisten van verschillende situaties. De meeste scenario's bestaan uit een client die toegang heeft tot een of meer PaaS-services via een privé-eindpunt. Ze voldoen aan de beginnetwerktopologie, maar verschillen in hun workloadvereisten. De scenario's beginnen gewoon, met een client die toegang heeft tot één regionale PaaS-service. Ze worden stapsgewijs complexer en voegen meer netwerkzichtbaarheid, regio's en PaaS-services toe.

In de meeste scenario's wordt de client geïmplementeerd als een VIRTUELE machine en is de PaaS-service waartoe de client toegang heeft een opslagaccount. U moet VM's beschouwen als een stand-in voor elke Azure-resource met een NIC die beschikbaar is in een virtueel netwerk, zoals Virtuele-machineschaalsets, Azure Kubernetes Service-knooppunten of een andere service die op een vergelijkbare manier wordt gerouteerd.

Belangrijk

De Private Link-implementatie voor het Azure Storage-account kan op subtiele manieren verschillen van andere PaaS-services, maar het is wel geschikt voor veel. Sommige services verwijderen bijvoorbeeld FQDN-records terwijl ze worden weergegeven via Private Link, wat kan leiden tot verschillende gedragingen, maar dergelijke verschillen zijn meestal geen factor in oplossingen voor deze scenario's.

Elk scenario begint met de gewenste eindstatus en bevat details over de configuratie die nodig is om van de beginnetwerktopologie naar de gewenste eindstatus te komen. De oplossing voor elk scenario maakt gebruik van het patroon voor extensies van virtuele hubs. Met dit patroon wordt uitgelegd hoe gedeelde services op een geïsoleerde en veilige manier beschikbaar worden gemaakt als conceptuele uitbreiding voor een regionale hub. De volgende tabel bevat koppelingen naar het extensiepatroon van de virtuele hub en de scenario's.

Guide	Beschrijving
Eén regio, toegewezen PaaS	Een workload in één regio heeft toegang tot één toegewezen PaaS-resource.

Volgende stappen

Het scenario met één regio, toegewezen PaaS-resource lezen

Handleiding voor Private Link en DNS in Azure Virtual WAN