Útmutató a private linkhez és a DNS-hez az Azure Virtual WAN-ban

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

Az Azure Private Link lehetővé teszi az ügyfelek számára, hogy nyilvános IP-címzés nélkül közvetlenül a privát virtuális hálózatokról elérhessék az Azure Platform szolgáltatásként (PaaS) nyújtott szolgáltatásait. Minden szolgáltatáshoz konfiguráljon egy privát végpontot, amely a hálózatról származó privát IP-címet használja. Az ügyfelek ezután a privát végpont használatával privát módon csatlakozhatnak a szolgáltatáshoz.

Az ügyfelek továbbra is a szolgáltatás teljes tartománynevét (FQDN) használják a csatlakozáshoz. Konfigurálja a DNS-t a hálózaton, hogy feloldja a szolgáltatás teljes tartománynevét a privát végpont magánhálózati IP-címére.

A hálózat kialakítása és különösen a DNS-konfiguráció kulcsfontosságú tényezők a szolgáltatásokhoz való privát végpontkapcsolat támogatásában. Ez a cikk egy olyan cikksorozat, amely útmutatást nyújt a különböző Private Link-forgatókönyvek implementálásához. Még ha egyik forgatókönyv sem felel meg pontosan az Ön helyzetének, akkor is képesnek kell lennie az igényeinek megfelelően igazítani a terveket.

Hálózati topológia indítása

A kezdő hálózati topológia egy hálózati architektúra, amely kiindulópontként szolgál a cikksorozat összes forgatókönyvéhez. Az architektúra egy tipikus küllős hálózat, amely az Azure Virtual WAN-t használja.

1. ábra: Hálózati topológia indítása minden privát végponthoz és DNS-forgatókönyvhöz

Töltse le az architektúra Visio-fájlját. Ez a topológia a következő jellemzőkkel rendelkezik:

Ez egy küllős hálózat, amely az Azure Virtual WAN-jal van implementálva.
Két régió van, amelyek mindegyike rendelkezik egy regionális Azure Firewall által védett virtuális központtal.
Minden biztonságos regionális virtuális központ az alábbi biztonsági beállításokkal rendelkezik az Azure-beli virtuális hálózati kapcsolatokhoz:
- Internetes forgalom: Az Azure Firewall védi – Az internet felé irányuló összes forgalom a regionális központi tűzfalon keresztül áramlik.
- Privát forgalom: Az Azure Firewall védi – A küllőről küllőre irányuló összes forgalom a regionális központi tűzfalon halad át.
Minden regionális virtuális központot az Azure Firewall biztosít. A regionális központi tűzfalak a következő beállításokkal rendelkeznek:
- DNS-kiszolgálók: Alapértelmezett (Az Azure biztosított) – A regionális központ tűzfala kifejezetten az Azure DNS-t használja a teljes tartománynév feloldásához a szabálygyűjteményekben.
- DNS-proxy: Engedélyezve – A regionális központ tűzfala válaszol a DNS-lekérdezésekre az 53-as porton. A nem gyorsítótárazott értékek lekérdezéseit továbbítja az Azure DNS-nek.
- A tűzfal naplózza a szabályértékeléseket és a DNS-proxykéréseket egy olyan Log Analytics-munkaterületre, amely ugyanabban a régióban található. Ezeknek az eseményeknek a naplózása gyakori hálózati biztonsági naplózási követelmény.
Minden csatlakoztatott virtuális hálózat küllője rendelkezik az alapértelmezett DNS-kiszolgálóval, amely a regionális központi tűzfal magánhálózati IP-címeként van konfigurálva. Ellenkező esetben az FQDN-szabály kiértékelése nem szinkronizálható.

Többrégiós útválasztás

