Megosztás a következőn keresztül:


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 diagnosztizálni és kijavítani a Key Vault és a Privát hivatkozások funkcióval kapcsolatos problémákat. Ez az útmutató segítséget nyújt a konfigurációs szempontokhoz, például a privát hivatkozások első használatba kéré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 rendelkezik ezzel a funkcióval, olvassa el a Key Vault integrálása az Azure Private Linkkel 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 választ kapnak 403 a ForbiddenByFirewall belső hibakóddal.
  • 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érelmek megfelelően működnek, a másikat használó kérelmek azonban meghiúsulnak.
  • Van egy másik előfizetése, kulcstartója vagy virtuális hálózata, amely privát hivatkozásokat használ. Szeretne egy új, hasonló üzembe helyezést végezni, de nem kaphat privát hivatkozásokat az ott való munkavégzéshez.

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

  • Időszakos kapcsolati probléma áll fenn. 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; 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 a kulcstartóban tárolt titkos kulcsokhoz való hozzáférést. Ha engedélyezi a tűzfalat a key vault beállításaiban, az adott 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 Machinesben, az Azure Service Fabric-fürtökben, a Azure-alkalmazás Service-ben, az Azure Kubernetes Service-ben (AKS) és hasonlókban futó alkalmazások és szkriptek. Ez az útmutató az 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 virtuális hálózathoz csatlakoztatott gépen, fürtön vagy környezetben kell futnia, amelyben a privát végpont erőforrás üzembe lett helyezve.

Ha az alkalmazás, a szkript vagy a portál tetszőleges internetes hálózaton fut, ez az útmutató NEM alkalmazható, és valószínűleg nem használható magánhivatkozások. Ez a korlátozás az Azure Cloud Shellben 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.

Felügyelt megoldás használata esetén tekintse meg a konkrét 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 virtuális hálózatától. Ilyen eset például az Azure Storage vagy az Azure SQL, amely inaktív állapotban történő titkosításra van konfigurálva, az Azure Event Hubs az ügyfél által megadott kulcsokkal titkosítja az adatokat, az Azure Data Factory hozzáfér a kulcstartóban tárolt szolgáltatás hitelesítő adataihoz, az Azure Pipelines titkos kulcsokat kér le a kulcstartóból, és más hasonló forgatókönyvek. Ezekben az esetekben ellenőriznie kell, hogy a termék támogatja-e a kulcstartókat, ha engedélyezve van a tűzfal. Ez a támogatás általában a Key Vault tűzfal Megbízható szolgáltatások funkciójával történik. 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ű módon hozzáad egy hálózati eszközt az ügyfél virtuális hálózatához, lehetővé téve, hogy úgy küldjön kéréseket, mintha üzembe helyezték volna a virtuális hálózaton. Figyelemre méltó 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. Ellenőrizze, hogy a kapcsolat jóvá lett-e hagyva és sikeres-e

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 ha a virtuális hálózat kapcsolata hiányzik, létre kell hoznia egy új privát végpontot. Erről később ejtünk szót.
  4. Továbbra is privát végpontkapcsolatokban 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, akkor lehet, hogy csak jóváhagyhatja.
    • Ha a kapcsolat "Elutasítva", "Sikertelen", "Hiba", "Leválasztva" vagy más állapot, akkor egyáltalán nem hatékony, létre kell hoznia egy új privát végpont-erőforrást.

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

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 a még mindig nem privát hivatkozásokat használó megbízható ügyfelektől. Győződjön meg arról, hogy tisztában van a tűzfalkonfiguráció egyes változásainak következményeival.

