Průvodce službou Private Link a DNS ve službě Azure Virtual WAN

Azure Private Link umožňuje klientům přistupovat ke službám PaaS (Platforma jako služba) Azure přímo z privátních virtuálních sítí bez použití přidělování veřejných IP adres. Pro každou službu nakonfigurujete privátní koncový bod, který používá privátní IP adresu z vaší sítě. Klienti pak můžou privátní koncový bod použít k privátnímu připojení ke službě.

Klienti nadále používají plně kvalifikovaný název domény (FQDN) služby pro připojení k této službě. Dns ve vaší síti nakonfigurujete tak, aby přeložil plně kvalifikovaný název domény služby na privátní IP adresu privátního koncového bodu.

Návrh sítě a zejména konfigurace DNS jsou klíčovými faktory pro podporu připojení privátního koncového bodu ke službám. Tento článek je jednou z řady článků, které obsahují pokyny k implementaci různých scénářů služby Private Link. I když žádná ze scénářů přesně neodpovídá vaší situaci, měli byste být schopni přizpůsobit návrhy tak, aby vyhovovaly vašim potřebám.

Spuštění síťové topologie

Počáteční síťová topologie je síťová architektura, která slouží jako výchozí bod pro všechny scénáře v této sérii článků. Architektura je typická hvězdicová síť, která používá Azure Virtual WAN.

Obrázek 1: Spuštění síťové topologie pro všechny scénáře privátního koncového bodu a DNS

Stáhněte si soubor Visia této architektury. Tato topologie má následující charakteristiky:

• Jedná se o hvězdicovou síť, která je implementovaná ve službě Azure Virtual WAN.
• Existují dvě oblasti, z nichž každý má místní virtuální centrum zabezpečené službou Azure Firewall.
• Každé zabezpečené regionální virtuální centrum má následující nastavení zabezpečení pro připojení ke službě Azure Virtual Network:
  • Internetový provoz: Zabezpečený službou Azure Firewall – Veškerý provoz do internetu prochází bránou firewall místního centra.
  • Privátní provoz: Zabezpečený službou Azure Firewall – Veškerý provoz, který prochází z paprsku do paprsku, prochází bránou firewall místního centra.
• Každé regionální virtuální centrum je zabezpečené pomocí služby Azure Firewall. Místní brány firewall centra mají následující nastavení:
  • Servery DNS: Výchozí (k dispozici Azure) – Místní brána firewall centra explicitně používá Azure DNS pro překlad plně kvalifikovaného názvu domény v kolekcích pravidel.
  • Proxy SERVER DNS: Povoleno – Brána firewall místního centra reaguje na dotazy DNS na portu 53. Předává dotazy do Azure DNS pro hodnoty bez mezipaměti.
  • Brána firewall protokoluje vyhodnocení pravidel a požadavky proxy serveru DNS do pracovního prostoru služby Log Analytics, který je ve stejné oblasti. Protokolování těchto událostí je běžným požadavkem na protokolování zabezpečení sítě.
• Každý připojený paprsk virtuální sítě má výchozí server DNS nakonfigurovaný tak, aby byl privátní IP adresou brány firewall místního centra. Jinak se vyhodnocení pravidla plně kvalifikovaného názvu domény nedá synchronizovat.

Směrování ve více oblastech

Zabezpečené rozbočovače Virtual WAN mají omezenou podporu pro připojení mezi rozbočovači, pokud existuje více zabezpečených virtuálních center. Toto omezení má vliv na scénáře s více rozbočovači, uvnitř oblastí a mezi oblastmi. Topologie sítě proto přímo neusnadní filtrování privátního provozu mezi oblastmi prostřednictvím služby Azure Firewall. Podpora této funkce je poskytována pomocí záměru směrování centra Virtual WAN a zásad směrování. Tato funkce je v současnosti v ukázkové verzi (Preview).

U této série článků předpokládáme, že interní zabezpečený provoz neprochází více rozbočovači. Provoz, který musí procházet více rozbočovačů, to musí udělat u paralelní topologie, která nefiltruje privátní provoz prostřednictvím zabezpečeného virtuálního centra, ale umožňuje projít místo toho.

Přidání paprskových sítí

Když přidáte paprskové sítě, budou se řídit omezeními definovanými v počáteční síťové topologii. Konkrétně je každá paprsková síť přidružená k výchozí směrovací tabulce, která je v jejím regionálním centru, a brána firewall je nakonfigurovaná tak, aby zabezpečila internetový i privátní provoz. Následující snímek obrazovky ukazuje příklad konfigurace:

Obrázek 2: Konfigurace zabezpečení pro připojení virtuální sítě ve virtuálním centru

Klíčové výzvy

Počáteční síťová topologie vytváří problémy s konfigurací DNS pro privátní koncové body.

I když použití služby Virtual WAN poskytuje prostředí spravovaného centra, je nevýhodou, že existuje omezená schopnost ovlivnit konfiguraci virtuálního centra nebo možnost přidat do něj další komponenty. Tradiční hvězdicová topologie umožňuje izolovat úlohy v paprskech při sdílení běžných síťových služeb, jako jsou záznamy DNS, v místním centru. Privátní zónu DNS obvykle propojujete s centrální sítí, aby azure DNS mohl překládat IP adresy privátního koncového bodu pro klienty.

Privátní zóny DNS ale není možné propojit s rozbočovači Virtual WAN, takže žádné překlady DNS, ke kterým dochází v rámci centra, si nejsou vědomy privátních zón. Konkrétně se jedná o problém pro službu Azure Firewall, nakonfigurovaného poskytovatele DNS pro paprsky úloh, který používá DNS pro překlad plně kvalifikovaného názvu domény.

Když používáte rozbočovače Virtual WAN, zdá se intuitivní, že byste propojili privátní zóny DNS s paprskovou virtuální sítí, kde úlohy očekávají překlad DNS. Jak je však uvedeno v architektuře, proxy server DNS je povolený v místních branách firewall a očekává se, že všechny paprsky jako zdroj DNS používají místní bránu firewall. Azure DNS se volá z brány firewall místo ze sítě úlohy, takže se v překladu nepoužívají všechna propojení privátních zón DNS v síti úloh.

Vzhledem ke složitosti, která má za následek povolení proxy serveru DNS v místních branách firewall, pojďme se podívat na důvody jeho povolení.

• Pravidla sítě služby Azure Firewall podporují omezení založená na plně kvalifikovaném názvu domény, aby bylo možné přesněji řídit odchozí provoz, který pravidla aplikace nezpracují. Tato funkce vyžaduje, aby byl povolený proxy server DNS. Běžným použitím je omezení provozu protokolu NTP (Network Time Protocol) na známé koncové body, například time.windows.com.
• Týmy zabezpečení můžou využívat protokolování požadavků DNS. Azure Firewall má integrovanou podporu protokolování požadavků DNS, takže vyžaduje, aby všechny paprskové prostředky jako jejich poskytovatel DNS používaly Azure Firewall.

Pro ilustraci problémů popisují následující části dvě konfigurace. Existuje jednoduchý příklad, který funguje, a složitější, který není, ale jeho selhání je poučné.

Pracovní scénář

Následující příklad je základní konfigurace privátního koncového bodu. Virtuální síť obsahuje klienta, který vyžaduje použití služby PAAS prostřednictvím privátního koncového bodu. Privátní zóna DNS propojená s virtuální sítí má záznam A, který přeloží plně kvalifikovaný název domény služby na privátní IP adresu privátního koncového bodu. Následující diagram znázorňuje tok.

Obrázek 3: Základní konfigurace DNS pro privátní koncové body

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

1. Klient vydá žádost o stgworkload00.blob.core.windows.net.

2. Azure DNS, nakonfigurovaný server DNS pro virtuální síť, se dotazuje na IP adresu pro stgworkload00.blob.core.windows.net.

   Spuštěním následujícího příkazu z virtuálního počítače je vidět, že je virtuální počítač nakonfigurovaný tak, aby jako poskytovatele DNS používal Azure DNS (168.63.129.16).

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

3. Privátní zóna privatelink.blob.core.windows.net DNS je propojená s virtuální sítí úloh, takže Azure DNS do odpovědi zahrnuje záznamy z virtuální sítě úloh.

4. Protože záznam A existuje v privátní zóně DNS, která mapuje plně kvalifikovaný název domény, stgworkload00.privatelink.blob.core.windows.netvrátí se privátní IP adresa privátního koncového bodu na privátní IP adresu 10.1.2.4.

   Spuštěním následujícího příkazu z virtuálního počítače se přeloží plně kvalifikovaný název domény účtu úložiště na privátní IP adresu privátního koncového bodu.

   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. Požadavek se vydá na privátní IP adresu privátního koncového bodu, který je v tomto případě 10.1.2.4.

6. Požadavek se směruje přes Private Link do účtu úložiště.

Návrh funguje, protože Azure DNS:

• Je nakonfigurovaný server DNS pro virtuální síť.
• Je si vědom propojené privátní zóny DNS.
• Překládá dotazy DNS pomocí hodnot zóny.

Nepracovní scénář

Následující příklad je naivní pokus o použití privátních koncových bodů v počáteční síťové topologii. Privátní zónu DNS není možné propojit s centrem Virtual WAN. Proto když jsou klienti nakonfigurovaní tak, aby jako svůj server DNS používali bránu firewall, požadavky DNS se předávají do Azure DNS z virtuálního centra, který nemá propojenou privátní zónu DNS. Azure DNS neví, jak přeložit jiný dotaz než zadáním výchozí ip adresy, což je veřejná IP adresa.

Obrázek 4: Naïve pokus o použití privátních koncových bodů v počáteční síťové topologii

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

1. Klient vydá žádost o stgworkload00.blob.core.windows.net.

   Spuštěním následujícího příkazu z virtuálního počítače je vidět, že je virtuální počítač nakonfigurovaný tak, aby jako zprostředkovatel DNS používal bránu firewall virtuálního centra.

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

2. Brána firewall má povolený proxy server DNS s výchozím nastavením pro předávání požadavků do Azure DNS. Požadavek se přepošla do Azure DNS.

3. Azure DNS nemůže přeložit stgworkload00.blob.core.windows.net na privátní IP adresu privátního koncového bodu, protože:

   1. Privátní zónu DNS nejde propojit s centrem Virtual WAN.
   2. Azure DNS neví o privátní zóně DNS, která je propojená s virtuální sítí úloh, protože nakonfigurovaný server DNS pro virtuální síť úlohy je Azure Firewall. Azure DNS odpoví veřejnou IP adresou účtu úložiště.

   Spuštěním následujícího příkazu z virtuálního počítače se přeloží plně kvalifikovaný název domény účtu úložiště na veřejnou IP adresu účtu úložiště.

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

   Vzhledem k tomu, že Azure Firewall proxy provádí dotazy DNS, můžeme je protokolovat. Níže jsou uvedené ukázkové protokoly proxy serveru DNS služby 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. Klient neobdrží privátní IP adresu koncového bodu služby Private Link a nemůže navázat privátní připojení k účtu úložiště.

Výše uvedené chování se očekává. Jedná se o problém, který řeší scénáře.

Scénáře

I když jsou řešení tohoto problému podobná, projděte si běžné scénáře úloh, jak řešení řeší požadavky různých situací. Většina scénářů se skládá z klienta, který přistupuje k jedné nebo více službám PaaS přes privátní koncový bod. Dodržují počáteční topologii sítě, ale liší se v požadavcích na úlohy. Scénáře začínají jednoduše pomocí klienta, který přistupuje k jedné regionální službě PaaS. Získají přírůstkově složitější služby a přidávají lepší viditelnost sítě, oblasti a služby PaaS.

Ve většině scénářů se klient implementuje jako virtuální počítač a služba PaaS, ke které klient přistupuje, je účet úložiště. Virtuální počítače byste měli zvážit jako samostatný prostředek Azure, který má síťovou kartu, která je vystavená ve virtuální síti, jako jsou škálovací sady virtuálních počítačů, uzly Azure Kubernetes Service nebo jakákoli jiná služba, která se směruje podobným způsobem.

Každý scénář začíná požadovaným koncovým stavem a podrobně popisuje konfiguraci, která se vyžaduje k získání od počáteční síťové topologie do požadovaného koncového stavu. Řešení pro každý scénář využívá model rozšíření virtuálních center. Tento model řeší, jak zveřejnit sdílené služby izolovaným a bezpečným způsobem, jako koncepční rozšíření pro regionální centrum. Následující tabulka obsahuje odkazy na vzor rozšíření virtuálního centra a scénáře.

Další kroky

Související prostředky

• Co je privátní koncový bod?
• Konfigurace DNS privátního koncového bodu v Azure
• Integrace služby Private Link a DNS ve velkém měřítku
• Azure Private Link v hvězdicové síti
• DNS pro místní prostředky a prostředky Azure
• Připojení cílové zóny dat v jedné oblasti
• Použití Azure Private Linku k propojení sítí k Azure Monitoru
• Azure DNS Private Resolver
• Vylepšený přístup k víceklientských webovým aplikacím z místní sítě
• Standardní vysoce dostupná zónově redundantní webová aplikace
• Kurz: Vytvoření infrastruktury DNS privátního koncového bodu pomocí služby Azure Private Resolver pro místní úlohu