Guide till Private Link och DNS i Azure Virtual WAN

Azure Private Link gör det möjligt för klienter att komma åt PaaS-tjänster (Plattform som en tjänst) direkt från privata virtuella nätverk utan att använda offentliga IP-adresser. För varje tjänst konfigurerar du en privat slutpunkt som använder en privat IP-adress från nätverket. Klienter kan sedan använda den privata slutpunkten för att ansluta privat till tjänsten.

Klienterna fortsätter att använda det fullständigt kvalificerade domännamnet (FQDN) för en tjänst för att ansluta till den. Du konfigurerar DNS i nätverket för att matcha tjänstens fullständiga domännamn till den privata IP-adressen för den privata slutpunkten.

Din nätverksdesign och i synnerhet din DNS-konfiguration är viktiga faktorer för att stödja privat slutpunktsanslutning till tjänster. Den här artikeln är en av en serie artiklar som ger vägledning om hur du implementerar olika Private Link-scenarier. Även om inget av scenarierna matchar din situation exakt bör du kunna anpassa designerna efter dina behov.

Starta nätverkstopologi

Den inledande nätverkstopologin är en nätverksarkitektur som fungerar som utgångspunkt för alla scenarier i den här artikelserien. Arkitekturen är ett typiskt nav-ekernätverk som använder Azure Virtual WAN.

Bild 1: Starta nätverkstopologi för alla privata slutpunkter och DNS-scenarier

Ladda ned en Visio-fil med den här arkitekturen. Den här topologin har följande egenskaper:

• Det är ett nav-ekernätverk som implementeras med Azure Virtual WAN.
• Det finns två regioner, var och en med en regional Azure Firewall-skyddad virtuell hubb.
• Varje skyddad regional virtuell hubb har följande säkerhetsinställningar för Azure Virtual Network-anslutningar:
  • Internettrafik: Skyddas av Azure Firewall – All trafik ut till Internet flödar via den regionala hubbens brandvägg.
  • Privat trafik: Skyddas av Azure Firewall – All trafik som överförs från eker till ekerflöden via den regionala hubbens brandvägg.
• Varje regional virtuell hubb skyddas med Azure Firewall. Brandväggarna för den regionala hubben har följande inställningar:
  • DNS-servrar: Standard (Azure tillhandahålls) – Den regionala hubbbrandväggen använder uttryckligen Azure DNS för FQDN-matchning i regelsamlingar.
  • DNS-proxy: Aktiverad – Brandväggen för den regionala hubben svarar på DNS-frågor på port 53. Den vidarebefordrar frågor till Azure DNS för ej åtkomliga värden.
  • Brandväggsloggarnas regelutvärderingar och DNS-proxybegäranden till en Log Analytics-arbetsyta som finns i samma region. Loggning av dessa händelser är ett vanligt krav för nätverkssäkerhetsloggning.
• Varje ansluten virtuell nätverkseker har sin standard-DNS-server konfigurerad för att vara den privata IP-adressen för den regionala hubbens brandvägg. Annars kan FQDN-regelutvärderingen vara osynkroniserad.

Routning i flera regioner

Skyddade Virtual WAN-hubbar har begränsat stöd för anslutning mellan hubbar när det finns flera säkra virtuella hubbar. Den här begränsningen påverkar scenarier för flera hubbar, intraregioner och regioner mellan regioner. Därför underlättar inte nätverkstopologin direkt filtrering av privat trafik mellan regioner via Azure Firewall. Stöd för den här funktionen levereras med hjälp av virtual WAN-hubbens routnings- och routningsprinciper. Den här funktionen finns nu i en förhandsversion.

För den här serien med artiklar är antagandet att intern skyddad trafik inte passerar flera hubbar. Trafik som måste passera flera hubbar måste göra det på en parallell topologi som inte filtrerar privat trafik via en säker virtuell hubb, utan låter den passera i stället.

Lägga till ekernätverk

När du lägger till ekernätverk följer de de begränsningar som definieras i den inledande nätverkstopologin. Mer specifikt är varje ekernätverk associerat med standardroutningstabellen som finns i dess regionala hubb, och brandväggen är konfigurerad för att skydda både Internet och privat trafik. Följande skärmbild visar ett konfigurationsexempel:

Bild 2: Säkerhetskonfiguration för virtuella nätverksanslutningar i den virtuella hubben

Viktiga utmaningar

Den inledande nätverkstopologin skapar utmaningar för att konfigurera DNS för privata slutpunkter.

