Sdílet prostřednictvím

Diagnostika potíží s konfigurací služeb Private Link ve službě Azure Key Vault

  • Článek

Úvod

Tento článek pomáhá uživatelům diagnostikovat a opravit problémy související se službou Key Vault a funkcí privátních propojení. Tato příručka vám pomůže s aspekty konfigurace, jako je první získání privátních propojení nebo oprava situace, kdy privátní propojení přestala fungovat kvůli určité změně.

Pokud s touto funkcí začínáte, přečtěte si téma Integrace služby Key Vault se službou Azure Private Link.

Problémy, na které se vztahuje tento článek

  • Vaše dotazy DNS stále vrací veřejnou IP adresu trezoru klíčů místo privátní IP adresy, kterou byste očekávali od použití funkce privátních propojení.
  • Všechny požadavky provedené daným klientem, který používá privátní propojení, selhávají s časovými limity nebo chybami sítě a problém není přerušovaný.
  • Trezor klíčů má privátní IP adresu, ale požadavky stále získávají 403 odpověď s vnitřním kódem ForbiddenByFirewall chyby.
  • Používáte privátní propojení, ale váš trezor klíčů stále přijímá žádosti z veřejného internetu.
  • Váš trezor klíčů má dva privátní koncové body. Požadavky, které používají jeden z nich, fungují správně, ale požadavky, které používají druhou, selhávají.
  • Máte jiné předplatné, trezor klíčů nebo virtuální síť, která používá privátní propojení. Chcete vytvořit nové podobné nasazení, ale nemůžete získat privátní propojení, která by tam fungovala.

Problémy, na které se nevztahuje tento článek

  • Dochází k občasnému problému s připojením. V daném klientovi uvidíte, že některé požadavky fungují a některé nefungují. Občasné problémy obvykle nejsou způsobeny problémem v konfiguraci privátních propojení; jsou znamením přetížení sítě nebo klienta.
  • Používáte produkt Azure, který podporuje BYOK (Bring Your Own Key), CMK (klíče spravované zákazníkem) nebo přístup k tajným kódům uloženým v trezoru klíčů. Když povolíte bránu firewall v nastavení trezoru klíčů, nemůže tento produkt získat přístup k trezoru klíčů. Projděte si dokumentaci specifickou pro produkt. Ujistěte se, že explicitně uvádí podporu trezorů klíčů s povolenou bránou firewall. V případě potřeby se obraťte na podporu konkrétního produktu.

Jak si přečíst tento článek

Pokud s privátními propojeními začínáte nebo vyhodnocujete komplexní nasazení, doporučujeme přečíst si celý článek. V opačném případě zvolte oddíl, který dává větší smysl pro váš problém.

Pusťme se do toho.

1. Potvrďte, že vlastníte připojení klienta.

Ověřte, že se klient spouští ve virtuální síti.

Tato příručka vám pomůže opravit připojení k trezoru klíčů, která pocházejí z kódu aplikace. Příklady jsou aplikace a skripty, které se spouštějí ve službě Azure Virtual Machines, clusterech Azure Service Fabric, Aplikace Azure Service, Azure Kubernetes Service (AKS) a podobně. Tato příručka se vztahuje také na přístupy prováděné ve webovém uživatelském rozhraní webu Azure Portal, kde prohlížeč přistupuje k vašemu trezoru klíčů přímo.

V definici privátních propojení musí aplikace, skript nebo portál běžet na počítači, clusteru nebo prostředí připojeném k virtuální síti, ve které byl prostředek privátního koncového bodu nasazen.

Pokud aplikace, skript nebo portál běží v libovolné síti připojené k internetu, tato příručka není použitelná a pravděpodobně nelze použít privátní propojení. Toto omezení platí také pro příkazy spouštěné v Azure Cloud Shellu, protože běží na vzdáleném počítači Azure poskytovaném na vyžádání místo prohlížeče uživatele.

Pokud používáte spravované řešení, projděte si konkrétní dokumentaci.

