Share via


A privát kapcsolatok konfigurációs problémáinak diagnosztizálása az Azure Key Vaultban

Bevezetés

Ez a cikk segít a felhasználóknak a Key Vault és a Privát hivatkozások funkcióval kapcsolatos problémák diagnosztizálásában és megoldásában. Ez az útmutató segítséget nyújt a konfigurációs szempontokhoz, például a privát kapcsolatok első alkalommal történő működéséhez, vagy egy olyan helyzet megoldásához, amikor a privát hivatkozások valamilyen változás miatt leálltak.

Ha még nem ismerkedik ezzel a funkcióval, olvassa el a Key Vault integrálása Azure Private Link című témakört.

A cikk által tárgyalt problémák

  • A DNS-lekérdezések továbbra is egy nyilvános IP-címet adnak vissza a kulcstartóhoz, nem pedig egy privát IP-címet, amelyet elvárna a privát hivatkozások funkciótól.
  • Egy adott ügyfél által küldött, privát kapcsolatot használó kérések időtúllépéssel vagy hálózati hibával meghiúsulnak, és a probléma nem időszakos.
  • A kulcstartó privát IP-címmel rendelkezik, de a kérések továbbra is a ForbiddenByFirewall belső hibakóddal kapnak 403 választ.
  • Privát hivatkozásokat használ, de a kulcstartó továbbra is fogadja a nyilvános internetről érkező kéréseket.
  • A kulcstartó két privát végpontot használ. Az egyiket használó kérések megfelelően működnek, de a másikat használó kérések meghiúsulnak.
  • Van egy másik előfizetése, kulcstartója vagy virtuális hálózata, amely privát hivatkozásokat használ. Új, hasonló üzembe helyezést szeretne végezni, de nem kaphat privát hivatkozásokat, hogy ott dolgozhassanak.

A jelen cikk által NEM tárgyalt problémák

  • Időszakos csatlakozási probléma merült fel. Egy adott ügyfélen egyes kérések működnek, mások pedig nem működnek. Az időszakos problémákat általában nem a privát kapcsolatok konfigurációjában jelentkező probléma okozza; ezek a hálózat vagy az ügyfél túlterhelésének jele.
  • Olyan Azure-terméket használ, amely támogatja a BYOK-ot (Saját kulcs használata), a CMK-t (ügyfél által kezelt kulcsokat), vagy hozzáférést a kulcstartóban tárolt titkos kódokhoz. Ha engedélyezi a tűzfalat a Key Vault beállításaiban, a termék nem tud hozzáférni a kulcstartóhoz. Tekintse meg a termékspecifikus dokumentációt. Győződjön meg arról, hogy explicit módon támogatja a kulcstartókat, ha engedélyezve van a tűzfal. Szükség esetén forduljon az adott termék támogatási szolgálatához.

A cikk elolvasásához

Ha még nem ismerkedik a privát hivatkozásokkal, vagy összetett üzembe helyezést értékel, javasoljuk, hogy olvassa el a teljes cikket. Ellenkező esetben nyugodtan válassza ki azt a szakaszt, amely több értelmet ad a tapasztalt problémának.

Lássunk is hozzá!

1. Győződjön meg arról, hogy Ön az ügyfélkapcsolat tulajdonosa

Győződjön meg arról, hogy az ügyfél a virtuális hálózaton fut

Ez az útmutató segítséget nyújt az alkalmazáskódból származó Key Vault-kapcsolatok javításában. Ilyenek például az Azure Virtual Machines, az Azure Service Fabric-fürtök, a Azure App Service, a Azure Kubernetes Service (AKS) és hasonlók. Ez az útmutató a Azure Portal webes felhasználói felületén végrehajtott hozzáférésekre is vonatkozik, ahol a böngésző közvetlenül hozzáfér a kulcstartóhoz.

A privát hivatkozások definíciója szerint az alkalmazásnak, a szkriptnek vagy a portálnak azon a gépen, fürtön vagy környezetben kell futnia, amely ahhoz a Virtual Network kapcsolódik, ahol a privát végpont erőforrás üzembe lett helyezve.