A biztonságos virtuális WAN-központok korlátozottan támogatják a központközi kapcsolatot, ha több biztonságos virtuális központ is van. Ez a korlátozás a többközpontos, a régión belüli és a régiók közötti forgatókönyveket érinti. Így a hálózati topológia nem segíti közvetlenül a privát, régiók közötti forgalom szűrését az Azure Firewallon keresztül. Ennek a funkciónak a támogatása a Virtual WAN Hub útválasztási szándékával és útválasztási szabályzatokkal történik. Ez a szolgáltatás jelenleg előzetes verzióként érhető el.

Ebben a cikksorozatban a feltételezés az, hogy a belső biztonságos forgalom nem halad át több központon. A több hubon áthaladó forgalomnak olyan párhuzamos topológián kell ezt tennie, amely nem szűri a privát forgalmat egy biztonságos virtuális központon keresztül, hanem lehetővé teszi a továbbítást.

Küllős hálózatok hozzáadása

Küllős hálózatok hozzáadásakor azok a kezdő hálózati topológiában meghatározott korlátozásokat követik. Pontosabban minden küllős hálózat a regionális központban található alapértelmezett útvonaltáblához van társítva, és a tűzfal úgy van konfigurálva, hogy az internetes és a privát forgalmat is biztonságossá tegye. Az alábbi képernyőképen egy konfigurációs példa látható:

2. ábra: A virtuális központ virtuális hálózati kapcsolatainak biztonsági konfigurációja

Főbb kihívások

A kezdő hálózati topológia kihívást jelent a DNS privát végpontokhoz való konfigurálásához.

Bár a Virtual WAN használata felügyelt központot biztosít, a kompromisszum az, hogy a virtuális központ konfigurációját korlátozottan lehet befolyásolni, vagy hogy több összetevőt is hozzáadhat hozzá. A hagyományos küllős topológia lehetővé teszi a küllők számítási feladatainak elkülönítését, miközben közös hálózati szolgáltatásokat, például DNS-rekordokat oszt meg az ön által felügyelt központban. A privát DNS-zónát általában a központi hálózathoz csatolja, hogy az Azure DNS feloldhassa az ügyfelek privát végpontjának IP-címeit.

A privát DNS-zónákat azonban nem lehet virtuális WAN-központokkal összekapcsolni, így a központon belüli DNS-feloldások nem ismerik a privát zónákat. Ez a probléma az Azure Firewall, a számítási feladatok küllőihez konfigurált DNS-szolgáltató esetében jelentkezik, amely a DNS-t használja a teljes tartománynév feloldásához.

A Virtual WAN hubok használatakor intuitívnak tűnik, hogy a privát DNS-zónákat a küllős virtuális hálózatokhoz csatolja, ahol a számítási feladatok DNS-feloldási javaslatokat várnak. Az architektúra szerint azonban a DNS-proxy engedélyezve van a regionális tűzfalakon, és várhatóan minden küllő a regionális tűzfalat használja DNS-forrásként. Az Azure DNS-t nem a számítási feladat hálózatáról, hanem a tűzfalról hívjuk meg, így a számítási feladat hálózatán lévő privát DNS-zónakapcsolatok nem lesznek használva a megoldásban.

Feljegyzés

Ha úgy szeretné konfigurálni a regionális tűzfalat, hogy a küllő dns-szolgáltatója legyen, állítsa a küllős virtuális hálózaton lévő egyéni DNS-kiszolgálót úgy, hogy a tűzfal privát IP-címére mutasson a normál Azure DNS-érték helyett.

Tekintettel a DNS-proxy regionális tűzfalakon való engedélyezésének összetettségére, tekintsük át az engedélyezés okait.

Az Azure Firewall hálózati szabályai támogatják az FQDN-alapú korlátokat, hogy pontosabban szabályozhassák az alkalmazásszabályok által nem kezelt kimenő forgalmat. Ehhez a funkcióhoz engedélyezni kell a DNS-proxyt. Gyakran használják a hálózati idő protokoll (NTP) forgalmát ismert végpontokra, például time.windows.com.
A biztonsági csapatok kihasználhatják a DNS-kérések naplózását. Az Azure Firewall beépített támogatást nyújt a DNS-kérések naplózásához, így az összes küllős erőforrás az Azure Firewall-t használja DNS-szolgáltatóként, így széles körű naplózási lefedettséget biztosít.