Även om användningen av Virtual WAN ger dig en hanterad hubbupplevelse är kompromissen att det finns begränsad möjlighet att påverka konfigurationen av den virtuella hubben eller möjligheten att lägga till fler komponenter i den. Med en traditionell topologi med nav-ekrar kan du isolera arbetsbelastningar i ekrar samtidigt som du delar vanliga nätverkstjänster, till exempel DNS-poster, i den självhanterade hubben. Du länkar vanligtvis den privata DNS-zonen till hubbnätverket så att Azure DNS kan matcha privata slutpunkts-IP-adresser för klienter.

Det går dock inte att länka privata DNS-zoner till Virtual WAN-hubbar, så alla DNS-matchningar som sker inom hubben är inte medvetna om privata zoner. Mer specifikt är detta ett problem för Azure Firewall, den konfigurerade DNS-providern för arbetsbelastningsekrar, som använder DNS för FQDN-matchning.

När du använder Virtual WAN-hubbar verkar det intuitivt att du länkar privata DNS-zoner till de virtuella ekernätverken där arbetsbelastningarna förväntar sig DNS-matchning. Men som anges i arkitekturen är DNS-proxy aktiverad i de regionala brandväggarna och det förväntas att alla ekrar använder sin regionala brandvägg som DNS-källa. Azure DNS anropas från brandväggen i stället för från arbetsbelastningens nätverk, så eventuella privata DNS-zonlänkar i arbetsbelastningsnätverket används inte i lösningen.

Med tanke på komplexiteten som uppstår vid aktivering av DNS-proxy i de regionala brandväggarna ska vi gå igenom orsakerna till att aktivera den.

• Azure Firewall-nätverksregler stöder FQDN-baserade gränser för att mer exakt kontrollera utgående trafik som programreglerna inte hanterar. Den här funktionen kräver att DNS-proxyn är aktiverad. En vanlig användning är att begränsa NTP-trafik (Network Time Protocol) till kända slutpunkter, till exempel time.windows.com.
• Säkerhetsteam kan dra nytta av loggning av DNS-begäranden. Azure Firewall har inbyggt stöd för loggning av DNS-begäranden, så att kräva att alla ekerresurser använder Azure Firewall som DNS-provider säkerställer bred loggningstäckning.

För att illustrera utmaningarna beskriver följande avsnitt två konfigurationer. Det finns ett enkelt exempel som fungerar, och ett mer komplext exempel som inte gör det, men dess misslyckande är lärorikt.

Arbetsscenario

Följande exempel är en grundläggande privat slutpunktskonfiguration. Ett virtuellt nätverk innehåller en klient som kräver användning av en PAAS-tjänst med hjälp av en privat slutpunkt. En privat DNS-zon som är länkad till det virtuella nätverket har en A-post som löser tjänstens fullständiga domännamn till den privata IP-adressen för den privata slutpunkten. Följande diagram illustrerar flödet.

Bild 3: En grundläggande DNS-konfiguration för privata slutpunkter

Ladda ned en Visio-fil med den här arkitekturen.

1. Klienten skickar en begäran till stgworkload00.blob.core.windows.net.

2. Azure DNS, den konfigurerade DNS-servern för det virtuella nätverket, efterfrågas för IP-adressen för stgworkload00.blob.core.windows.net.

   När du kör följande kommando från den virtuella datorn (VM) visas att den virtuella datorn är konfigurerad att använda Azure DNS (168.63.129.16) som DNS-provider.

   resolvectl status eth0
   
   Link 2 (eth0)
         Current Scopes: DNS
     Current DNS Server: 168.63.129.16
            DNS Servers: 168.63.129.16    
   

3. Den privata DNS-zonen privatelink.blob.core.windows.net är länkad till arbetsbelastnings-VNet, så Azure DNS innehåller poster från arbetsbelastnings-VNet i sitt svar.

4. Eftersom det finns en A-post i den privata DNS-zonen som mappar FQDN, , stgworkload00.privatelink.blob.core.windows.nettill den privata IP-adressen för den privata slutpunkten, returneras den privata IP-adressen 10.1.2.4.

   Om du kör följande kommando från den virtuella datorn matchas FQDN för lagringskontot till den privata IP-adressen för den privata slutpunkten.

   resolvectl query stgworkload00.blob.core.windows.net
   
   stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                       (stgworkload00.privatelink.blob.core.windows.net)
   

5. Begäran utfärdas till den privata IP-adressen för den privata slutpunkten som i det här fallet är 10.1.2.4.

6. Begäran dirigeras via Private Link till lagringskontot.

Designen fungerar eftersom Azure DNS:

• Är den konfigurerade DNS-servern för det virtuella nätverket.
• Är medveten om den länkade privata DNS-zonen.
• Löser DNS-frågor med hjälp av zonens värden.

Scenario utan arbete

