Scenario med en region – Private Link och DNS i Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

Den här artikeln visar hur du exponerar en PaaS-resurs över en privat slutpunkt för en specifik arbetsbelastning i en enda region. I scenariot är nätverkstopologin hub-spoke och hubben är en Azure Virtual WAN-hubb.

Viktigt!

Den här artikeln är en del av en serie om Azure Private Link och Azure DNS i Virtual WAN och bygger på nätverkstopologin som definieras i scenarioguiden. Läs översiktssidan först för att förstå grundnätverksarkitekturen och viktiga utmaningar.

Scenario

Bild 1: Scenario med en region för Virtual WAN med Private Link och Azure DNS – utmaningen

Ladda ned en Visio-fil med den här arkitekturen. Det här avsnittet definierar scenariot och omdefinierar utmaningen för det här scenariot (utmaningen är densamma som det icke-arbetande exemplet på översiktssidan). Den inledande scenarioarkitekturen bygger på den startnätverkstopologi som definierats i översiktsguiden. Följande är tilläggen och ändringarna:

Det finns bara en region med en virtuell hubb.
Det finns ett Azure Storage-konto i regionen som har inaktiverad åtkomst till offentligt nätverk. Antagandet i det här scenariot är att endast en arbetsbelastning har åtkomst till lagringskontot.
Det finns till en början ett enda virtuellt nätverk som är anslutet till den virtuella hubben.
Det virtuella nätverket har ett arbetsbelastningsundernät som innehåller en virtuell datorklient .
Det virtuella nätverket innehåller ett privat slutpunktsundernät som innehåller en privat slutpunkt för lagringskontot.

Lyckat resultat

Azure Virtual Machine-klienten kan ansluta till Azure Storage-kontot via lagringskontots privata slutpunkt som finns i samma virtuella nätverk och all annan åtkomst till lagringskontot blockeras.

Hinder

Du behöver en DNS-post i DNS-flödet som kan matcha det fullständigt kvalificerade domännamnet (FQDN) för lagringskontot tillbaka till den privata IP-adressen för den privata slutpunkten. Som du ser i översikten är utmaningen med scenariot dubbel:

Det går inte att länka en privat DNS-zon som underhåller de lagringskonton som krävs för DNS-poster till en virtuell hubb.
Du kan länka en privat DNS-zon till arbetsbelastningsnätverket, så du kanske tror att det skulle fungera. Tyvärr stipulerar baslinjearkitekturen att varje anslutet virtuellt nätverk har DNS-servrar som är konfigurerade att peka på att använda Azure Firewall DNS-proxyn.

Eftersom du inte kan länka en privat DNS-zon till en virtuell hubb och det virtuella nätverket är konfigurerat för att använda Azure Firewall DNS-proxyn har Azure DNS-servrar ingen mekanism för att matcha lagringskontots (FQDN) till den privata IP-adressen för den privata slutpunkten. Resultatet är att klienten tar emot ett felaktigt DNS-svar.

DNS- och HTTP-flöden

Nu ska vi granska DNS-flöden och resulterande HTTP-begärandeflöden för den här arbetsbelastningen. Granskningen hjälper oss att visualisera det hinder som beskrevs tidigare.

Bild 2: Scenario med en region för Virtual WAN med Private Link och Azure DNS – utmaningen

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

DNS-flöde

DNS-frågan för stgworkload00.blob.core.windows.net från klienten skickas till den konfigurerade DNS-servern, som är Azure Firewall i den peerkopplade regionala hubben.
Azure Firewall skickar begäran till Azure DNS. Eftersom det inte går att länka en privat DNS-zon till en virtuell hubb vet Inte Azure DNS hur FQDN ska matchas med den privata slutpunktens privata IP-adress. Den vet hur du löser det fullständiga domännamnet till lagringskontots offentliga IP-adress, så det returnerar lagringskontots offentliga IP-adress.

HTTP-flöde

Med DNS-resultatet i handen, lagringskontots offentliga IP-adress, utfärdar klienten en HTTP-begäran till stgworkload00.blob.core.windows.net.
Begäran skickas till lagringskontots offentliga IP-adress. Den här begäran misslyckas av många orsaker:
- NSG:n i arbetsbelastningens undernät kanske inte tillåter den här Internetbundna trafiken.
- Azure Firewall som filtrerar internetbunden utgående trafik har förmodligen ingen programregel som stöder det här flödet.
- Även om både NSG och Azure Firewall hade utsläppsrätter för det här begärandeflödet är Lagringskontot konfigurerat för att blockera all åtkomst till det offentliga nätverket. Försöket bryter slutligen mot vårt mål att endast tillåta åtkomst till lagringskontot via den privata slutpunkten.