Tato příručka se nevztahuje na řešení spravovaná Microsoftem, kde k trezoru klíčů přistupuje produkt Azure, který existuje nezávisle na virtuální síti zákazníka. Příklady takových scénářů jsou Azure Storage nebo Azure SQL nakonfigurované pro šifrování neaktivních uložených dat, Azure Event Hubs šifruje data pomocí klíčů poskytnutých zákazníkem, Azure Data Factory pro přístup k přihlašovacím údajům služby uložené v trezoru klíčů, Azure Pipelines načítající tajné kódy z trezoru klíčů a další podobné scénáře. V těchto případech musíte zkontrolovat, jestli produkt podporuje trezory klíčů s povolenou bránou firewall. Tato podpora se obvykle provádí s funkcí Důvěryhodné služby brány firewall služby Key Vault. Mnoho produktů však není součástí seznamu důvěryhodných služeb z různých důvodů. V takovém případě se dostanete na podporu specifickou pro jednotlivé produkty.

Několik produktů Azure podporuje koncept injektáže virtuální sítě. Jednoduše řečeno, produkt přidá síťové zařízení do virtuální sítě zákazníka, což mu umožní odesílat požadavky, jako by byl nasazen do virtuální sítě. Příkladem je Azure Databricks. Takové produkty můžou vyhovět trezoru klíčů pomocí privátních propojení a tento průvodce odstraňováním potíží vám může pomoct.

2. Ověřte, že je připojení schváleno a úspěšné.

Následující kroky ověřují, že připojení privátního koncového bodu je schválené a úspěšné:

  1. Otevřete Azure Portal a otevřete prostředek trezoru klíčů.
  2. V levé nabídce vyberte Sítě.
  3. Vyberte kartu Připojení privátních koncových bodů. Zobrazí se všechna privátních koncových bodů a jejich stavy. Pokud neexistují žádná připojení nebo pokud chybí připojení pro vaši virtuální síť, musíte vytvořit nový privátní koncový bod. Tomu se budeme věnovat později.
  4. Stále v připojeních privátních koncových bodů najděte ten, který diagnostikujete, a ověřte, že stav připojení je schválený a stav zřizování byl úspěšný.
    • Pokud je připojení ve stavu Čeká na vyřízení, možná ho budete moct jenom schválit.
    • Pokud se připojení "Odmítnuto", "Selhání", "Chyba", "Odpojeno" nebo jiný stav, není vůbec efektivní, musíte vytvořit nový prostředek privátního koncového bodu.

Je vhodné odstranit neefektivní připojení, aby byly věci čisté.

3. Ověřte, že je správně nakonfigurovaná brána firewall trezoru klíčů.

Důležité

Změna nastavení brány firewall může odebrat přístup z legitimních klientů, kteří stále nepoužívají privátní propojení. Ujistěte se, že znáte důsledky každé změny v konfiguraci brány firewall.

Důležitým pojmem je, že funkce privátních propojení poskytuje přístup pouze k vašemu trezoru klíčů ve virtuální síti, která je uzavřená, aby se zabránilo exfiltraci dat. Neodebere žádný existující přístup. Pokud chcete efektivně blokovat přístupy z veřejného internetu, musíte bránu firewall trezoru klíčů explicitně povolit:

  1. Otevřete Azure Portal a otevřete prostředek trezoru klíčů.
  2. V levé nabídce vyberte Sítě.
  3. Ujistěte se, že je nahoře vybraná karta Brány firewall a virtuální sítě .
  4. Pokud zjistíte, že možnost Povolit veřejný přístup ze všech vybraných sítí , vysvětluje, proč mají externí klienti stále přístup k trezoru klíčů. Pokud chcete, aby služba Key Vault byla přístupná jenom přes Private Link, vyberte Zakázat veřejný přístup.

