Scénář jedné oblasti – Private Link a DNS ve službě Azure Virtual WAN

Azure Private Link

Azure DNS

Azure Firewall

Azure Virtual WAN

Tento článek ukazuje, jak zveřejnit prostředek PaaS přes privátní koncový bod pro konkrétní úlohu v jedné oblasti. Ve scénáři je síťová topologie hvězdicová a centrum je centrem Azure Virtual WAN.

Důležité

Tento článek je součástí série o službě Azure Private Link a Azure DNS ve službě Virtual WAN a vychází ze síťové topologie definované v průvodci scénářem. Nejprve si přečtěte stránku s přehledem, abyste pochopili základní architekturu sítě a klíčové výzvy.

Scénář

Obrázek 1: Scénář jedné oblasti pro Virtual WAN se službou Private Link a Azure DNS – výzva

Stáhněte si soubor Visia této architektury. Tato část definuje scénář a předefinuje výzvu pro tento scénář (výzva je stejná jako nepracovní příklad na stránce přehledu). Architektura počátečního scénáře vychází ze spouštěcí síťové topologie definované v průvodci přehledem. Tady jsou doplňky a změny:

Existuje pouze jedna oblast s jedním virtuálním centrem.
V oblasti je účet Azure Storage, který má zakázaný přístup k veřejné síti. Předpokladem v tomto scénáři je, že k účtu úložiště přistupuje jenom jedna úloha.
Zpočátku je k virtuálnímu centru připojená jedna virtuální síť.
Virtuální síť má podsíť úloh, která obsahuje klienta virtuálního počítače.
Virtuální síť obsahuje podsíť privátního koncového bodu, která obsahuje privátní koncový bod pro účet úložiště.

Úspěšný výsledek

Klient virtuálního počítače Azure se může připojit k účtu Azure Storage prostřednictvím privátního koncového bodu účtu úložiště, který je ve stejné virtuální síti, a veškerý další přístup k účtu úložiště se zablokuje.

Překážka

V toku DNS potřebujete záznam DNS, který dokáže přeložit plně kvalifikovaný název domény (FQDN) účtu úložiště zpět na privátní IP adresu privátního koncového bodu. Jak je uvedeno v přehledu, problém se scénářem je dvojí:

Privátní zónu DNS, která udržuje účty úložiště nezbytné záznamy DNS, není možné propojit s virtuálním centrem.
Privátní zónu DNS můžete propojit se sítí úloh, takže si můžete myslet, že by to fungovalo. Základní architektura bohužel stanoví, že každá propojená virtuální síť má servery DNS nakonfigurované tak, aby odkazovaly na použití proxy serveru DNS služby Azure Firewall.

Protože nemůžete propojit privátní zónu DNS s virtuálním centrem a virtuální síť je nakonfigurovaná tak, aby používala proxy server DNS služby Azure Firewall, servery Azure DNS nemají žádný mechanismus pro překlad (FQDN) účtu úložiště na privátní IP adresu privátního koncového bodu. Výsledkem je, že klient obdrží chybnou odpověď DNS.

Toky DNS a HTTP

Pojďme se podívat na toky požadavků HTTP a DNS pro tuto úlohu. Tato kontrola nám pomůže vizualizovat překážky popsané výše.

Obrázek 2: Scénář jedné oblasti pro Virtual WAN se službou Private Link a Azure DNS – výzva

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok DNS

Dotaz DNS pro stgworkload00.blob.core.windows.net klienta se odešle na nakonfigurovaný server DNS, což je Azure Firewall v partnerském regionálním centru.
Proxy služby Azure Firewall požadavek na Azure DNS. Protože není možné propojit privátní zónu DNS s virtuálním centrem, Azure DNS neví, jak přeložit plně kvalifikovaný název domény na privátní IP adresu privátního koncového bodu. Ví, jak přeložit plně kvalifikovaný název domény na veřejnou IP adresu účtu úložiště, takže vrátí veřejnou IP adresu účtu úložiště.