Ha az alkalmazás, a szkript vagy a portál tetszőleges internetkapcsolattal rendelkező hálózaton fut, ez az útmutató NEM alkalmazható, és valószínűleg nem használhatók privát hivatkozások. Ez a korlátozás az Azure Cloud Shell végrehajtott parancsokra is vonatkozik, mivel a felhasználói böngésző helyett igény szerint biztosított távoli Azure-gépen futnak.

Ha felügyelt megoldást használ, tekintse meg az adott dokumentációt

Ez az útmutató NEM vonatkozik a Microsoft által felügyelt megoldásokra, ahol a kulcstartóhoz egy olyan Azure-termék fér hozzá, amely független az ügyfél Virtual Network. Ilyen esetek például az Azure Storage vagy Azure SQL, amely inaktív állapotban történő titkosításra van konfigurálva, Azure Event Hubs az adatok ügyfél által megadott kulcsokkal való titkosítását, Azure Data Factory a kulcstartóban tárolt szolgáltatás hitelesítő adatainak elérését, az Azure Pipelines titkos kulcsok kulcstartóból való lekérését és más hasonló forgatókönyveket. Ezekben az esetekben ellenőriznie kell, hogy a termék támogatja-e a kulcstartókat, ha engedélyezve van a tűzfal. Ezt a támogatást általában a Key Vault tűzfal Megbízható szolgáltatások funkciójával hajtják végre. Számos termék azonban különböző okokból nem szerepel a megbízható szolgáltatások listájában. Ebben az esetben lépjen kapcsolatba a termékspecifikus támogatással.

Néhány Azure-termék támogatja a virtuális hálózatok injektálásának fogalmát. A termék egyszerű kifejezéssel hozzáad egy hálózati eszközt az ügyfél Virtual Network, így a kéréseket úgy küldheti el, mintha az Virtual Network lett volna üzembe helyezve. Említendő példa az Azure Databricks. Az ilyen termékek a privát hivatkozások használatával kéréseket intézhetnek a kulcstartóhoz, és ez a hibaelhárítási útmutató segíthet.

2. Győződjön meg arról, hogy a kapcsolat jóvá lett hagyva és sikeres

Az alábbi lépésekkel ellenőrizheti a privát végponti kapcsolat jóváhagyását és sikerességét:

  1. Nyissa meg először az Azure Portalt, majd a kulcstartó erőforrását.
  2. Válassza a bal oldali menü Hálózatkezelés pontját.
  3. Válassza a Privát végponti kapcsolatok lapot. Ez megmutatja az összes privát végponti kapcsolatot és azok állapotát. Ha nincsenek kapcsolatok, vagy hiányzik a Virtual Network kapcsolata, létre kell hoznia egy új privát végpontot. Erről később ejtünk szót.
  4. Továbbra is a privát végponti kapcsolatokban keresse meg a diagnosztizáltat, és győződjön meg arról, hogy a "Kapcsolat állapota" jóváhagyva , a "Kiépítési állapot" pedig Sikeres.
    • Ha a kapcsolat "Függőben" állapotban van, lehet, hogy csak jóváhagyhatja.
    • Ha az "Elutasítva", a "Failed", a "Error", a "Disconnected" vagy más állapotú kapcsolat egyáltalán nem érvényes, létre kell hoznia egy új privát végpont-erőforrást.

Érdemes törölni a nem hatékony kapcsolatokat, hogy tisztán tarthassa a dolgokat.

3. Győződjön meg arról, hogy a Key Vault tűzfala megfelelően van konfigurálva

Fontos

A tűzfalbeállítások módosítása eltávolíthatja a hozzáférést azoktól a megbízható ügyfelektől, amelyek még mindig nem használnak privát hivatkozásokat. Győződjön meg arról, hogy tisztában van a tűzfalkonfiguráció egyes változásainak következményeival.