Následující příkazy platí také pro nastavení brány firewall:

  • Funkce privátních propojení nevyžaduje zadání žádné virtuální sítě v nastavení brány firewall trezoru klíčů. Všechny požadavky používající privátní IP adresu trezoru klíčů (viz další část) musí fungovat, i když v nastavení brány firewall trezoru klíčů není zadaná žádná virtuální síť.
  • Funkce privátních propojení nevyžaduje zadání žádné IP adresy v nastavení brány firewall trezoru klíčů. Všechny požadavky používající privátní IP adresu trezoru klíčů musí znovu fungovat, i když v nastavení brány firewall nebyla zadána žádná IP adresa.

Pokud používáte privátní propojení, jedinou motivací k určení virtuální sítě nebo IP adresy v bráně firewall trezoru klíčů jsou:

  • Máte hybridní systém, kde někteří klienti používají privátní propojení, některé používají koncové body služby, některé používají veřejnou IP adresu.
  • Přecházíte na privátní propojení. Když v takovém případě potvrdíte, že všichni klienti používají privátní propojení, měli byste z nastavení brány firewall trezoru klíčů odebrat virtuální sítě a IP adresy.

4. Ujistěte se, že trezor klíčů má privátní IP adresu.

Rozdíl mezi privátními a veřejnými IP adresami

Privátní IP adresa má vždy jeden z následujících formátů:

  • 10.x.x.x: Příklady: 10.1.2.3, 10.56.34.12.
  • 172.16.x.x až 172.32.x.x: Příklady: 172.20.1.1, 172.31.67.89.
  • 192.168.x.x: Příklady: 192.168.0.1, 192.168.100.7

Některé IP adresy a rozsahy jsou rezervované:

  • 224.x.x.x: Vícesměrové vysílání
  • 255.255.255.255: Vysílání
  • 127.x.x.x: Zpětná smyčka
  • 169.254.x.x: Link-local
  • 168.63.129.16: Interní DNS

Všechny ostatní IP adresy jsou veřejné.

Při procházení portálu nebo spuštění příkazu, který zobrazuje IP adresu, se ujistěte, že je tato IP adresa soukromá, veřejná nebo rezervovaná. Aby privátní propojení fungovala, musí se název hostitele trezoru klíčů přeložit na privátní IP adresu patřící do adresního prostoru virtuální sítě.

Vyhledání privátní IP adresy trezoru klíčů ve virtuální síti

Budete muset diagnostikovat překlad názvů hostitelů a pro to musíte znát přesnou privátní IP adresu vašeho trezoru klíčů s povolenými privátními propojeními. Chcete-li tuto adresu najít, postupujte takto:

  1. Otevřete Azure Portal a otevřete prostředek trezoru klíčů.
  2. V levé nabídce vyberte Sítě.
  3. Vyberte kartu Připojení privátních koncových bodů. Zobrazí se všechna privátních koncových bodů a jejich stavy.
  4. Najděte ten, který diagnostikujete, a ověřte, že stav připojení je schválený a stav zřizování byl úspěšný. Pokud tuto možnost nevidíte, vraťte se k předchozím oddílům tohoto dokumentu.
  5. Po nalezení správné položky klikněte na odkaz ve sloupci Privátní koncový bod. Tím se otevře prostředek privátního koncového bodu.
  6. Na stránce Přehled se může zobrazit oddíl s názvem Vlastní nastavení DNS. Ověřte, že je zde jenom jedna položka, která odpovídá názvu hostitele trezoru klíčů. Tato položka zobrazuje privátní IP adresu trezoru klíčů.
  7. Můžete také kliknout na odkaz v síťovém rozhraní a potvrdit, že privátní IP adresa je stejná jako v předchozím kroku. Síťové rozhraní je virtuální zařízení, které reprezentuje trezor klíčů.

IP adresa je ip adresa, kterou budou virtuální počítače a další zařízení spuštěná ve stejné virtuální síti používat pro připojení k trezoru klíčů. Poznamenejte si IP adresu nebo nechte kartu prohlížeče otevřenou a při dalším šetření se na ni nedotýkejte.

Poznámka:

Pokud má váš trezor klíčů více privátních koncových bodů, pak má několik privátních IP adres. To je užitečné jenom v případě, že máte více virtuálních sítí, které přistupují ke stejnému trezoru klíčů, každý prostřednictvím vlastního privátního koncového bodu (privátní koncový bod patří do jedné virtuální sítě). Ujistěte se, že jste problém diagnostikovali pro správnou virtuální síť, a v předchozím postupu vyberte správné připojení privátního koncového bodu. Kromě toho nevytvořujte více privátních koncových bodů pro stejný trezor klíčů ve stejné virtuální síti. Není to nutné a je to zdrojem nejasností.

5. Ověření překladu DNS

Překlad DNS je proces překladu názvu hostitele trezoru klíčů (příklad: fabrikam.vault.azure.net) na IP adresu (příklad: 10.1.2.3). Následující pododdíly zobrazují očekávané výsledky překladu DNS v jednotlivých scénářích.

Tato část je určená pro účely výuky. Pokud trezor klíčů nemá ve schváleném stavu žádné připojení privátního koncového bodu, vrátí překlad názvu hostitele výsledek podobný tomuto:

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  52.168.109.101
Aliases:  fabrikam.vault.azure.net
          data-prod-eus.vaultcore.azure.net
          data-prod-eus-region.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for data-prod-eus.vaultcore.azure.net.
data-prod-eus.vaultcore.azure.net is an alias for data-prod-eus-region.vaultcore.azure.net.
data-prod-eus-region.vaultcore.azure.net has address 52.168.109.101

Uvidíte, že se název překládá na veřejnou IP adresu a že neexistuje žádný privatelink alias. Alias je vysvětlen později, nedělejte si o něj starosti.

Výše uvedený výsledek se očekává bez ohledu na počítač připojený k virtuální síti nebo libovolný počítač s připojením k internetu. K tomu dochází, protože trezor klíčů nemá ve schváleném stavu žádné připojení privátního koncového bodu, a proto není nutné, aby trezor klíčů podporoval privátní propojení.

Pokud má trezor klíčů jedno nebo více připojení privátních koncových bodů ve schváleném stavu a přeložíte název hostitele z libovolného počítače připojeného k internetu (počítač, který není připojený k virtuální síti, ve které se nachází privátní koncový bod), zjistíte toto:

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  52.168.109.101
Aliases:  fabrikam.vault.azure.net
          fabrikam.privatelink.vaultcore.azure.net
          data-prod-eus.vaultcore.azure.net
          data-prod-eus-region.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net is an alias for data-prod-eus.vaultcore.azure.net.
data-prod-eus.vaultcore.azure.net is an alias for data-prod-eus-region.vaultcore.azure.net.
data-prod-eus-region.vaultcore.azure.net has address 52.168.109.101

Rozdíl od předchozího scénáře spočívá v tom, že existuje nový alias s hodnotou {vaultname}.privatelink.vaultcore.azure.net. To znamená, že rovina dat trezoru klíčů je připravená přijímat žádosti z privátních propojení.

Neznamená to, že požadavky prováděné z počítačů mimo virtuální síť (jako je ten, který jste právě použili), budou používat privátní propojení – nebudou. Vidíte, že ze skutečnosti, že se název hostitele stále překládá na veřejnou IP adresu. Privátní propojení můžou používat jenom počítače připojené k virtuální síti . Další informace o tom budou následovat.

Pokud alias nevidíte privatelink , znamená to, že trezor klíčů má ve stavu nula připojení Approved privátních koncových bodů. Před opakováním se vraťte do této části .

Pokud má trezor klíčů jedno nebo více připojení privátního koncového bodu ve schváleném stavu a přeložíte název hostitele z počítače připojeného k virtuální síti, kde se vytvořil privátní koncový bod, jedná se o očekávanou odpověď:

Windows:

C:\> nslookup fabrikam.vault.azure.net

Non-authoritative answer:
Address:  10.1.2.3
Aliases:  fabrikam.vault.azure.net
          fabrikam.privatelink.vaultcore.azure.net

Linux:

joe@MyUbuntu:~$ host fabrikam.vault.azure.net