Följande exempel är ett naivt försök att använda privata slutpunkter i den inledande nätverkstopologin. Det går inte att länka en privat DNS-zon till en Virtuell WAN-hubb. När klienter konfigureras att använda brandväggen som DNS-server vidarebefordras därför DNS-begäranden till Azure DNS inifrån den virtuella hubben, som inte har någon länkad privat DNS-zon. Azure DNS vet inte hur man löser frågan annat än genom att ange standardvärdet, som är den offentliga IP-adressen.

Bild 4: Ett naivt försök att använda privata slutpunkter i den inledande nätverkstopologin

Ladda ned en Visio-fil med den här arkitekturen.

1. Klienten skickar en begäran till stgworkload00.blob.core.windows.net.

   När du kör följande kommando från den virtuella datorn visas att den virtuella datorn är konfigurerad att använda brandväggen för den virtuella hubben som DNS-provider.

   resolvectl status eth0
   
   Link 2 (eth0)
         Current Scopes: DNS
     Current DNS Server: 10.100.0.132
            DNS Servers: 10.100.0.132    
   

2. Brandväggen har DNS-proxy aktiverad med standardinställningen för att vidarebefordra begäranden till Azure DNS. Begäran vidarebefordras till Azure DNS.

3. Azure DNS kan inte matcha stgworkload00.blob.core.windows.net den privata IP-adressen för den privata slutpunkten eftersom:

   1. En privat DNS-zon kan inte länkas till en Virtuell WAN-hubb.
   2. Azure DNS känner inte till en privat DNS-zon som är länkad till det virtuella arbetsbelastningsnätverket, eftersom den konfigurerade DNS-servern för det virtuella arbetsbelastningsnätverket är Azure Firewall. Azure DNS svarar med lagringskontots offentliga IP-adress.

   Om du kör följande kommando från den virtuella datorn matchas FQDN för lagringskontot till lagringskontots offentliga IP-adress.

   resolvectl query stgworkload00.blob.core.windows.net
   
   stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                       (blob.bn9prdstr08a.store.core.windows.net)
   

   Eftersom Azure Firewall proxyar DNS-frågor kan vi logga dem. Följande är exempel på DNS-proxyloggar för Azure Firewall.

   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    
   

4. Klienten tar inte emot den privata IP-adressen för Private Link-slutpunkten och kan inte upprätta en privat anslutning till lagringskontot.

Ovanstående beteende förväntas. Det är problemet som scenarierna tar itu med.

Scenarier

Även om lösningarna på det här problemet är liknande visar en genomgång av vanliga arbetsbelastningsscenarier hur lösningarna hanterar kraven i olika situationer. De flesta scenarier består av en klient som har åtkomst till en eller flera PaaS-tjänster via en privat slutpunkt. De följer nätverkstopologin som startar, men de skiljer sig åt i sina arbetsbelastningskrav. Scenarierna börjar helt enkelt med en klient som har åtkomst till en enda regional PaaS-tjänst. De blir inkrementellt mer komplexa och lägger till mer nätverkssynlighet, regioner och PaaS-tjänster.

I de flesta scenarier implementeras klienten som en virtuell dator och PaaS-tjänsten som klienten har åtkomst till är ett lagringskonto. Du bör betrakta virtuella datorer som en stand-in för alla Azure-resurser som har ett nätverkskort som exponeras i ett virtuellt nätverk, till exempel VM-skalningsuppsättningar, Azure Kubernetes Service-noder eller någon annan tjänst som dirigerar på ett liknande sätt.

Varje scenario börjar med önskat sluttillstånd och beskriver den konfiguration som krävs för att hämta från startnätverkstopologin till önskat sluttillstånd. Lösningen på varje scenario utnyttjar mönstret för tillägg för virtuella hubbar. Det här mönstret beskriver hur du exponerar delade tjänster på ett isolerat och säkert sätt, som ett konceptuellt tillägg till en regional hubb. Följande tabell innehåller länkar till mönstret för tillägget för virtuell hubb och scenarierna.

Nästa steg

Relaterade resurser

• Vad är en privat slutpunkt?
• DNS-konfiguration för privat slutpunkt i Azure
• Private Link och DNS-integrering i stor skala
• Azure Private Link i ett nav-och-ekernätverk
• DNS för lokala resurser och Azure-resurser
• Datalandningszonanslutning för en region
• Använda Azure Private Link för att ansluta nätverk till Azure Monitor
• Azure DNS Private Resolver
• Förbättrad säkerhetsåtkomst till webbappar med flera klientorganisationer från ett lokalt nätverk
• Baslinje med hög tillgänglighet zonredundant webbapp
• Självstudie: Skapa en privat DNS-infrastruktur för slutpunkter med Azure Private Resolver för en lokal arbetsbelastning