Tok HTTP

Výsledkem DNS je ručně veřejná IP adresa účtu úložiště, klient vydá požadavek HTTP na stgworkload00.blob.core.windows.net.
Požadavek se odešle na veřejnou IP adresu účtu úložiště. Tento požadavek selže z mnoha důvodů:
- Skupina zabezpečení sítě v podsíti úloh nemusí povolit tento internetový provoz.
- Brána Azure Firewall, která filtruje odchozí provoz směřující na internet, pravděpodobně nemá pravidlo aplikace pro podporu tohoto toku.
- I když skupina zabezpečení sítě i Azure Firewall pro tento tok požadavků měly povolenky, je účet úložiště nakonfigurovaný tak, aby blokoval veškerý přístup k veřejné síti. Tento pokus nakonec porušuje náš cíl povolení přístupu k účtu úložiště pouze prostřednictvím privátního koncového bodu.

Řešení – Vytvoření rozšíření virtuálního centra pro DNS

Řešením této výzvy je, aby tým podnikové sítě implementovali rozšíření virtuálního centra pro DNS. Jedinou odpovědností za rozšíření virtuálního centra DNS je umožnit týmům úloh, které potřebují používat privátní zóny DNS ve své architektuře v rámci této počáteční topologie centra Virtual WAN.

Rozšíření DNS se implementuje jako paprsk virtuální sítě, který je v partnerském vztahu s místním virtuálním centrem. Privátní zóny DNS je možné propojit s touto virtuální sítí. Virtuální síť obsahuje také privátní překladač Azure DNS, který umožňuje službám mimo tuto virtuální síť, jako je Azure Firewall, dotazovat a přijímat hodnoty ze všech propojených privátních zón DNS. Tady jsou komponenty typického rozšíření virtuálního centra pro DNS spolu s některými požadovanými změnami konfigurace:

Nová paprsková virtuální síť, která je v partnerském vztahu s virtuálním centrem oblasti. Tento paprsk je nakonfigurovaný stejně jako jakýkoli jiný paprsk, což znamená, že výchozí server DNS a pravidla směrování vynutí použití služby Azure Firewall v místním centru.
Prostředek privátního překladače DNS se nasadí s příchozím koncovým bodem v paprskové virtuální síti.
Vytvoří se prostředek privatelink.blob.core.windows.net privátní zóny DNS.
- Tato zóna obsahuje A záznam, který se mapuje z názvu plně kvalifikovaného názvu domény účtu úložiště na privátní IP adresu privátního koncového bodu pro účet úložiště.
- Privátní zóna DNS je propojená s paprskovou virtuální sítí.
- Pokud řízení přístupu na základě role (RBAC) umožňuje, můžete k údržbě těchto záznamů DNS použít automatickou registraci nebo položky spravované službou. Pokud ne, můžete je udržovat ručně.
V místním centru se server DNS služby Azure Firewall změní tak, aby ukazoval na příchozí koncový bod služby DNS Private Resolver.

Následující diagram znázorňuje architekturu spolu s toky DNS i HTTP.

Obrázek 3: Pracovní řešení pro scénář jedné oblasti pro Virtual WAN se službou Private Link a DNS

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok DNS pro vytvoření rozšíření virtuálního centra pro DNS

Dotaz DNS pro stgworkload00.blob.core.windows.net klienta se odešle na nakonfigurovaný server DNS, což je Azure Firewall v partnerském regionálním centru – 10.100.0.132 v tomto případě.

Obrázek 4: Konfigurace serverů DNS pro virtuální síť úloh
Proxy služby Azure Firewall v tomto případě požadavek na místní privátní překladač Azure DNS v rozšíření centra – 10.200.1.4, což je privátní IP adresa příchozího koncového bodu služby DNS Private Resolver.