fabrikam.vault.azure.net is an alias for fabrikam.privatelink.vaultcore.azure.net.
fabrikam.privatelink.vaultcore.azure.net has address 10.1.2.3

Existují dva velmi odlišné rozdíly. Nejprve se název přeloží na privátní IP adresu. To musí být IP adresa, kterou jsme našli v odpovídající části tohoto článku. Za druhé, po privatelink tom nejsou žádné další aliasy. K tomu dochází, protože servery DNS virtuální sítě zachycuje řetěz aliasů a vrací privátní IP adresu přímo z názvu fabrikam.privatelink.vaultcore.azure.net. Tato položka je ve skutečnosti A záznamem v zóně Privátní DNS. Další informace o tom budou následovat.

Poznámka:

Výše uvedený výsledek se provede pouze na virtuálním počítači připojeném k virtuální síti, ve které byl vytvořen privátní koncový bod. Pokud ve virtuální síti nemáte nasazený virtuální počítač, který obsahuje privátní koncový bod, nasaďte ho a připojte se k němu vzdáleně, spusťte nslookup příkaz (Windows) nebo host příkaz (Linux) výše.

Pokud tyto příkazy spustíte na virtuálním počítači připojeném k virtuální síti, ve které byl vytvořen privátní koncový bod, a nezobrazují privátní IP adresu trezoru klíčů, může vám s vyřešením problému pomoct další část.

6. Ověření zóny Privátní DNS

Pokud překlad DNS nefunguje, jak je popsáno v předchozí části, může dojít k problému s vaší zónou Privátní DNS a tato část vám může pomoct. Pokud překlad DNS zobrazuje správnou privátní IP adresu trezoru klíčů, je vaše Privátní DNS zóna pravděpodobně správná. Celý tento oddíl můžete přeskočit.

Ověřte, že požadovaný prostředek zóny Privátní DNS existuje.

Vaše předplatné Azure musí mít prostředek zóny Privátní DNS s tímto přesným názvem:

privatelink.vaultcore.azure.net

Stav tohoto prostředku můžete zkontrolovat tak, že přejdete na stránku předplatného na portálu a v nabídce vlevo vyberete Prostředky. Název prostředku musí být privatelink.vaultcore.azure.neta typ prostředku musí být Privátní DNS zóně.

Tento prostředek se obvykle vytvoří automaticky při vytváření privátního koncového bodu pomocí běžného postupu. Existují ale případy, kdy se tento prostředek nevytvořil automaticky a musíte ho provést ručně. Tento prostředek byl pravděpodobně také omylem odstraněn.

Pokud tento prostředek nemáte, vytvořte ve svém předplatném nový prostředek zóny Privátní DNS. Nezapomeňte, že název musí být přesně privatelink.vaultcore.azure.netbez mezer nebo dalších tečk. Pokud zadáte nesprávný název, překlad názvů vysvětlený v tomto článku nebude fungovat. Další informace o tom, jak tento prostředek vytvořit, najdete v tématu Vytvoření privátní zóny DNS Azure pomocí webu Azure Portal. Pokud se na této stránce podíváte, můžete přeskočit vytváření virtuální sítě, protože v tomto okamžiku byste ji už měli mít. Ověřovací postupy můžete také přeskočit pomocí služby Virtual Machines.

Ověřte, že je zóna Privátní DNS propojená s virtuální sítí.

Nestačí mít Privátní DNS zónu. Musí být také propojen s virtuální sítí, která obsahuje privátní koncový bod. Pokud není zóna Privátní DNS propojená se správnou virtuální sítí, bude jakýkoli překlad DNS z této virtuální sítě ignorovat zónu Privátní DNS.

Otevřete prostředek Privátní DNS Zóna a v nabídce vlevo klikněte na možnost Propojení virtuální sítě. Zobrazí se seznam odkazů s názvem virtuální sítě ve vašem předplatném. Virtuální síť, která obsahuje prostředek privátního koncového bodu, musí být uvedena tady. Pokud tam není, přidejte ji. Podrobný postup najdete v tématu Propojení virtuální sítě. Možnost Povolit automatickou registraci můžete nechat nezaškrtnutou – tato funkce nesouvisí s privátními propojeními.