Fontos szempont, hogy a privát kapcsolatok funkció csak olyan virtuális hálózat kulcstartójához biztosít hozzáférést, amely bezárva van 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 a virtuális hálózatok lap felül van kiválasztva.
  4. Ha úgy találja , hogy a nyilvános hozzáférés engedélyezése az összes hálózatból ki van választva, ez megmagyarázza, hogy a külső ügyfelek miért férhetnek hozzá a kulcstartóhoz. Ha azt szeretné, hogy a Key Vault csak privát kapcsolaton keresztül legyen elérhető, válassza a Nyilvános hozzáférés letiltása lehetőséget.

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

  • A privát kapcsolatok funkcióhoz nincs szükség "virtuális hálózat" megadására a key vault 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 kapcsolatok funkcióhoz nincs szükség IP-cím megadására a Key Vault tűzfalbeállításaiban. A kulcstartó privát 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 minden ügyfél privát hivatkozásokat használ, el kell távolítania a virtuális hálózatokat és AZ 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: Broadcast
  • 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 az IP-címet megjelenítő parancsot futtat, győződjön meg arról, hogy az IP-cím privát, nyilvános vagy fenntartott. Ahhoz, hogy a privát hivatkozások működjenek, a kulcstartó gazdagépnevének a virtuális hálózat címteréhez tartozó magánhálózati IP-címre kell feloldania.

A key vault 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, és engedélyeznie kell a privát hivatkozásokat. 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 van, és a kiépítési állapot 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 megjelenhetnek 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 adapteren található 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 ugyanazon a virtuális hálózaton 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.

Feljegyzés

Ha a kulcstartó több privát végpontot is használ, 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 virtuális hálózathoz tartozik). Győződjön meg arról, hogy a megfelelő virtuális hálózattal kapcsolatos problémát diagnosztizálja, és a fenti eljárásban válassza ki a megfelelő privát végpontkapcsolatot. Ezenkívül ne hozzon létre több privát végpontot ugyanahhoz a Key Vaulthoz ugyanabban a virtuális hálózaton. 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) EGY IP-címre (például: ) történő fordításának folyamata. 10.1.2.3 Az alábbi alszakaszok az egyes forgatókönyvekben a DNS-feloldás várt eredményeit mutatják.

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 egy 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 a virtuális hálózathoz, vagy tetszőleges, internetkapcsolattal rendelkező gép. Ez azért fordul elő, mert 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 a gazdagépnevet egy, az internethez csatlakoztatott tetszőleges gépről oldja fel (egy olyan gépről, amely nem csatlakozik ahhoz a virtuális hálózathoz, ahol a privát végpont található), 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 jelentős különbség, hogy van egy új alias az értékkel {vaultname}.privatelink.vaultcore.azure.net. Ez azt jelenti, hogy a Key Vault adatsíkja készen áll arra, hogy fogadja a privát kapcsolatokból érkező kéréseket.

Ez nem jelenti azt, hogy a virtuális hálózaton kívüli gépekről (például az imént használt gépről) végrehajtott kérések privát hivatkozásokat használnak – nem fognak. Ez abból a tényből látható, hogy a gazdagépnév továbbra is nyilvános IP-címre lesz feloldva. Csak a virtuális hálózathoz csatlakoztatott gépek használhatnak privát kapcsolatokat. Erről bővebben is olvashat.

Ha nem látja az privatelink aliast, az azt jelenti, hogy a kulcstartónak nincs privát végpontkapcsolata állapotban Approved . Az újrapróbálkozás előtt térjen vissza erre a szakaszra .

Ha a kulcstartó egy vagy több jóváhagyott állapotú privát végpontkapcsolattal rendelkezik, és feloldja a gazdagépnevet egy olyan gépről, amely ahhoz a virtuális hálózathoz csatlakozik, ahol a privát végpont létre lett hozva, 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 jelentős különbség van. Először is a név egy privát IP-címre lesz feloldva. Ennek kell lennie a cikk megfelelő szakaszában talált IP-címnek. Másodszor, az egyik után privatelink nincs más alias. Ez azért történik, mert a virtuális hálózati 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 bővebben is olvashat.

Feljegyzés

A fenti eredmény csak a virtuális hálózathoz csatlakoztatott virtuális gépen történik, ahol a privát végpont létre lett hozva. Ha nem telepített virtuális gépet a privát végpontot tartalmazó virtuális hálózaton, telepítsen egyet, és csatlakozzon távolról hozzá, majd hajtsa végre a nslookup fenti parancsot (Windows) vagy a host fenti parancsot (Linux).

Ha ezeket a parancsokat egy olyan virtuális gépen futtatja, amely a privát végpontot létrehozó virtuális hálózathoz csatlakozik, és nem jeleníti 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 probléma merül fel a saját DNS zónával kapcsolatban, é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 zónaerőforrás

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