A kihívások szemléltetéséhez a következő szakaszok két konfigurációt írnak le. Van egy egyszerű példa, amely működik, és egy összetettebb, amely nem, de a hiba tanulságos.

Munkaforgatókönyv

Az alábbi példa egy alapszintű privát végpontkonfiguráció. A virtuális hálózatok olyan ügyfelet tartalmaznak, amely egy paAS-szolgáltatás magánvégponton történő használatát igényli. A virtuális hálózathoz csatolt privát DNS-zónákban van egy A rekord, amely feloldja a szolgáltatás teljes tartománynevét a privát végpont privát IP-címére. Az alábbi ábra a folyamatot szemlélteti.

3. ábra: A privát végpontok alapszintű DNS-konfigurációja

Töltse le az architektúra Visio-fájlját.

Az ügyfél kérést küld stgworkload00.blob.core.windows.net.
Az Azure DNS, a virtuális hálózat konfigurált DNS-kiszolgálója lekérdezi a stgworkload00.blob.core.windows.net IP-címét.

A virtuális gépről (VM) az alábbi parancs futtatásával szemlélteti, hogy a virtuális gép úgy van konfigurálva, hogy az Azure DNS-t (168.63.129.16) használja DNS-szolgáltatóként.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
A privát DNS-zóna privatelink.blob.core.windows.net a Számítási feladat virtuális hálózatához van társítva, így az Azure DNS a számítási feladat virtuális hálózatának rekordjait tartalmazza a válaszában.
Mivel a privát DNS-zónában létezik egy A rekord, amely leképezi a teljes tartománynevet (stgworkload00.privatelink.blob.core.windows.net) a privát végpont privát IP-címére, a rendszer a 10.1.2.4-es privát IP-címet adja vissza.

A következő parancs virtuális gépről való futtatása feloldja a tárfiók teljes tartománynevét a privát végpont privát IP-címére.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
A kérést a privát végpont privát IP-címére küldik, amely ebben az esetben 10.1.2.4.
A kérés privát kapcsolaton keresztül irányítja a tárfiókhoz.

A tervezés azért működik, mert az Azure DNS:

A virtuális hálózathoz konfigurált DNS-kiszolgáló.
Tisztában van a társított privát DNS-zónával.
A DNS-lekérdezéseket a zóna értékeinek használatával oldja fel.

Nem munkaalapú forgatókönyv

Az alábbi példa egy naiv kísérlet privát végpontok használatára a kezdő hálózati topológiában. Privát DNS-zónát nem lehet virtuális WAN-központhoz kapcsolni. Ezért ha az ügyfelek úgy vannak konfigurálva, hogy DNS-kiszolgálóként használják a tűzfalat, a DNS-kérések a virtuális központon belülről továbbítódnak az Azure DNS-be, amely nem rendelkezik társított privát DNS-zónával. Az Azure DNS nem tudja, hogyan oldhatja meg a lekérdezést, csak az alapértelmezett, azaz a nyilvános IP-cím megadásával.

4. ábra: Magánvégpontok használatának naiv kísérlete a kezdő hálózati topológiában

Töltse le az architektúra Visio-fájlját.

Az ügyfél kérést küld stgworkload00.blob.core.windows.net.