Snímek obrazovky se zásadami služby Azure Firewall, kde je povolený proxy server DNS a servery DNS jsou nastavené na Vlastní Položka odkazuje na privátní IP adresu vstupního koncového bodu DNS Private Resolver.

Obrázek 5: Konfigurace DNS v zásadách služby Azure Firewall
Proxy serveru privátního překladače DNS požadavek na Azure DNS. Vzhledem k tomu, že privátní zóna DNS je propojená s virtuální sítí, která obsahuje příchozí koncový bod, může Azure DNS používat záznamy v těchto propojených privátních zónách DNS.

Obrázek 6: Privátní DNS zónové propojení virtuální sítě
Azure DNS se obrať na propojenou privátní zónu DNS a přeloží plně kvalifikovaný název domény stgworkload00.blob.core.windows.net na 10.1.2.4, což je IP adresa privátního koncového bodu pro účet úložiště. Tato odpověď se poskytne službě Azure Firewall DNS, která klientovi vrátí privátní IP adresu účtu úložiště.

Obrázek 7: Privátní DNS zóny se záznamem A pro privátní koncový bod účtu úložiště

Tok HTTP

Výsledkem DNS je ruční privátní IP adresa účtu úložiště, klient vydá požadavek HTTP na stgworkload00.blob.core.windows.net.
Požadavek se odešle na privátní IP adresu (10.1.2.4) účtu úložiště. Tento požadavek úspěšně směruje za předpokladu, že nedojde ke konfliktu omezení místních skupin zabezpečení sítě v podsíti klienta nebo podsíti privátního koncového bodu. Je důležité si uvědomit, že i když služba Azure Firewall zabezpečuje privátní provoz, požadavek se nepřesměruje přes Azure Firewall, protože privátní koncový bod je ve stejné virtuální síti jako klient. To znamená, že pro tento scénář není nutné provádět žádné povolenky služby Azure Firewall.
Privátní připojení k účtu úložiště je vytvořeno prostřednictvím služby Private Link. Účet úložiště umožňuje pouze přístup k privátní síti a přijímá požadavek HTTP.

Rozšíření virtuálního centra pro důležité informace o DNS

Při implementaci rozšíření pro váš podnik zvažte následující doprovodné materiály.

Nasazení rozšíření DNS není úkolem týmu úloh. Tato úloha je podniková síťová funkce a měla by se jednat o rozhodnutí implementace provedené s těmito jednotlivci.
Před přidáním jakékoli služby PaaS, pro kterou chcete nakonfigurovat záznamy DNS privátního koncového bodu, musí existovat rozšíření DNS a privátní zóny DNS.
Rozšíření virtuálního centra je regionální prostředek, vyhněte se provozu mezi oblastmi a vytvořte rozšíření centra pro každé regionální centrum, kde se očekává překlad DNS privátního koncového bodu.

Paprsková virtuální síť

V souladu s principem jedné odpovědnosti by virtuální síť pro rozšíření DNS měla obsahovat jenom prostředky potřebné k překladu DNS a neměly by se sdílet s jinými prostředky.
Virtuální síť pro rozšíření DNS by měla postupovat podle stejných pokynů konfigurace v části Přidání paprskových sítí.

Azure DNS Private Resolver

Každá oblast by měla mít jedno rozšíření DNS virtuálního centra s jedním privátním překladačem DNS.
Privátní překladač DNS pro tento scénář vyžaduje pouze příchozí koncový bod a žádné odchozí koncové body. Privátní IP adresa pro příchozí koncový bod je to, co je nastavené pro vlastní službu DNS v zásadách služby Azure Firewall (viz obrázek 5).
Pro zajištění vyšší odolnosti a zvýšeného zpracování zatížení můžete nasadit několik instancí privátního překladače DNS na každou oblast s nakonfigurovaným proxy serverem Azure DNS s více IP adresami proxiované rozlišení.