Fontos elképzelés, hogy a privát kapcsolatok funkció csak egy bezárt Virtual Network biztosít hozzáférést a kulcstartóhoz az adatkiszivárgás megakadályozása érdekében. Nem távolít el meglévő hozzáférést. A nyilvános internetről való hozzáférés hatékony letiltásához explicit módon engedélyeznie kell a Key Vault tűzfalát:

  1. Nyissa meg először az Azure Portalt, majd a kulcstartó erőforrását.
  2. Válassza a bal oldali menü Hálózatkezelés pontját.
  3. Győződjön meg arról, hogy a Tűzfalak és virtuális hálózatok lap felül van kiválasztva.
  4. Ha a Nyilvános hozzáférés engedélyezése az összes hálózatból lehetőséget választja, ez megmagyarázza, hogy a külső ügyfelek miért férhetnek hozzá továbbra is a kulcstartóhoz. Ha azt szeretné, hogy a Key Vault csak Private Link legyen elérhető, válassza a Nyilvános hozzáférés letiltása lehetőséget.

A következő utasítások a tűzfalbeállításokra is vonatkoznak:

  • A privát kapcsolatok funkcióhoz nincs szükség "virtuális hálózat" megadására a kulcstartó tűzfalbeállításaiban. A kulcstartó privát IP-címét használó kéréseknek (lásd a következő szakaszt) akkor is működnie kell, ha nincs megadva virtuális hálózat a Key Vault tűzfalbeállításaiban.
  • A privát hivatkozások funkcióhoz nincs szükség IP-cím megadására a Key Vault tűzfalbeállításaiban. A kulcstartó magánhálózati IP-címét használó összes kérésnek működnie kell, még akkor is, ha a tűzfalbeállításokban nem adott meg IP-címet.

Ha privát hivatkozásokat használ, a kulcstartó tűzfalában a virtuális hálózat vagy IP-cím megadásának egyetlen motivációja a következő:

  • Van egy hibrid rendszere, amelyben egyes ügyfelek privát hivatkozásokat használnak, mások szolgáltatásvégpontokat, mások nyilvános IP-címet használnak.
  • Privát hivatkozásokra vált. Ebben az esetben, ha meggyőződik arról, hogy az összes ügyfél privát hivatkozásokat használ, el kell távolítania a virtuális hálózatokat és IP-címeket a Key Vault tűzfalbeállításaiból.

4. Győződjön meg arról, hogy a kulcstartó privát IP-címmel rendelkezik

A privát és a nyilvános IP-címek közötti különbség

A magánhálózati IP-címek mindig az alábbi formátumok egyikével rendelkezik:

  • 10.x.x.x: Példák: 10.1.2.3, 10.56.34.12.
  • 172.16.x.x–172.32.x.x: Példák: 172.20.1.1, 172.31.67.89.
  • 192.168.x.x: Példák: 192.168.0.1, 192.168.100.7

Bizonyos IP-címek és -tartományok fenntartottak:

  • 224.x.x.x: Csoportos küldés
  • 255.255.255.255: Közvetítés
  • 127.x.x.x: Visszacsatolás
  • 169.254.x.x: Link-local
  • 168.63.129.16: Belső DNS

Minden más IP-cím nyilvános.

Amikor a portálon tallózik, vagy olyan parancsot futtat, amely megjeleníti az IP-címet, győződjön meg arról, hogy az IP-cím privát, nyilvános vagy fenntartott. A privát kapcsolatok működéséhez a kulcstartó gazdagépnevének a Virtual Network címtartományhoz tartozó magánhálózati IP-címre kell feloldania.

A kulcstartó privát IP-címének megkeresése a virtuális hálózaton

Diagnosztizálnia kell a gazdagépnév feloldását, és ehhez ismernie kell a kulcstartó pontos privát IP-címét, amelyen engedélyezve van a privát hivatkozások használata. A cím megkereséséhez kövesse az alábbi eljárást:

  1. Nyissa meg először az Azure Portalt, majd a kulcstartó erőforrását.
  2. Válassza a bal oldali menü Hálózatkezelés pontját.
  3. Válassza a Privát végponti kapcsolatok lapot. Ez megmutatja az összes privát végponti kapcsolatot és azok állapotát.
  4. Keresse meg a diagnosztizáltat, és győződjön meg arról, hogy a "Kapcsolat állapota " jóváhagyva , a kiépítési állapot pedig Sikeres. Ha ezt nem látja, térjen vissza a dokumentum korábbi szakaszaihoz.
  5. Ha megtalálta a megfelelő elemet, kattintson a Privát végpont oszlopban található hivatkozásra. Ekkor megnyílik a privát végpont erőforrása.
  6. Az Áttekintés lapon megjelenhet az Egyéni DNS-beállítások nevű szakasz. Győződjön meg arról, hogy csak egyetlen bejegyzés felel meg a kulcstartó gazdaeszköznevének. Ez a bejegyzés a Key Vault privát IP-címét jeleníti meg.
  7. A Hálózati adapter hivatkozásra kattintva ellenőrizheti, hogy a magánhálózati IP-cím ugyanaz-e, mint az előző lépésben. A hálózati adapter egy virtuális eszköz, amely a kulcstartót képviseli.