Jakmile je zóna Privátní DNS propojená s virtuální sítí, budou požadavky DNS pocházející z virtuální sítě hledat názvy v zóně Privátní DNS. To se vyžaduje pro správné řešení adres prováděné na virtuálních počítačích připojených k virtuální síti, ve které byl vytvořen privátní koncový bod.

Poznámka:

Pokud jste odkaz právě uložili, může to nějakou dobu trvat, než se to projeví, i když portál oznámí, že je operace dokončená. Možná budete také muset restartovat virtuální počítač, který používáte k otestování překladu DNS.

Ověřte, že zóna Privátní DNS obsahuje správný záznam A.

Pomocí portálu otevřete zónu Privátní DNS s názvem privatelink.vaultcore.azure.net. Na stránce Přehled se zobrazují všechny záznamy. Ve výchozím nastavení bude existovat jeden záznam s názvem @ a typem SOA, což znamená Začátek autority. Nedotýkejte se toho.

Aby překlad názvů trezoru klíčů fungoval, musí existovat A záznam s jednoduchým názvem trezoru bez přípony nebo tečky. Pokud je fabrikam.vault.azure.netnapříklad název hostitele , musí existovat A záznam s názvem fabrikambez přípony nebo tečky.

Hodnota záznamu A (IP adresa) musí být také privátní IP adresa trezoru klíčů. Pokud najdete A záznam, ale obsahuje nesprávnou IP adresu, musíte odebrat nesprávnou IP adresu a přidat novou. Doporučujeme odebrat celý A záznam a přidat nový.

Poznámka:

Kdykoli odeberete nebo upravíte A záznam, počítač se může stále překládat na starou IP adresu, protože hodnota TTL (Time To Live) ještě nemusí vypršená. Doporučujeme vždy zadat hodnotu TTL ne menší než 10 sekund a ne větší než 600 sekund (10 minut). Pokud zadáte hodnotu, která je příliš velká, může trvat příliš dlouho, než se klienti obnoví z výpadků.

Překlad DNS pro více než jednu virtuální síť

Pokud existuje více virtuálních sítí a každý má vlastní prostředek privátního koncového bodu odkazující na stejný trezor klíčů, musí se název hostitele trezoru klíčů přeložit na jinou privátní IP adresu v závislosti na síti. To znamená, že je potřeba také více Privátní DNS zón, z nichž každý je propojený s jinou virtuální sítí a používá jinou IP adresu v záznamuA.

V pokročilejších scénářích můžou mít virtuální sítě povolené partnerské vztahy. V tomto případě potřebuje pouze jednu virtuální síť prostředek privátního koncového bodu, i když oba můžou být potřeba propojit s prostředkem Privátní DNS Zóna. Tento scénář přímo nepokrývá tento dokument.

Zjistěte, že máte kontrolu nad překladem DNS.

Jak je vysvětleno v předchozí části, trezor klíčů s privátními odkazy má alias {vaultname}.privatelink.vaultcore.azure.net ve své veřejné registraci. Server DNS používaný virtuální sítí používá veřejnou registraci, ale kontroluje všechny aliasy pro privátní registraci a pokud se najde, zastaví se následující aliasy definované při veřejné registraci.

Tato logika znamená, že pokud je virtuální síť propojená s Privátní DNS zónou s názvem privatelink.vaultcore.azure.neta veřejná registrace DNS pro trezor klíčů má alias fabrikam.privatelink.vaultcore.azure.net (všimněte si, že přípona názvu hostitele trezoru klíčů odpovídá názvu Privátní DNS zóny přesně), pak dotaz DNS vyhledá A záznam s názvem fabrikam v zóně Privátní DNS. A Pokud se záznam najde, vrátí se jeho IP adresa v dotazu DNS a při veřejné registraci DNS se neprovádí žádné další vyhledávání.