Lösning – Upprätta ett virtuellt hubbtillägg för DNS

En lösning på utmaningen är att företagsnätverksteamet implementerar ett virtuellt hubbtillägg för DNS. Det enda ansvaret för tillägget för den virtuella DNS-hubben är att aktivera arbetsbelastningsteam som behöver använda privata DNS-zoner i sin arkitektur i den här starttopologin för Virtual WAN-hubben.

DNS-tillägget implementeras som en virtuell nätverksekerare som är peer-kopplad till dess regionala virtuella hubb. Det går att länka privata DNS-zoner till det här virtuella nätverket. Det virtuella nätverket innehåller också en privat Lösning för Azure DNS som gör att tjänster utanför det virtuella nätverket, till exempel Azure Firewall, kan köra frågor mot och ta emot värden från alla länkade privata DNS-zoner. Följande är komponenterna i ett typiskt virtuellt hubbtillägg för DNS, tillsammans med några nödvändiga konfigurationsändringar:

Ett nytt virtuellt ekernätverk som är peer-kopplat till regionens virtuella hubb. Den här ekern är konfigurerad som alla andra ekrar, vilket innebär att standardregler för DNS-server och routning tvingar användning av Azure Firewall i den regionala hubben.
En privat DNS-matchningsresurs distribueras med en inkommande slutpunkt i det virtuella ekernätverket.
En privat DNS-zonresurs med namnet privatelink.blob.core.windows.net skapas.
- Den här zonen innehåller en A post som mappar från lagringskontots FQDN-namn till den privata IP-adressen för den privata slutpunkten för lagringskontot.
- Den privata DNS-zonen är länkad till det virtuella ekernätverket.
- Om rollbaserad åtkomstkontroll (RBAC) tillåter kan du använda automatisk registrering eller tjänsthanterade poster för att underhålla dessa DNS-poster. Annars kan du underhålla dem manuellt.
I den regionala hubben ändras Azure Firewalls DNS-server så att den pekar på DNS Private Resolvers inkommande slutpunkt.

Följande diagram illustrerar arkitekturen, tillsammans med både DNS- och HTTP-flöden.

Bild 3: Fungerande lösning för scenario med en enda region för Virtual WAN med Private Link och DNS

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

DNS-flöde för att upprätta ett virtuellt hubbtillägg för DNS

DNS-frågan för stgworkload00.blob.core.windows.net från klienten skickas till den konfigurerade DNS-servern, som är Azure Firewall i den peerkopplade regionala hubben – 10.100.0.132 i det här fallet.

Bild 4: KONFIGURATION AV DNS-servrar för virtuellt arbetsbelastningsnätverk
Azure Firewall skickar begäran till den regionala privata Azure DNS-matcharen i hubbtillägget – 10.200.1.4 i det här fallet, vilket är den privata IP-adressen för DEN PRIVATA DNS-matcharens inkommande slutpunkt.

Skärmbild av Azure Firewall-principen där DNS-proxyn är aktiverad och DNS-servrarna är inställda på Anpassad. Startpunkterna till den privata IP-adressen för DNS Private Resolver-indataslutpunkten.

Bild 5: DNS-konfiguration i Azure Firewall-princip
DNS Private Resolver skickar begäran till Azure DNS. Eftersom en privat DNS-zon är länkad till det virtuella nätverket som innehåller den inkommande slutpunkten kan Azure DNS använda poster i dessa länkade privata DNS-zoner.

Bild 6: Privat DNS länkar till virtuella nätverk i zonen
Azure DNS konsulterar den länkade privata DNS-zonen och löser FQDN stgworkload00.blob.core.windows.net för till 10.1.2.4, vilket är IP-adressen för den privata slutpunkten för lagringskontot. Det här svaret skickas till Azure Firewall DNS, som sedan returnerar lagringskontots privata IP-adress till klienten.

Bild 7: Privat DNS zon med A-posten för lagringskontots privata slutpunkt

HTTP-flöde

Med DNS-resultatet i handen, lagringskontots privata IP-adress, utfärdar klienten en HTTP-begäran till stgworkload00.blob.core.windows.net.
Begäran skickas till lagringskontots privata IP-adress (10.1.2.4). Den här begäran dirigeras korrekt, förutsatt att det inte finns några motstridiga begränsningar för de lokala nätverkssäkerhetsgrupperna i klientundernätet eller undernätet för den privata slutpunkten. Det är viktigt att förstå att även om Azure Firewall skyddar privat trafik dirigeras inte begäran via Azure Firewall eftersom den privata slutpunkten finns i samma virtuella nätverk som klienten. Det innebär att inga Azure Firewall-ersättningar behöver göras för det här scenariot.
En privat anslutning till lagringskontot upprättas via Private Link-tjänsten. Lagringskontot tillåter endast åtkomst till privata nätverk och accepterar HTTP-begäran.