Az IP-cím az, amelyet a virtuális gépek és az ugyanabban a Virtual Network futó egyéb eszközök használnak a kulcstartóhoz való csatlakozáshoz. Jegyezze fel az IP-címet, vagy tartsa nyitva a böngészőlapot, és ne érintse meg, amíg további vizsgálatokat végez.

Megjegyzés

Ha a kulcstartó több privát végponttal rendelkezik, akkor több privát IP-címmel rendelkezik. Ez csak akkor hasznos, ha több virtuális hálózat is hozzáfér ugyanahhoz a kulcstartóhoz, mindegyik saját privát végponton keresztül (a privát végpont egyetlen Virtual Network tartozik). Győződjön meg arról, hogy a megfelelő Virtual Network diagnosztizálja a problémát, és válassza ki a megfelelő privát végpontkapcsolatot a fenti eljárásban. Továbbá ne hozzon létre több privát végpontot ugyanahhoz a Key Vault ugyanabban a Virtual Network. Ez nem szükséges, és zavart okozhat.

5. A DNS-feloldás ellenőrzése

A DNS-feloldás a kulcstartó gazdagépnevének (például: fabrikam.vault.azure.net) IP-címre (például: ) történő lefordításának folyamata. 10.1.2.3 Az alábbi alszakaszok a DNS-feloldás várt eredményeit mutatják be az egyes forgatókönyvekben.

Ez a szakasz tanulási célokra szolgál. Ha a kulcstartó nem rendelkezik jóváhagyott állapotú privát végpontkapcsolattal, a gazdagépnév feloldása az alábbihoz hasonló eredményt ad:

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

Láthatja, hogy a név nyilvános IP-címre lesz feloldva, és nincs privatelink alias. Az aliast később ismertetjük, ne aggódjon miatta.

A fenti eredmény attól függetlenül várható, hogy a gép csatlakozik-e a Virtual Network, vagy egy tetszőleges, internetkapcsolattal rendelkező gép. Ennek az az oka, hogy a kulcstartó nem rendelkezik jóváhagyott állapotú privát végpontkapcsolattal, ezért nincs szükség a kulcstartóra a privát kapcsolatok támogatásához.

Ha a kulcstartó egy vagy több jóváhagyott állapotú privát végpontkapcsolattal rendelkezik, és az állomásnevet egy tetszőleges, az internethez csatlakoztatott gépről oldja fel (egy olyan gépről, amely nincs csatlakoztatva a privát végpontot tároló Virtual Network), a következőt kell megtalálnia:

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

Az előző forgatókönyvhez képest lényeges különbség, hogy van egy új alias a értékkel {vaultname}.privatelink.vaultcore.azure.net. Ez azt jelenti, hogy a Key Vault adatsíkja készen áll a privát kapcsolatokból érkező kérések fogadására.

Ez nem jelenti azt, hogy a Virtual Network kívüli gépekről (például az imént használttól) érkező kérések privát hivatkozásokat fognak használni – ezek nem. Ez abból a tényből látható, hogy a gazdagépnév továbbra is nyilvános IP-címre van feloldva. Csak a Virtual Network csatlakoztatott gépek használhatnak privát kapcsolatokat. Erről további információt is olvashat.

Ha nem látja az aliastprivatelink, az azt jelenti, hogy a kulcstartó nulla privát végponti kapcsolattal rendelkezik.Approved az újrapróbálkozás előtt Vissza erre a szakaszra.

Ha a kulcstartó egy vagy több jóváhagyott állapotú privát végpontkapcsolattal rendelkezik, és a gazdanevet egy, a privát végpontot létrehozó Virtual Network csatlakoztatott gépről oldja fel, ez a várt válasz:

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