privatelink.vaultcore.azure.net

Az erőforrás meglétét a portál előfizetési lapján, a bal oldali menü "Erőforrások" elemére kattintva ellenőrizheti. Az erőforrás nevének meg kell lennieprivatelink.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 jön létre, 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 véletlenül törölték is.

Ha nem rendelkezik ezzel az erőforrással, hozzon létre egy új saját DNS zónaerőforrást az előfizetésében. Ne feledje, hogy a névnek pontosan privatelink.vaultcore.azure.netszóközök vagy 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-beli privát DNS-zóna létrehozása az Azure Portal használatával. Ha ezt a lapot követi, kihagyhatja a virtuális hálózat létrehozását, mert ezen a ponton már rendelkeznie kell egyet. A virtuális gépekkel is kihagyhatja az érvényesítési eljárásokat.

Ellenőrizze, hogy a saját DNS zóna kapcsolódik-e a virtuális hálózathoz

Nem elég egy saját DNS zóna. A privát végpontot tartalmazó virtuális hálózathoz is hozzá kell kapcsolni. Ha a saját DNS zóna nincs a megfelelő virtuális hálózathoz csatolva, az adott virtuális hálózat dns-feloldása figyelmen kívül hagyja a saját DNS zónát.

Nyissa meg a saját DNS Zóna erőforrást, és kattintson a bal oldali menüBen a Virtuális hálózati kapcsolatok lehetőségre. Ez megjeleníti a hivatkozások listáját, amelyek mindegyike egy virtuális hálózat nevét tartalmazza az előfizetésben. A privát végpont erőforrását tartalmazó virtuális hálózatnak itt kell szerepelnie. Ha nem szerepel, adja hozzá. Részletes lépésekért lásd a virtuális hálózat összekapcsolása című témakört. Az "Automatikus regisztráció engedélyezése" jelölőnégyzet bejelöletlen marad – ez a funkció nem kapcsolódik a privát hivatkozásokhoz.

Ha a saját DNS zóna a virtuális hálózathoz van csatolva, a virtuális hálózatból származó DNS-kérések a saját DNS zónában keresnek neveket. Erre azért van szükség, hogy a címfeloldás helyes legyen a virtuális hálózathoz csatlakoztatott virtuális gépeken, ahol a privát végpont létre lett hozva.

Feljegyzé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 szerint 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 saját DNS zónát névvelprivatelink.vaultcore.azure.net. Az Áttekintés lapon az összes rekord látható. Alapértelmezés szerint egy névvel és típussal SOArendelkező @ rekord lesz, amely a Hatóság kezdetét jelenti. Ne nyúljon hozzá.

Ahhoz, hogy a kulcstartó névfeloldása működjön, egy egyszerű tárolónévvel rendelkező rekordnak kell lennie A utótagok és pont nélkül. Ha például a gazdagép neve, fabrikam.vault.azure.netakkor a névvel fabrikamrendelkező rekordnak utótagok és pont nélkül kell lennieA.

Emellett a A rekord értékének (az IP-címnek) a kulcstartó 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 rossz IP-címet, és hozzá kell adnia egy újat. Javasoljuk, hogy távolítsa el a teljes A rekordot, és adjon hozzá egy újat.

Feljegyzés

Amikor eltávolít vagy módosít egy rekordot A , a gép továbbra is feloldhatja a régi IP-címet, 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 virtuális hálózathoz

Ha több virtuális hálózat van, és mindegyiknek saját privát végpontja van, amely ugyanarra a kulcstartóra hivatkozik, akkor a kulcstartó gazdagépnevét a hálózattól függően egy másik privát 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 virtuális hálózathoz van csatolva, és egy másik IP-címet használ a A rekordban.

Speciálisabb esetekben a virtuális hálózatok esetében engedélyezve lehet a társviszony-létesítés. Ebben az esetben csak egy virtuális hálózatnak 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 zónaerőforráshoz. Ezt a forgatókönyvet nem fedi le közvetlenül ez a dokumentum.

Ismerje meg, hogy ön szabályozhatja a DNS-feloldásokat