Tillägg för virtuell hubb för DNS-överväganden

När du implementerar tillägget för ditt företag bör du överväga följande vägledning.

Att distribuera DNS-tillägget är inte en uppgift för arbetsbelastningsteamet. Den här uppgiften är en företagsnätverksfunktion och bör vara ett implementeringsbeslut som fattas med dessa personer.
DNS-tillägget och privata DNS-zoner måste finnas innan du lägger till någon PaaS-tjänst som du vill konfigurera dns-poster för för privata slutpunkter.
Tillägget för virtuell hubb är en regional resurs, undvik trafik mellan regioner och upprätta ett hubbtillägg per regional hubb där DNS-matchning för privat slutpunkt förväntas.

Virtuellt ekernätverk

Enligt principen för enskilt ansvar bör det virtuella nätverket för DNS-tillägget endast innehålla de resurser som krävs för DNS-matchning och bör inte delas med andra resurser.
Det virtuella nätverket för DNS-tillägget bör följa samma konfigurationsriktlinjer under Lägga till ekernätverk.

Azure DNS Private Resolver

Varje region bör ha ett DNS-tillägg för virtuell hubb med en privat DNS-matchare.
Dns Private Resolver kräver bara en inkommande slutpunkt och inga utgående slutpunkter för det här scenariot. Den privata IP-adressen för den inkommande slutpunkten är det som anges för den anpassade DNS-tjänsten i Azure Firewall-principen (se bild 5).
För högre återhämtning och ökad belastningshantering kan du distribuera flera PRIVATA DNS-matchningsinstanser per region, med Azure DNS-proxy konfigurerad med flera IP-adresser för proportionell lösning.

Bild 8: Inkommande slutpunkter för den privata DNS-matcharen
Följ begränsningarna för virtuella nätverk för den privata DNS-matcharen.
Nätverkssäkerhetsgruppen i undernätet för DNS Private Resolvers inkommande slutpunkt bör endast tillåta UDP-trafik från dess regionala hubb till port 53. Du bör blockera all annan inkommande och utgående trafik.

Privat DNS-zon

Eftersom Azure DNS Private Resolver löser DNS via Azure DNS kan Azure DNS hämta alla privata DNS-zoner som är länkade till det inkommande undernätets virtuella nätverk.

Länka den privata DNS-zonen till det virtuella hubbtillägget för det virtuella DNS-nätverket.
Följ riktlinjerna för att hantera privata DNS-zoner för privata slutpunkter.
Om du förväntar dig att PaaS-resursägare ska hantera sina egna poster konfigurerar du RBAC i enlighet med detta eller implementerar en lösning som den från Private Link och DNS-integrering i stor skala.

Scenarioöverväganden

Med ett välhanterat DNS-tillägg för virtuell hubb på plats ska vi gå tillbaka till arbetsbelastningen och åtgärda några ytterligare punkter för att uppnå de lyckade utfallsmålen i det här scenariot.

Lagringskonto

Ange åtkomst till offentligt nätverk: Inaktiverad under Nätverksanslutning för att säkerställa att lagringskontot endast kan nås via privata slutpunkter.
Lägg till en privat slutpunkt i ett dedikerat privat slutpunktsundernät i arbetsbelastningens virtuella nätverk.
Skicka Azure Diagnostics till arbetsbelastningens Log Analytics-arbetsyta. Du kan använda åtkomstloggarna för att felsöka konfigurationsproblem.

Säkerhet för privat slutpunkt

Ett krav för den här lösningen är att begränsa exponeringen för det här lagringskontot. När du tar bort offentlig Internetåtkomst till din PaaS-resurs bör du hantera säkerhet för privata nätverk.

När Azure Firewall skyddar privat trafik i en Virtual WAN Hub-spoke-topologi nekar Azure Firewall som standard eker-till-eker-anslutning. Den här standardinställningen hindrar arbetsbelastningar i andra ekernätverk från att komma åt privata slutpunkter (och andra resurser) i det virtuella arbetsbelastningsnätverket. Trafik helt inom ett virtuellt nätverk dirigeras inte via Azure Firewall. Om du vill kontrollera åtkomsten i det virtuella nätverket och lägga till mer detaljerat skydd bör du överväga följande rekommendationer för nätverkssäkerhetsgrupp (NSG).