Két lényeges különbség van. Először a név egy magánhálózati IP-címre lesz feloldva. Ennek az IP-címnek kell lennie, amelyet a cikk megfelelő szakaszában találtunk. Másodszor, nincs más alias az privatelink után. Ennek az az oka, hogy a Virtual Network DNS-kiszolgálók elfogják az aliasok láncát, és közvetlenül a névből fabrikam.privatelink.vaultcore.azure.netadják vissza a magánhálózati IP-címet. Ez a bejegyzés valójában egy A rekord egy saját DNS zónában. Erről további információt is olvashat.

Megjegyzés

A fenti eredmény csak a privát végpontot létrehozó Virtual Network csatlakoztatott virtuális gépen történik. Ha nincs üzembe helyezve virtuális gép a privát végpontot tartalmazó Virtual Network, telepítsen egyet, és csatlakozzon távolról hozzá, majd hajtsa végre a nslookup fenti parancsot (Windows) vagy a host parancsot (Linux).

Ha ezeket a parancsokat egy olyan virtuális gépen futtatja, amely ahhoz a Virtual Network csatlakozik, ahol a privát végpont létre lett hozva, és nem jelenítik meg a kulcstartó privát IP-címét, a következő szakasz segíthet a probléma megoldásában.

6. A saját DNS zóna ellenőrzése

Ha a DNS-feloldás nem működik az előző szakaszban leírtak szerint, előfordulhat, hogy a saját DNS Zónával van probléma, és ez a szakasz segíthet. Ha a DNS-feloldás a key vault megfelelő privát IP-címét jeleníti meg, akkor a saját DNS Zóna valószínűleg helyes. Ebben az esetben kihagyhatja ezt a szakaszt.

Ellenőrizze, hogy létezik-e a szükséges saját DNS zone erőforrás

Az Azure-előfizetésnek rendelkeznie kell egy saját DNS Zone-erőforrással, amely pontosan ezt a nevet adja:

privatelink.vaultcore.azure.net

Az erőforrás jelenlétének ellenőrzéséhez nyissa meg a Portál előfizetési oldalát, és válassza a bal oldali menü "Erőforrások" elemét. Az erőforrás nevének privatelink.vaultcore.azure.net, az erőforrástípusnak pedig saját DNS zónának kell lennie.

Ez az erőforrás általában automatikusan létrejön, amikor egy közös eljárással hoz létre privát végpontot. Vannak azonban olyan esetek, amikor ez az erőforrás nem jön létre automatikusan, és manuálisan kell elvégeznie. Előfordulhat, hogy ezt az erőforrást is véletlenül törölték.

Ha nem rendelkezik ezzel az erőforrással, hozzon létre egy új saját DNS Zone-erőforrást az előfizetésében. Ne feledje, hogy a névnek pontosan privatelink.vaultcore.azure.net, szóközök és további pont nélkül kell lennie. Ha helytelen nevet ad meg, a cikkben ismertetett névfeloldás nem fog működni. Az erőforrás létrehozásával kapcsolatos további információkért lásd: Azure privát DNS-zóna létrehozása a Azure Portal használatával. Ha követi ezt a lapot, kihagyhatja Virtual Network létrehozását, mert ezen a ponton már rendelkeznie kell egyvalakinek. Az érvényesítési eljárásokat a Virtual Machines is kihagyhatja.

Ellenőrizze, hogy a saját DNS zóna kapcsolódik-e a Virtual Network

Nem elég egy saját DNS zóna. A privát végpontot tartalmazó Virtual Network is hozzá kell kapcsolni. Ha a saját DNS zóna nincs a megfelelő Virtual Network csatolva, a Virtual Network DNS-feloldása figyelmen kívül hagyja a saját DNS zónát.

Nyissa meg a saját DNS Zone erőforrást, és kattintson a virtuális hálózati kapcsolatok lehetőségre a bal oldali menüben. Ekkor megjelenik a hivatkozások listája, amelyek mindegyike egy Virtual Network nevét tartalmazza az előfizetésben. A privát végpont erőforrását tartalmazó Virtual Network itt kell szerepelnie. Ha nincs ott, adja hozzá. A részletes lépésekért lásd : A virtuális hálózat összekapcsolása. Bejelöletlenül hagyhatja az "Automatikus regisztráció engedélyezése" jelölőnégyzetet – ez a funkció nem kapcsolódik a privát kapcsolatokhoz.