Jak vidíte, překlad názvů je pod vaší kontrolou. Důvody pro tento návrh jsou:

  • Můžete mít složitý scénář, který zahrnuje vlastní servery DNS a integraci s místními sítěmi. V takovém případě potřebujete řídit, jak se názvy překládají na IP adresy.
  • Možná budete potřebovat přístup k trezoru klíčů bez privátních propojení. V takovém případě musí překlad názvu hostitele z virtuální sítě vrátit veřejnou IP adresu a k tomu dochází, protože trezory klíčů bez privátních propojení nemají privatelink v registraci názvu alias.

Dotazování koncového /healthstatus bodu trezoru klíčů

Váš trezor klíčů poskytuje /healthstatus koncový bod, který je možné použít pro diagnostiku. Hlavičky odpovědi zahrnují počáteční IP adresu, jak je vidět ve službě trezoru klíčů. Tento koncový bod můžete volat pomocí následujícího příkazu (nezapomeňte použít název hostitele trezoru klíčů):

Windows (PowerShell):

PS C:\> $(Invoke-WebRequest -UseBasicParsing -Uri https://fabrikam.vault.azure.net/healthstatus).Headers

Key                           Value
---                           -----
Pragma                        no-cache
x-ms-request-id               3729ddde-eb6d-4060-af2b-aac08661d2ec
x-ms-keyvault-service-version 1.2.27.0
x-ms-keyvault-network-info    addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security     max-age=31536000;includeSubDomains
Content-Length                4
Cache-Control                 no-cache
Content-Type                  application/json; charset=utf-8

Linux nebo nedávná verze Windows 10, která zahrnuje curl:

joe@MyUbuntu:~$ curl -i https://fabrikam.vault.azure.net/healthstatus

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
x-ms-request-id: 6c090c46-0a1c-48ab-b740-3442ce17e75e
x-ms-keyvault-service-version: 1.2.27.0
x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;
Strict-Transport-Security: max-age=31536000;includeSubDomains
Content-Length: 4

Pokud se vám nezobrazuje podobný výstup nebo pokud dojde k chybě sítě, znamená to, že váš trezor klíčů není přístupný prostřednictvím zadaného názvu hostitele (fabrikam.vault.azure.net v příkladu). Buď se název hostitele nepřeloží na správnou IP adresu, nebo máte problém s připojením v přenosové vrstvě. Příčinou můžou být problémy se směrováním, výpadky balíčků a další důvody. Musíte provést další šetření.

Odpověď musí obsahovat hlavičku x-ms-keyvault-network-info:

x-ms-keyvault-network-info: addr=10.4.5.6;act_addr_fam=InterNetworkV6;

Pole addr v x-ms-keyvault-network-info hlavičce zobrazuje IP adresu původu požadavku. Tato IP adresa může být jedna z následujících:

  • Privátní IP adresa počítače, který požadavek provádí. To znamená, že požadavek používá privátní propojení nebo koncové body služby. Toto je očekávaný výsledek pro privátní propojení.
  • Některé další privátní IP adresy, ne z počítače, který požadavek provádí. To znamená, že některé vlastní směrování je efektivní. Stále značí, že požadavek používá privátní propojení nebo koncové body služby.
  • Některá veřejná IP adresa. To značí, že se požadavek směruje na internet přes zařízení NAT (Gateway). To znamená, že požadavek nepoužívá privátní propojení a je potřeba opravit nějaký problém. Běžné důvody jsou 1) privátní koncový bod není ve schváleném a úspěšném stavu; a 2) název hostitele se nepřeloží na privátní IP adresu trezoru klíčů. Tento článek obsahuje akce řešení potíží pro oba případy.

Poznámka:

Pokud požadavek /healthstatus funguje, ale chybí hlavička x-ms-keyvault-network-info , koncový bod pravděpodobně nebude obsluhovat trezor klíčů. Vzhledem k tomu, že výše uvedené příkazy také ověřují certifikát HTTPS, může chybějící hlavička představovat znaménko manipulace.

Dotazování IP adresy trezoru klíčů přímo