Skapa en programsäkerhetsgrupp (ASG) för att gruppera resurser som har liknande behov av inkommande eller utgående åtkomst. I det här scenariot använder du en ASG för de virtuella klientdatorer som behöver åtkomst till lagring och en för lagringskonton som används. Se Konfigurera en programsäkerhetsgrupp (ASG) med en privat slutpunkt.
Kontrollera att undernätet som innehåller den virtuella arbetsbelastningsdatorn har en NSG.
Kontrollera att undernätet som innehåller de privata slutpunkterna har en NSG.

NSG-regler för undernät som innehåller en virtuell arbetsbelastningsdator

Förutom andra nätverksregler som din arbetsbelastning kräver konfigurerar du följande regler.

Regler för utgående trafik:
- Tillåt beräknings-ASG att komma åt lagringskontots ASG.
- Tillåt beräknings-ASG till den regionala hubbens privata IP-adress för UDP på port 53.

*Bild 9: NSG-regler för arbetsbelastningsundernät

NSG-regler för undernät som innehåller privata slutpunkter

Det anses vara bästa praxis att exponera privata slutpunkter i ett litet, dedikerat undernät i det förbrukande virtuella nätverket. En orsak är att du kan använda användardefinierade vägar och nätverksprinciper för nätverksgrupper för privata slutpunkter för ökad trafikkontroll och säkerhet.

Det här scenariot gör att en mycket restriktiv nätverkssäkerhetsgrupp kan tillämpas.

Regler för inkommande trafik:
- Tillåt beräknings-ASG att komma åt lagringskontots ASG
- Neka all annan trafik
Regler för utgående trafik:
- Neka all trafik

*Bild 10: NSG-regler för privat slutpunktsundernät

Privat slutpunktssäkerhet i praktiken

Följande bild visar hur du kan ge skydd på djupet genom att följa de överväganden som beskrevs. Diagrammet visar ett andra virtuellt ekernätverk med en andra virtuell dator. Den arbetsbelastningen kan inte komma åt den privata slutpunkten.

Bild 11: Fungerande lösning för scenario med en enda region för Virtual WAN med Private Link och DNS

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

DNS-flöde

DNS-flödet är exakt samma som i lösningsflödet.

Det som är viktigt att markera är att det fullständiga domännamnet matchar den privata IP-adressen och inte den offentliga IP-adressen. Den här lösningen innebär att alla ekrar alltid får den privata IP-adressen för den här tjänsten. Ett annat scenario beskriver hur du kan använda den här metoden för att dela en PaaS-tjänst över flera arbetsbelastningar som förbrukar användning. I det här scenariot med en arbetsbelastning är detta inte ett problem.

HTTP-flöde

Med DNS-resultatet i handen, lagringskontots privata IP-adress, utfärdar klienten en HTTP-begäran till stgworkload00.blob.core.windows.net.
Begäran skickas till lagringskontots privata IP-adress. Den här begäran misslyckas på lämpligt sätt av många orsaker:
- Azure Firewall är konfigurerat för att skydda privat trafik, så den hanterar begäran. Om inte Azure Firewall har en nätverks- eller programregel på plats för att tillåta flödet blockerar Azure Firewall begäran.
- Du behöver inte använda Azure Firewall i hubben för att skydda privat trafik. Om nätverket till exempel stöder privat trafik mellan regioner är nätverkssäkerhetsgruppen i det privata slutpunktsundernätet fortfarande konfigurerad för att blockera all trafik förutom beräknings-ASG-källorna i det virtuella nätverk som är värd för arbetsbelastningen.

Sammanfattning

I den här artikeln beskrivs ett scenario där en virtuell datorklient ansluter till Azure Storage-kontot via lagringskontots privata slutpunkt. Slutpunkten finns i samma virtuella nätverk som klienten. All annan åtkomst till lagringskontot blockeras. Det här scenariot kräver en DNS-post i DNS-flödet som kan matcha det fullständigt kvalificerade domännamnet (FQDN) för lagringskontot tillbaka till den privata IP-adressen för den privata slutpunkten.

Den inledande nätverkstopologin för det här scenariot medför två utmaningar:

Det går inte att länka en privat DNS-zon med nödvändiga DNS-poster för lagringskontot till den virtuella hubben.
Det går inte att länka en privat DNS-zon till arbetsbelastningsundernätet. Den inledande nätverkstopologin kräver att standardregler för DNS-server och routning tvingar användning av Azure Firewall i den regionala hubben.

Den föreslagna lösningen är att företagsnätverksteamet implementerar ett virtuellt hubbtillägg för DNS. Med det här tillägget kan företagsnätverksteamet exponera delade DNS-tjänster för arbetsbelastningsekrar som kräver dem.

Dela via

Scenario med en region – Private Link och DNS i Azure Virtual WAN