Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Azure Private Link je technologie, která umožňuje připojit nabídky Azure Platforma jako služba (PaaS) pomocí připojení privátních IP adres zpřístupněním privátních koncových bodů. Pomocí služby Azure Virtual WAN můžete nasadit privátní koncový bod v jedné z virtuálních sítí připojených k libovolnému virtuálnímu centru. Toto privátní propojení poskytuje připojení k jakékoli jiné virtuální síti nebo větvi připojené ke stejné službě Virtual WAN.
Poznámka:
Ve všech virtuálních sítích připojených k jednomu centru Virtual WAN je maximálně 4 000 privátních koncových bodů. Překročení tohoto limitu může způsobit zhoršení připojení. Privátní koncové body ve velkém měřítku se v současné době nepodporují pro rozbočovače Virtual WAN, takže tento limit se momentálně nedá upravit. Další informace o limitech virtuální sítě privátních koncových bodů najdete v tématu Zvýšení limitů privátních koncových bodů ve virtuálních sítích připojených k prostředkům Azure.
Než začnete
Kroky v tomto článku předpokládají, že jste nasadili virtuální síť WAN s jedním nebo více rozbočovači a aspoň dvěma virtuálními sítěmi připojenými k Virtual WAN.
Pokud chcete vytvořit novou virtuální síť WAN a nové centrum, postupujte podle kroků v následujících článcích:
Úvahy ohledně směrování s Private Link v rámci Virtual WAN
Připojení privátního koncového bodu v Azure je stavové. Když se vytvoří připojení k privátnímu koncovému bodu přes Virtual WAN, provoz se směruje prostřednictvím jednoho nebo více úseků směrování provozu přes různé prvky Virtual WAN (například virtuální směrovač hubu, brána ExpressRoute, brána VPN, Azure Firewall nebo NVA). Přesné síťové skoky závisí na konfiguraci směrování Virtual WAN. Softwarově definovaná síťová vrstva Azure odesílá na pozadí všechny pakety související s jedním 5-tuple tokem do jedné z backendových instancí, které obsluhují různé komponenty Virtual WAN. Asymetricky směrovaný provoz (například provoz odpovídající jednomu 5-tuple toku směrovanému do různých backendových instancí) se nepodporuje a platforma Azure jej zahodí.
Během událostí údržby v infrastruktuře Virtual WAN se instance back-endu restartují po jednom. To může vést k přerušovaným problémům s připojením k soukromému koncovému bodu, protože instance, která obsluhuje tok, je dočasně nedostupná. Podobný problém může nastat při škálování služby Azure Firewall nebo směrovače virtuálního rozbočovače. Stejný provozní tok může být vyrovnán zátěží do nové back-endové instance, která je jiná než ta, která právě obsluhuje tento tok.
Pokud chcete zmírnit dopad údržby a událostí rozšíření kapacity na provoz Private Link nebo privátního koncového bodu, zvažte následující osvědčené postupy:
| Typ provozu | Nejlepší praxe |
|---|---|
| Vše (VPN, ExpressRoute, inter-hub nebo Virtual Network) | Nakonfigurujte hodnotu časového limitu PROTOKOLU TCP pro libovolnou aplikaci (ať už hostované místně nebo v jiné virtuální síti Azure), která přistupuje k privátnímu koncovému bodu služby Private Link nebo privátnímu koncovému bodu, na 15 až 30 sekund. Menší hodnota časového limitu protokolu TCP umožňuje rychlejší zotavení provozu aplikace z událostí údržby a horizontálního navýšení kapacity. Případně otestujte různé hodnoty časového limitu aplikace, abyste zjistili vhodný časový limit na základě vašich požadavků. |
| Vše (VPN, ExpressRoute, inter-hub nebo Virtual Network) | Předem škálované komponenty Virtual WAN pro zpracování nárůstů provozu, aby se zabránilo výskytu událostí automatického škálování. U směrovače virtuálního centra můžete nastavit minimální jednotky infrastruktury směrování přímo na rozbočovači, aby se předešlo škálování během nárůstů provozu. |
| ExpressRoute | Když aktivní tok TCP z místního prostředí připojeného přes ExpressRoute přistupuje ke službě Private Link a brána ExpressRoute je zasažena událostí údržby služby Virtual WAN, podkladová infrastruktura Azure odešle klientské aplikaci, která tento tok iniciovala, paket TCP Reset (RST). Ujistěte se, že klientská aplikace správně zpracovává protokol TCP RST a vytváří novou relaci TCP, aby se zajistilo rychlejší obnovení. |
| ExpressRoute a VPN | Ujistěte se, že je vaše místní zařízení nakonfigurováno tak, aby pro každou pětici odpovídající provozu privátního koncového bodu používalo stejný tunel VPN nebo stejný směrovač Microsoft Enterprise Edge jako další směrovací uzel. |
Vytvoření koncového bodu privátního propojení
Koncový bod privátního propojení můžete vytvořit pro mnoho různých služeb. V tomto příkladu používáme Azure SQL Database. Další informace o tom, jak vytvořit privátní koncový bod pro službu Azure SQL Database, najdete v rychlém startu: Vytvoření privátního koncového bodu pomocí webu Azure Portal. Následující obrázek znázorňuje konfiguraci sítě služby Azure SQL Database:
Po vytvoření databáze Azure SQL můžete ověřit IP adresu privátního koncového bodu kontrolou vašich privátních koncových bodů.
Kliknutím na privátní koncový bod, který jsme vytvořili, by se měla zobrazit jeho privátní IP adresa a plně kvalifikovaný název domény (FQDN). Privátní koncový bod by měl mít IP adresu v rozsahu virtuální sítě (10.1.3.0/24):
Ověřit připojení ze stejné virtuální sítě
V tomto příkladu ověříme připojení ke službě Azure SQL Database z virtuálního počítače s Linuxem pomocí nainstalovaných nástrojů MS SQL. Prvním krokem je ověření, že překlad DNS funguje a plně kvalifikovaný název domény služby Azure SQL Database se přeloží na privátní IP adresu ve stejné virtuální síti, ve které je nasazený privátní koncový bod (10.1.3.0/24):
nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
Jak vidíte v předchozím výstupu, plně kvalifikovaný název domény wantest.database.windows.net je namapován na wantest.privatelink.database.windows.net, přičemž privátní zóna DNS vytvořená spolu s privátním koncovým bodem se překládá na privátní IP adresu 10.1.3.228. Když se podíváte do zóny soukromého DNS, potvrdí se, že existuje záznam A pro soukromý koncový bod namapovaný na soukromou IP adresu.
Po ověření správného překladu DNS se můžeme pokusit připojit k databázi:
query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.3.75
Jak vidíte, používáme speciální dotaz SQL, který nám dává zdrojovou IP adresu, kterou sql server vidí z klienta. V tomto případě server uvidí klienta s privátní IP adresou (10.1.3.75), což znamená, že provoz směřuje z virtuální sítě přímo do privátního koncového bodu.
Nastavte proměnné a username aby odpovídaly password přihlašovacím údajům definovaným ve službě Azure SQL Database, aby příklady v této příručce fungovaly.
Připojení z jiné virtuální sítě
Teď, když má jedna virtuální síť ve službě Azure Virtual WAN připojení k privátnímu koncovému bodu, můžou k ní mít přístup i všechny ostatní virtuální sítě a větve připojené ke službě Virtual WAN. Musíte zajistit připojení prostřednictvím některého z modelů podporovaných službou Azure Virtual WAN, jako například scénáře Any-to-any nebo scénáře sdílených služeb VNet, což jsou dva příklady.
Jakmile máte připojení z virtuální sítě nebo pobočky k virtuální síti, ve které je nasazený privátní koncový bod, musíte nakonfigurovat rozlišení DNS:
- Pokud se připojujete k privátnímu koncovému bodu z virtuální sítě, můžete použít stejnou privátní zónu, kterou jste vytvořili ve službě Azure SQL Database.
- Pokud se připojujete k privátnímu koncovému bodu z větve (VPN typu Site-to-Site, VPN typu Point-to-Site nebo ExpressRoute), musíte použít místní překlad DNS.
V tomto příkladu se připojujeme z jiné virtuální sítě. Nejprve připojte privátní zónu DNS k nové virtuální síti, aby její úlohy mohly přeložit plně kvalifikovaný název domény služby Azure SQL Database na privátní IP adresu. To se provádí propojením privátní zóny DNS s novou virtuální sítí:
Virtuální počítač v připojené virtuální síti by nyní měl správně přeložit FQDN služby Azure SQL Database na privátní IP adresu privátního propojení.
nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
Abyste mohli pečlivě zkontrolovat, jestli má tato virtuální síť (10.1.1.0/24) připojení k původní virtuální síti, ve které byl privátní koncový bod nakonfigurovaný (10.1.3.0/24), můžete ověřit efektivní směrovací tabulku v libovolném virtuálním počítači ve virtuální síti:
Jak vidíte, existuje trasa, která směřuje k VNetu 10.1.3.0/24, vložená virtuálními síťovými branami ve službě Azure Virtual WAN. Teď můžeme konečně otestovat připojení k databázi:
query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.1.75
V tomto příkladu jsme viděli, jak vytvoření privátního koncového bodu v jedné z virtuálních sítí připojených k virtuální síti WAN poskytuje připojení ke zbývajícím virtuálním sítím a větvím ve službě Virtual WAN.
Další kroky
Další informace o službě Virtual WAN najdete v nejčastějších dotazech.