Miután a saját DNS Zóna hozzá van kapcsolva a Virtual Network, a Virtual Network származó DNS-kérések a saját DNS zónában keresik a neveket. Ez a privát végpontot létrehozó Virtual Network csatlakoztatott Virtual Machines helyes címfeloldásához szükséges.

Megjegyzés

Ha most mentette a hivatkozást, eltarthat egy ideig, amíg ez érvénybe lép, még akkor is, ha a portál azt mondja, hogy a művelet befejeződött. Előfordulhat, hogy újra kell indítania a DNS-feloldás teszteléséhez használt virtuális gépet.

Győződjön meg arról, hogy a saját DNS zóna a megfelelő A rekordot tartalmazza

A Portál használatával nyissa meg a nevű saját DNS zónátprivatelink.vaultcore.azure.net. Az Áttekintés lapon az összes rekord látható. Alapértelmezés szerint egy nevű és típusú SOArekord @ lesz, amely a következőt jelenti: Hatóság kezdete. Ne nyúlj hozzá.

Ahhoz, hogy a Key Vault névfeloldása működjön, egy egyszerű tárolónévvel rendelkező rekordnak kell lennie A utótag vagy pont nélkül. Ha például az állomásnév fabrikam.vault.azure.net, akkor egy utótag vagy pont nélküli rekordnak fabrikamkell lennieA.

Emellett a A rekord értékének (az IP-címnek) a key vault privát IP-címének kell lennie. Ha megtalálta a A rekordot, de nem a megfelelő IP-címet tartalmazza, el kell távolítania a nem megfelelő IP-címet, és hozzá kell adnia egy újat. Javasoljuk, hogy távolítsa el a teljes A rekordot, és adjon hozzá egy újat.

Megjegyzés

Amikor eltávolít vagy módosít egy rekordot A , előfordulhat, hogy a gép továbbra is a régi IP-címre lesz feloldva, mert előfordulhat, hogy a TTL (élettartam) értéke még nem járt le. Javasoljuk, hogy mindig adjon meg 10 másodpercnél nem kisebb és 600 másodpercnél (10 percnél) nem nagyobb TTL-értéket. Ha túl nagy értéket ad meg, az ügyfelek túl sokáig tarthatnak a kimaradások utáni helyreállításhoz.

DNS-feloldás több Virtual Network

Ha több virtuális hálózat van, és mindegyik saját privát végponti erőforrással rendelkezik, amely ugyanarra a kulcstartóra hivatkozik, akkor a kulcstartó gazdagépnevét a hálózattól függően egy másik magánhálózati IP-címre kell feloldani. Ez azt jelenti, hogy több saját DNS zónára is szükség van, amelyek mindegyike egy másik Virtual Network van csatolva, és egy másik IP-címet használ a A rekordban.

Speciálisabb forgatókönyvek esetén előfordulhat, hogy a virtuális hálózatokon engedélyezve van a társviszony-létesítés. Ebben az esetben csak egy Virtual Network van szüksége a privát végpont erőforrására, bár előfordulhat, hogy mindkettőt hozzá kell kapcsolni a saját DNS Zone erőforráshoz. Ezt a forgatókönyvet nem fedi le közvetlenül ez a dokumentum.

Ismerje meg, hogy ön rendelkezik a DNS-feloldás feletti vezérléssel

Az előző szakaszban leírtak szerint a privát kapcsolatokkal rendelkező kulcstartóban szerepel az alias {vaultname}.privatelink.vaultcore.azure.net a nyilvános regisztrációban. A Virtual Network által használt DNS-kiszolgáló a nyilvános regisztrációt használja, de minden aliast ellenőriz egy privát regisztrációhoz, és ha talál ilyet, a nyilvános regisztráció során definiált aliasok követését leállítja.