A virtuális gépről az alábbi parancs futtatásával szemlélteti, hogy a virtuális gép úgy van konfigurálva, hogy a virtuális központ tűzfalát használja DNS-szolgáltatóként.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
A tűzfalon engedélyezve van a DNS-proxy, és az alapértelmezett beállítással továbbítja a kéréseket az Azure DNS-nek. A kérés továbbítva lesz az Azure DNS-nek.
Az Azure DNS nem tudja feloldani a stgworkload00.blob.core.windows.net a privát végpont privát IP-címére, mert:
1. A privát DNS-zónák nem kapcsolhatók virtuális WAN-központhoz.
2. Az Azure DNS nem tud a számítási feladat virtuális hálózatához társított privát DNS-zónáról, mert a számítási feladat virtuális hálózatának konfigurált DNS-kiszolgálója az Azure Firewall. Az Azure DNS a tárfiók nyilvános IP-címével válaszol.
A következő parancs virtuális gépről való futtatása feloldja a tárfiók teljes tartománynevét a tárfiók nyilvános IP-címére.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
Mivel az Azure Firewall DNS-lekérdezéseket proxyz, naplózhatjuk őket. Az alábbiakban az Azure Firewall DNS-proxynaplóinak mintái találhatók.
```
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    
```
Az ügyfél nem kapja meg a Private Link-végpont privát IP-címét, és nem tud privát kapcsolatot létesíteni a tárfiókhoz.

A fenti viselkedés várható. Ez a probléma, amelyet a forgatókönyvek kezelnek.

Forgatókönyvek

Bár a probléma megoldásai hasonlóak, a gyakori számítási feladatok forgatókönyveiből megtudhatja, hogy a megoldások hogyan kezelik a különböző helyzetek követelményeit. A legtöbb forgatókönyv olyan ügyfélből áll, amely egy vagy több PaaS-szolgáltatást egy privát végponton keresztül ér el. Betartják a kezdő hálózati topológiát, de eltérnek a számítási feladatokra vonatkozó követelményektől. A forgatókönyvek egyszerűen kezdődnek, egy olyan ügyféllel, amely egyetlen regionális PaaS-szolgáltatást ér el. Egyre összetettebbek lesznek, így nagyobb hálózati láthatóságot, régiókat és PaaS-szolgáltatásokat adhatnak hozzá.

A legtöbb esetben az ügyfél virtuális gépként van implementálva, az ügyfél által elért PaaS-szolgáltatás pedig egy tárfiók. A virtuális gépeket minden olyan Azure-erőforrás stand-injének kell tekintenie, amely egy virtuális hálózaton közzétett hálózati adapterrel rendelkezik, például a virtuálisgép-méretezési csoportokhoz, az Azure Kubernetes Service-csomópontokhoz vagy bármely más, hasonló módon átirányított szolgáltatáshoz.

Fontos

Az Azure Storage-fiók Private Link-implementációja finoman eltérhet a többi PaaS-szolgáltatástól, de sokak számára jól illeszkedik. Egyes szolgáltatások például eltávolítják az FQDN-rekordokat, miközben privát kapcsolaton keresztül teszik közzé őket, ami eltérő viselkedést eredményezhet, de az ilyen különbségek általában nem számítanak az ilyen forgatókönyvek megoldásainak.

Minden forgatókönyv a kívánt végállapottal kezdődik, és részletezi a kezdő hálózati topológiából a kívánt végállapotba való beolvasáshoz szükséges konfigurációt. A megoldás minden forgatókönyvre kihasználja a virtuális központ bővítményeinek mintáját. Ez a minta azt mutatja be, hogyan tehetők elérhetővé a megosztott szolgáltatások elszigetelt és biztonságos módon, egy regionális központ fogalmi kiterjesztéseként. Az alábbi táblázat a virtuális központ bővítménymintájára és a forgatókönyvekre mutató hivatkozásokat tartalmaz.

Útmutató	Leírás
Egyetlen régió, dedikált PaaS	Az egyetlen régióban lévő számítási feladatok egyetlen dedikált PaaS-erőforráshoz férnek hozzá.

Következő lépések

Az egyetlen régió, dedikált PaaS-erőforrásforgatókönyv olvasása

Útmutató a private linkhez és a DNS-hez az Azure Virtual WAN-ban