Obrázek 8: Příchozí koncové body pro privátní překladač DNS
Postupujte podle omezení virtuální sítě pro privátní překladač DNS.
Skupina zabezpečení sítě v podsíti pro příchozí koncový bod privátního překladače DNS by měla povolit provoz UDP jenom z místního centra na port 53. Měli byste blokovat všechny ostatní příchozí a odchozí přenosy.

Zóna privátního DNS

Vzhledem k tomu, že privátní překladač Azure DNS překládá DNS prostřednictvím Azure DNS, dokáže Azure DNS vyzvednout všechny privátní zóny DNS propojené s virtuální sítí své příchozí podsítě.

Propojte privátní zónu DNS s rozšířením virtuálního centra pro virtuální síť DNS.
Postupujte podle pokynů ke správě privátních zón DNS pro privátní koncové body.
Pokud očekáváte, že vlastníci prostředků PaaS budou spravovat vlastní položky, nakonfigurujte RBAC odpovídajícím způsobem nebo implementujte řešení, jako je například integrace Private Linku a DNS ve velkém měřítku.

Důležité informace o scénářích

S dobře spravovaným rozšířením DNS virtuálního centra se vraťme zpět k úloze a vyřešme některé další body, které vám pomůžou dosáhnout úspěšných cílů výsledků v tomto scénáři.

Účet úložiště

Nastavení přístupu k veřejné síti: Zakázáno v části Připojení k síti, aby se zajistilo, že k účtu úložiště bude možné přistupovat pouze prostřednictvím privátních koncových bodů.
Přidejte privátní koncový bod do vyhrazené podsítě privátního koncového bodu ve virtuální síti úlohy.
Odešlete Azure Diagnostics do pracovního prostoru služby Log Analytics pro úlohy. K řešení potíží s konfigurací můžete použít protokoly přístupu.

Zabezpečení privátního koncového bodu

Požadavkem tohoto řešení je omezení vystavení tohoto účtu úložiště. Jakmile odeberete přístup k veřejnému internetu k prostředku PaaS, měli byste vyřešit zabezpečení privátních sítí.

Pokud azure Firewall zabezpečuje privátní provoz v hvězdicové topologii služby Virtual WAN, azure Firewall ve výchozím nastavení zakáže připojení paprsku k paprskům. Toto výchozí nastavení brání úlohám v jiných paprskových sítích v přístupu k privátním koncovým bodům (a dalším prostředkům) ve virtuální síti úloh. Provoz plně v rámci virtuální sítě se nesměruje přes Azure Firewall. Pokud chcete řídit přístup v rámci virtuální sítě a přidat podrobnější ochranu, zvažte následující doporučení skupiny zabezpečení sítě (NSG).

Vytvořte skupinu zabezpečení aplikace (ASG) pro seskupení prostředků, které mají podobné požadavky na příchozí nebo odchozí přístup. V tomto scénáři použijte ASG pro klientské virtuální počítače, které potřebují přístup k úložišti, a jednu pro účty úložiště, ke kterým se přistupuje. Viz Konfigurace skupiny zabezpečení aplikace (ASG) s privátním koncovým bodem.
Ujistěte se, že podsíť obsahující virtuální počítač úloh má skupinu zabezpečení sítě.
Ujistěte se, že podsíť obsahující privátní koncové body obsahuje skupinu zabezpečení sítě.

Pravidla NSG pro podsíť obsahující virtuální počítač úloh

Kromě jiných pravidel sítě, která vaše úloha vyžaduje, nakonfigurujte následující pravidla.

Odchozí pravidla:
- Povolte asG výpočetního prostředí pro přístup k účtu úložiště ASG.
- Povolte výpočetní asG privátní IP adrese služby Azure Firewall pro místní centrum pro UDP na portu 53.

*Obrázek 9: Pravidla skupiny zabezpečení sítě pro podsíť úloh

Pravidla NSG pro podsíť obsahující privátní koncové body