Ez a logika azt jelenti, hogy ha a Virtual Network egy nevű saját DNS zónához privatelink.vaultcore.azure.netkapcsolódik, és a kulcstartó nyilvános DNS-regisztrációja aliassal fabrikam.privatelink.vaultcore.azure.net rendelkezik (vegye figyelembe, hogy a kulcstartó gazdagépnév-utótagja pontosan megegyezik a saját DNS zóna nevével), akkor a DNS-lekérdezés egy A olyan rekordot keres, amelynek neve fabrikamszerepel a saját DNS zónában. Ha a A rekord megtalálható, annak IP-címét adja vissza a RENDSZER a DNS-lekérdezésben, és nem végez további kereséseket a nyilvános DNS-regisztráció során.

Mint látható, a névfeloldás az Ön felügyelete alatt áll. Ennek a kialakításnak az alapjai a következők:

  • Előfordulhat, hogy összetett forgatókönyve van, amely magában foglalja az egyéni DNS-kiszolgálókat és a helyszíni hálózatokkal való integrációt. Ebben az esetben szabályoznia kell, hogy a nevek hogyan legyenek lefordítva IP-címekre.
  • Előfordulhat, hogy privát kapcsolatok nélkül kell hozzáférnie egy kulcstartóhoz. Ebben az esetben a gazdagépnévnek a Virtual Network való feloldásához vissza kell adnia a nyilvános IP-címet, és ez azért történik, mert a privát kapcsolatokkal nem rendelkező kulcstartók nem rendelkeznek aliassal privatelink a névregisztrációban.

/healthstatus A kulcstartó végpontjának lekérdezése

A kulcstartó biztosítja a /healthstatus végpontot, amely diagnosztikához használható. A válaszfejlécek tartalmazzák a forrás IP-címét a Key Vault szolgáltatás által látott módon. Ezt a végpontot a következő paranccsal hívhatja meg (ne felejtse el használni a kulcstartó gazdanevét):

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, vagy a Windows 10 legújabb verziója, amely tartalmazza a következőketcurl:

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

Ha nem ehhez hasonló kimenetet kap, vagy hálózati hibát kap, az azt jelenti, hogy a kulcstartó nem érhető el a megadott gazdanéven (fabrikam.vault.azure.net a példában). Az állomásnév nem a megfelelő IP-címre van feloldva, vagy csatlakozási probléma merült fel az átviteli rétegben. Ezt útválasztási problémák, csomagvesztések és egyéb okok okozhatják. További vizsgálatot kell végeznie.

A válasznak tartalmaznia kell a fejlécet x-ms-keyvault-network-info:

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

A addr fejlécben lévő x-ms-keyvault-network-info mező a kérés forrásának IP-címét jeleníti meg. Ez az IP-cím a következők egyike lehet:

  • A kérést végző gép magánhálózati IP-címe. Ez azt jelzi, hogy a kérés privát hivatkozásokat vagy szolgáltatásvégpontokat használ. Ez a privát kapcsolatok várt eredménye.
  • Más magánhálózati IP-cím, nem a kérést végző gépről. Ez azt jelzi, hogy néhány egyéni útválasztás érvényes. Továbbra is azt jelzi, hogy a kérés privát hivatkozásokat vagy szolgáltatásvégpontokat használ.
  • Néhány nyilvános IP-cím. Ez azt jelzi, hogy a kérést egy átjáró (NAT) eszközön keresztül irányítja az internetre. Ez azt jelzi, hogy a kérés NEM privát hivatkozásokat használ, és néhány problémát ki kell javítani. Ennek gyakori okai: 1) a privát végpont nincs jóváhagyva és sikeres állapotban; és 2) az állomásnév nem oldódik fel a kulcstartó privát IP-címére. Ez a cikk mindkét esetben tartalmaz hibaelhárítási műveleteket.

Megjegyzés

Ha a kérés /healthstatus működik, de a x-ms-keyvault-network-info fejléc hiányzik, akkor a kulcstartó valószínűleg nem szolgálja ki a végpontot. Mivel a fenti parancsok a HTTPS-tanúsítványt is ellenőrzik, a hiányzó fejléc az illetéktelen módosítás jele lehet.

A Key Vault IP-címének közvetlen lekérdezése

Fontos