Az előző szakaszban leírtak szerint a privát hivatkozásokat tartalmazó kulcstartóban az alias {vaultname}.privatelink.vaultcore.azure.net szerepel a nyilvános regisztrációban. A virtuális hálózat á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 egyet, a nyilvános regisztráció során definiált aliasokat nem fogja követni.

Ez a logika azt jelenti, hogy ha a virtuális hálózat egy névvel rendelkező privatelink.vaultcore.azure.netsaját DNS zónához van csatolva, és a kulcstartó nyilvános DNS-regisztrációja aliassal fabrikam.privatelink.vaultcore.azure.net rendelkezik (vegye figyelembe, hogy a kulcstartó gazdagépneve utótagja pontosan megegyezik a saját DNS Zóna nevével), akkor a DNS-lekérdezés a A saját DNS zónában névvel fabrikam rendelkező rekordot keres. Ha a A rekord megtalálható, annak IP-címét adja vissza a DNS-lekérdezés, és a rendszer 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 hivatkozások nélkül kell hozzáférnie egy kulcstartóhoz. Ebben az esetben a gazdagépnév virtuális hálózatból 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 az privatelink aliassal 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, ahogyan azt a Key Vault szolgáltatás látja. A végpontot a következő paranccsal hívhatja meg (ne felejtse el használni a kulcstartó gazdagépnevé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 a következőket tartalmazza 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

Ha nem ehhez hasonló kimenetet kap, vagy hálózati hiba jelenik meg, az azt jelenti, hogy a kulcstartó nem érhető el a megadott gazdagépnéven keresztül (fabrikam.vault.azure.net a példában). Vagy a gazdagépné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, csomagelesés é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árható eredménye.
  • Más privát IP-cím, nem a kérést végző gépről. Ez azt jelzi, hogy egyes egyéni útválasztások hatékonyak. 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) a gazdagépnév nem oldódik fel a kulcstartó privát IP-címére. Ez a cikk mindkét esetben hibaelhárítási műveleteket tartalmaz.

Feljegyzés

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

A kulcstartó IP-címének lekérdezése közvetlenül

Fontos

A key vault 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érleteknek van kitéve, amelyek nem jelennek meg, ha gyakran letiltja a HTTPS-tanúsítványok érvényesítését a Key Vaultra irányuló kéréseiben.

Ha a PowerShell legújabb verzióját telepítette, kihagyhatja -SkipCertificateCheck 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 használja curl, ugyanezt megteheti az -k argumentummal:

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égpontot nem érdekli, ha a kulcstartó gazdagépnevét vagy IP-címét használja.

Ha egy értéket ad x-ms-keyvault-network-info vissza a kéréshez a key vault gazdagépnévvel, és egy másik értéket 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, hogy eldöntse, melyik eset helytelen, é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 fejlett hálózati ismeretekkel kell rendelkeznie.

Egyéni DNS-kiszolgálók diagnosztizálása a Virtuális hálózaton

A portálon nyissa meg a virtuális hálózati erőforrást. A bal oldali menüben nyissa meg a DNS-kiszolgálókat. Ha "Egyéni" beállítást használ, akkor előfordulhat, hogy a DNS-feloldás nem a jelen dokumentumban leírtak szerint történik. Meg kell diagnosztizálnia, hogy a DNS-kiszolgálók hogyan oldják fel a kulcstartó gazdagépnevét.

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

A virtuális gépen felülíró vagy egyéni DNS-kiszolgálókat futtató gazdagépek diagnosztizálása

Számos operációs rendszer lehetővé teszi a gazdagépnévként kifejezett rögzített IP-cím beállítását, általában a hosts fájl módosításával. Emellett engedélyezhetik a DNS-kiszolgálók felülírását is. Ha a fenti 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ó promiscuous 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 speciális rendszergazdák felülírhatják a főtanúsítvány-hatóságokat (CA-kat), és telepíthetnek egy promiscuous proxyt az átjáróeszközökre, amelyek több gépet szolgálnak ki a hálózaton. Ezek a proxyk jelentős hatással lehetnek a biztonságra és a megbízhatóságra is. 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 speciális vagy összetett forgatókönyvekben található elemek nem teljes listája:

  • Tűzfalbeállítások, a virtuális hálózathoz csatlakoztatott Azure Firewall vagy a virtuális hálózaton 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.