Důležité

Přístup k trezoru klíčů bez ověření certifikátu HTTPS je nebezpečný a dá se použít jenom pro účely výuky. Produkční kód nesmí přistupovat k trezoru klíčů bez ověření na straně klienta. I když právě diagnostikujete problémy, může docházet k pokusům o manipulaci, které se neprojeví, pokud ve vašich požadavcích na trezor klíčů často zakážete ověřování certifikátů HTTPS.

Pokud jste nainstalovali nejnovější verzi PowerShellu, můžete přeskočit -SkipCertificateCheck kontroly certifikátů HTTPS a pak můžete ip adresu trezoru klíčů cílit přímo:

PS C:\> $(Invoke-WebRequest -SkipCertificateCheck -Uri https://10.1.2.3/healthstatus).Headers

Pokud používáte curl, můžete to samé udělat s argumentem -k :

joe@MyUbuntu:~$ curl -i -k https://10.1.2.3/healthstatus

Odpovědi musí být stejné jako v předchozí části, což znamená, že musí obsahovat x-ms-keyvault-network-info záhlaví se stejnou hodnotou. Koncový /healthstatus bod se nezajímá, pokud používáte název hostitele trezoru klíčů nebo IP adresu.

Pokud se zobrazí x-ms-keyvault-network-info vrácení jedné hodnoty požadavku pomocí názvu hostitele trezoru klíčů a jiné hodnoty požadavku pomocí IP adresy, pak každý požadavek cílí na jiný koncový bod. Podívejte se na vysvětlení addr pole z x-ms-keyvault-network-info předchozí části a rozhodněte se, který případ je nesprávný a je potřeba ho opravit.

8. Další změny a přizpůsobení, které způsobují dopad

Následující položky nejsou vyčerpávající prošetřované akce. Řeknou vám, kde hledat další problémy, ale k opravě problémů v těchto scénářích musíte mít pokročilé znalosti sítě.

Diagnostika vlastních serverů DNS ve službě Virtual Network

Na portálu otevřete prostředek virtuální sítě. V nabídce vlevo otevřete servery DNS. Pokud používáte "Vlastní", překlad DNS nemusí být popsaný v tomto dokumentu. Musíte diagnostikovat, jak servery DNS překládají název hostitele trezoru klíčů.

Pokud používáte výchozí servery DNS poskytnuté v Azure, je tento celý dokument použitelný.

Diagnostika přepisování hostitelů nebo vlastních serverů DNS na virtuálním počítači

Mnoho operačních systémů umožňuje nastavit explicitní pevnou IP adresu na název hostitele, obvykle změnou hosts souboru. Mohou také povolit přepsání serverů DNS. Pokud používáte některý z těchto scénářů, pokračujte možnostmi diagnostiky specifické pro systém.

Proxy servery promiscuous (Fiddler atd.)

S výjimkou případů, kdy je výslovně uvedeno, možnosti diagnostiky v tomto článku fungují pouze v případě, že v prostředí není k dispozici žádný proxy server. I když se tyto proxy servery často instalují výhradně na počítač, který se diagnostikuje (Fiddler je nejběžnějším příkladem), můžou pokročilí správci přepsat kořenové certifikační autority (CA) a nainstalovat proxy server na zařízení brány, která obsluhují více počítačů v síti. Tyto proxy servery můžou mít významný vliv na zabezpečení i spolehlivost. Společnost Microsoft nepodporuje konfigurace, které tyto produkty používají.

Další věci, které můžou mít vliv na připojení

Toto je seznam položek, které nejsou vyčerpávající, které najdete v pokročilých nebo složitých scénářích:

  • Nastavení brány firewall, buď Azure Firewall připojené k virtuální síti, nebo vlastní řešení brány firewall nasazené ve virtuální síti nebo v počítači.
  • Partnerský vztah sítě, který může mít vliv na to, které servery DNS se používají a jak se provoz směruje.
  • Vlastní řešení brány (NAT), která můžou mít vliv na směrování provozu, včetně provozu z dotazů DNS.