A kulcstartó HTTPS-tanúsítvány érvényesítése nélkül való elérése veszélyes, és csak tanulási célokra használható. Az éles kódnak SOHA nem szabad hozzáférnie a kulcstartóhoz az ügyféloldali ellenőrzés nélkül. Még ha csak diagnosztizálja is a problémákat, előfordulhat, hogy illetéktelen módosítási kísérletek történnek, amelyek nem fognak kiderülni, ha gyakran tiltja le a HTTPS-tanúsítvány érvényesítését a Key Vaultra irányuló kérelmekben.

Ha a PowerShell legújabb verzióját telepítette, a használatával -SkipCertificateCheck kihagyhatja a HTTPS-tanúsítványellenőrzéseket, majd közvetlenül megcélozhatja a kulcstartó IP-címét :

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

Ha a függvényt használja curl, ugyanezt az argumentummal -k teheti meg:

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

A válaszoknak meg kell egyeznie az előző szakaszsal, ami azt jelenti, hogy a x-ms-keyvault-network-info fejlécnek ugyanazzal az értékkel kell rendelkeznie. A /healthstatus végpont nem számít, ha a kulcstartó gazdagépnevét vagy IP-címét használja.

Ha azt látja x-ms-keyvault-network-info , hogy egy értéket ad vissza a kéréshez a Key Vault állomásnevével, egy másikat pedig a kéréshez az IP-cím használatával, akkor minden kérés egy másik végpontot céloz meg. Tekintse meg az addr előző szakaszban szereplő mező x-ms-keyvault-network-info magyarázatát, és döntse el, hogy melyik eset hibás, és ki kell javítani.

8. Egyéb módosítások és testreszabások, amelyek hatással vannak

Az alábbi elemek nem teljes körű vizsgálati műveletek. Ezekből megtudhatja, hol keressen további problémákat, de az ilyen helyzetekben felmerülő problémák megoldásához speciális hálózati ismeretekkel kell rendelkeznie.

Egyéni DNS-kiszolgálók diagnosztizálása a Virtual Network

A Portálon nyissa meg a Virtual Network erőforrást. A bal oldali menüben nyissa meg a DNS-kiszolgálókat. Ha "Egyéni" kifejezést használ, akkor előfordulhat, hogy a DNS-feloldás nem a jelen dokumentumban leírtak szerint történik. Diagnosztizálnia kell, hogy a DNS-kiszolgálók hogyan oldják fel a kulcstartó gazdanevét.

Ha az azure-beli alapértelmezett DNS-kiszolgálókat használja, ez a teljes dokumentum alkalmazható.

Felülíró vagy egyéni DNS-kiszolgálókat használó gazdagépek diagnosztizálása a virtuális gépen

Számos operációs rendszer lehetővé teszi, hogy állomásnévként explicit rögzített IP-címet állítsunk be, általában a hosts fájl módosításával. Engedélyezhetik a DNS-kiszolgálók felül bírálását is. Ha ezen forgatókönyvek valamelyikét használja, folytassa a rendszerspecifikus diagnosztikai beállításokkal.

Kétértelmű proxyk (Fiddler stb.)

A jelen cikkben szereplő diagnosztikai beállítások csak akkor működnek, ha a környezetben nem található találó proxy. Bár ezek a proxyk gyakran kizárólag a diagnosztizált gépen vannak telepítve (a Fiddler a leggyakoribb példa), a haladó rendszergazdák felülírhatják a főtanúsítvány-hitelesítésszolgáltatókat (CA-kat), és telepíthetnek egy találó proxyt a hálózat több gépét kiszolgáló átjáróeszközökre. Ezek a proxyk jelentős mértékben befolyásolhatják a biztonságot és a megbízhatóságot. A Microsoft nem támogatja az ilyen termékeket használó konfigurációkat.

Egyéb dolgok, amelyek hatással lehetnek a kapcsolatra

Ez a lista a speciális vagy összetett forgatókönyvekben található elemek nem teljes listáját tartalmazza:

  • Tűzfalbeállítások, a Virtual Network csatlakoztatott Azure Firewall, vagy a Virtual Network vagy a gépen üzembe helyező egyéni tűzfalmegoldás.
  • Hálózati társviszony-létesítés, amely hatással lehet a használt DNS-kiszolgálókra és a forgalom irányítására.
  • Egyéni átjáró-(NAT-) megoldások, amelyek hatással lehetnek a forgalom irányítására, beleértve a DNS-lekérdezésekből érkező forgalmat is.