Považuje se za osvědčený postup zveřejnění privátních koncových bodů v malé vyhrazené podsíti v rámci spotřebované virtuální sítě. Jedním z důvodů je, že můžete použít trasy definované uživatelem a zásady sítě skupiny zabezpečení sítě pro privátní koncové body pro přidání řízení provozu a zabezpečení.

Tento scénář umožňuje použití vysoce omezující skupiny zabezpečení sítě.

Příchozí pravidla:
- Povolit asG výpočetního prostředí pro přístup k účtu úložiště ASG
- Odepřít veškerý ostatní provoz
Odchozí pravidla:
- Odepřít veškerý provoz

*Obrázek 10: Pravidla NSG pro podsíť privátního koncového bodu

Zabezpečení privátního koncového bodu v akci

Následující obrázek ukazuje, jak můžou následující aspekty, které byly popsány, poskytovat hloubkové zabezpečení ochrany. Diagram znázorňuje druhou paprskovou virtuální síť s druhým virtuálním počítačem. Tato úloha nemá přístup k privátnímu koncovému bodu.

Obrázek 11: Pracovní řešení pro scénář jedné oblasti pro Virtual WAN se službou Private Link a DNS

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok DNS

Tok DNS je úplně stejný jako v toku řešení.

Je důležité zdůraznit, že plně kvalifikovaný název domény se překládá na privátní IP adresu, nikoli na veřejnou IP adresu. Toto řešení znamená, že všechny paprsky vždy obdrží privátní IP adresu této služby. Další scénář popisuje, jak můžete tento přístup použít ke sdílení služby PaaS napříč několika náročnými úlohami. Pro tento scénář s jednou úlohou to není problém.

Tok HTTP

Výsledkem DNS je ruční privátní IP adresa účtu úložiště, klient vydá požadavek HTTP na stgworkload00.blob.core.windows.net.
Požadavek se odešle na privátní IP adresu účtu úložiště. Tento požadavek odpovídajícím způsobem selže z mnoha důvodů:
- Azure Firewall je nakonfigurovaný pro zabezpečení privátního provozu, takže zpracovává požadavek. Pokud služba Azure Firewall nemá pravidlo sítě nebo aplikace, které tok povolí, služba Azure Firewall požadavek zablokuje.
- K zabezpečení privátního provozu nemusíte v centru používat Azure Firewall. Pokud například vaše síť podporuje privátní provoz mezi oblastmi, skupina zabezpečení sítě v podsíti privátního koncového bodu je stále nakonfigurovaná tak, aby blokovala veškerý provoz kromě výpočetních zdrojů ASG ve virtuální síti, která hostuje danou úlohu.

Shrnutí

Tento článek představuje scénář, ve kterém se klient virtuálního počítače připojuje k účtu Azure Storage prostřednictvím privátního koncového bodu účtu úložiště. Koncový bod je ve stejné virtuální síti jako klient. Veškerý další přístup k účtu úložiště je zablokovaný. Tento scénář vyžaduje záznam DNS v toku DNS, který dokáže přeložit plně kvalifikovaný název domény (FQDN) účtu úložiště zpět na privátní IP adresu privátního koncového bodu.

Počáteční síťová topologie pro tento scénář představuje dvě výzvy:

Privátní zónu DNS není možné propojit s požadovanými záznamy DNS pro účet úložiště s virtuálním centrem.
Propojení privátní zóny DNS s podsítí úloh nefunguje. Počáteční síťová topologie vyžaduje, aby výchozí server DNS a pravidla směrování vynutily použití služby Azure Firewall v místním centru.

Navrhované řešení je pro tým podnikové sítě, aby implementovali rozšíření virtuálního centra pro DNS. Toto rozšíření umožňuje podnikovému síťovému týmu zpřístupnit sdílené služby DNS paprskům úloh, které je vyžadují.

Sdílet prostřednictvím

Scénář jedné oblasti – Private Link a DNS ve službě Azure Virtual WAN