Share via

Diagnozowanie problemów z konfiguracją linków prywatnych w usłudze Azure Key Vault

  • Artykuł

Wprowadzenie

Ten artykuł ułatwia użytkownikom diagnozowanie i rozwiązywanie problemów związanych z Key Vault i funkcją linków prywatnych. Ten przewodnik pomaga w aspektach konfiguracji, takich jak pierwsze działanie linków prywatnych lub naprawianie sytuacji, w której łącza prywatne przestały działać z powodu niektórych zmian.

Jeśli jesteś nowym użytkownikiem tej funkcji, zobacz Integracja Key Vault z Azure Private Link.

Problemy omówione w tym artykule

  • Zapytania DNS nadal zwracają publiczny adres IP magazynu kluczy, a nie prywatny adres IP, którego można oczekiwać od korzystania z funkcji linków prywatnych.
  • Wszystkie żądania wysyłane przez danego klienta korzystającego z łącza prywatnego kończą się niepowodzeniem z przekroczeniami limitu czasu lub błędami sieci, a problem nie jest sporadycznie.
  • Magazyn kluczy ma prywatny adres IP, ale żądania nadal otrzymują 403 odpowiedź z ForbiddenByFirewall wewnętrznym kodem błędu.
  • Używasz linków prywatnych, ale magazyn kluczy nadal akceptuje żądania z publicznego Internetu.
  • Magazyn kluczy ma dwa prywatne punkty końcowe. Żądania używające jednego działają prawidłowo, ale żądania używające drugiego kończą się niepowodzeniem.
  • Masz inną subskrypcję, magazyn kluczy lub sieć wirtualną, która korzysta z linków prywatnych. Chcesz utworzyć nowe podobne wdrożenie, ale nie możesz uzyskać linków prywatnych, aby tam pracować.

Problemy NIEuwzględniane w tym artykule

  • Występuje sporadyczne problemy z łącznością. W danym kliencie są widoczne pewne żądania działające, a niektóre nie działają. Sporadyczne problemy zwykle nie są spowodowane problemem w konfiguracji łączy prywatnych; są one oznaką przeciążenia sieci lub klienta.
  • Używasz produktu platformy Azure, który obsługuje usługę BYOK (Bring Your Own Key), CMK (klucze zarządzane przez klienta) lub dostęp do wpisów tajnych przechowywanych w magazynie kluczy. Po włączeniu zapory w ustawieniach magazynu kluczy ten produkt nie może uzyskać dostępu do magazynu kluczy. Zapoznaj się z dokumentacją specyficzną dla produktu. Upewnij się, że jawnie określono obsługę magazynów kluczy z włączoną zaporą. W razie potrzeby skontaktuj się z pomocą techniczną dla tego konkretnego produktu.

Jak przeczytać ten artykuł

Jeśli dopiero zaczynasz korzystać z linków prywatnych lub oceniasz złożone wdrożenie, zaleca się przeczytanie całego artykułu. W przeciwnym razie możesz wybrać sekcję, która ma większe znaczenie dla napotkanego problemu.

Zaczynamy!

1. Potwierdź, że jesteś właścicielem połączenia klienta

Upewnij się, że klient działa w sieci wirtualnej

Ten przewodnik ma pomóc w naprawianiu połączeń z magazynem kluczy pochodzącym z kodu aplikacji. Przykłady to aplikacje i skrypty wykonywane w usłudze Azure Virtual Machines, klastrach usługi Azure Service Fabric, Azure App Service, Azure Kubernetes Service (AKS) i podobnych innych. Ten przewodnik ma również zastosowanie do dostępu wykonywanych w interfejsie użytkownika Azure Portal web-base, w którym przeglądarka uzyskuje bezpośredni dostęp do magazynu kluczy.

Zgodnie z definicją linków prywatnych aplikacja, skrypt lub portal musi być uruchomiona na maszynie, klastrze lub środowisku połączonym z Virtual Network, w którym wdrożono zasób prywatnego punktu końcowego.

Jeśli aplikacja, skrypt lub portal jest uruchomiony w dowolnej sieci połączonej z Internetem, ten przewodnik nie ma zastosowania i prawdopodobnie nie można użyć linków prywatnych. To ograniczenie dotyczy również poleceń wykonywanych w usłudze Azure Cloud Shell, ponieważ są one uruchamiane na zdalnym komputerze platformy Azure udostępnianym na żądanie zamiast w przeglądarce użytkownika.

Jeśli używasz rozwiązania zarządzanego, zapoznaj się z konkretną dokumentacją

Ten przewodnik nie ma zastosowania do rozwiązań zarządzanych przez firmę Microsoft, gdzie dostęp do magazynu kluczy jest uzyskiwany przez produkt platformy Azure, który istnieje niezależnie od klienta Virtual Network. Przykładami takich scenariuszy są usługa Azure Storage lub Azure SQL skonfigurowana do szyfrowania danych magazynowanych, Azure Event Hubs szyfrowanie danych za pomocą kluczy dostarczonych przez klienta, Azure Data Factory uzyskiwanie dostępu do poświadczeń usługi przechowywanych w magazynie kluczy, pobieranie wpisów tajnych z magazynu kluczy i inne podobne scenariusze. W takich przypadkach należy sprawdzić, czy produkt obsługuje magazyny kluczy z włączoną zaporą. Ta obsługa jest zwykle wykonywana z funkcją zaufanych usług zapory Key Vault. Jednak wiele produktów nie znajduje się na liście zaufanych usług z różnych powodów. W takim przypadku skontaktuj się z pomocą techniczną specyficzną dla produktu.

Kilka produktów platformy Azure obsługuje koncepcję iniekcji sieci wirtualnej. W prosty sposób produkt dodaje urządzenie sieciowe do Virtual Network klienta, umożliwiając wysyłanie żądań tak, jakby zostało wdrożone na Virtual Network. Godnym uwagi przykładem jest usługa Azure Databricks. Takie produkty mogą wysyłać żądania do magazynu kluczy przy użyciu linków prywatnych, a ten przewodnik rozwiązywania problemów może pomóc.

2. Upewnij się, że połączenie zostało zatwierdzone i powiodło się

Poniższe kroki pozwalają sprawdzić, czy połączenie prywatnego punktu końcowego zostało zatwierdzone i jego nawiązanie powiodło się:

  1. Otwórz witrynę Azure Portal i otwórz zasób magazynu kluczy.
  2. W menu po lewej stronie wybierz pozycję Sieć.
  3. Wybierz kartę Połączenia z prywatnym punktem końcowym. Spowoduje to wyświetlenie wszystkich połączeń prywatnych punktów końcowych i ich stanów. Jeśli nie ma żadnych połączeń lub jeśli brakuje połączenia dla Virtual Network, musisz utworzyć nowy prywatny punkt końcowy. Zostanie to omówione później.
  4. Nadal w obszarze Połączenia prywatnego punktu końcowego znajdź ten, który diagnozujesz, i upewnij się, że stan połączenia to Zatwierdzone , a stan aprowizacji to Powodzenie.
    • Jeśli połączenie jest w stanie "Oczekiwanie", może być możliwe jego zatwierdzenie.
    • Jeśli połączenie "Odrzucone", "Niepowodzenie", "Błąd", "Rozłączone" lub inny stan, w ogóle nie jest skuteczne, należy utworzyć nowy zasób prywatnego punktu końcowego.

Dobrym pomysłem jest usunięcie nieskutecznych połączeń, aby zachować czystą elementy.

3. Upewnij się, że zapora magazynu kluczy jest prawidłowo skonfigurowana

Ważne

Zmiana ustawień zapory może usunąć dostęp z uprawnionych klientów, którzy nadal nie korzystają z linków prywatnych. Upewnij się, że wiesz o konsekwencjach każdej zmiany w konfiguracji zapory.

Ważne jest, że funkcja łączy prywatnych zapewnia dostęp tylko do magazynu kluczy w Virtual Network, który jest zamknięty, aby zapobiec eksfiltracji danych. Nie usuwa żadnego istniejącego dostępu. Aby skutecznie zablokować dostęp z publicznego Internetu, należy jawnie włączyć zaporę magazynu kluczy:

  1. Otwórz witrynę Azure Portal i otwórz zasób magazynu kluczy.
  2. W menu po lewej stronie wybierz pozycję Sieć.
  3. Upewnij się, że karta Zapory i sieci wirtualne jest zaznaczona u góry.
  4. Jeśli znajdziesz opcję Zezwalaj na dostęp publiczny ze wszystkich wybranych sieci , wyjaśnia to, dlaczego klienci zewnętrzni nadal mogą uzyskiwać dostęp do magazynu kluczy. Jeśli chcesz, aby Key Vault była dostępna tylko za pośrednictwem Private Link, wybierz pozycję Wyłącz dostęp publiczny.

Następujące instrukcje dotyczą również ustawień zapory:

  • Funkcja łączy prywatnych nie wymaga określenia żadnej "sieci wirtualnej" w ustawieniach zapory magazynu kluczy. Wszystkie żądania korzystające z prywatnego adresu IP magazynu kluczy (zobacz następną sekcję) muszą działać, nawet jeśli w ustawieniach zapory magazynu kluczy nie określono żadnej sieci wirtualnej.
  • Funkcja łączy prywatnych nie wymaga określenia żadnego adresu IP w ustawieniach zapory magazynu kluczy. Ponownie wszystkie żądania używające prywatnego adresu IP magazynu kluczy muszą działać, nawet jeśli w ustawieniach zapory nie określono żadnego adresu IP.

Jeśli używasz linków prywatnych, jedynymi motywacjami do określenia sieci wirtualnej lub adresu IP w zaporze magazynu kluczy są:

  • Masz system hybrydowy, w którym niektórzy klienci używają linków prywatnych, niektóre używają punktów końcowych usługi, a niektóre używają publicznego adresu IP.
  • Przechodzisz do linków prywatnych. W takim przypadku po potwierdzeniu, że wszyscy klienci używają linków prywatnych, należy usunąć sieci wirtualne i adresy IP z ustawień zapory magazynu kluczy.

4. Upewnij się, że magazyn kluczy ma prywatny adres IP

Różnica między prywatnymi i publicznymi adresami IP

Prywatny adres IP ma zawsze jeden z następujących formatów:

  • 10.x.x.x: Przykłady: 10.1.2.3, 10.56.34.12.
  • 172.16.x.x do 172.32.x.x: Przykłady: 172.20.1.1, 172.31.67.89.
  • 192.168.x.x: Przykłady: 192.168.0.1, 192.168.100.7

Niektóre adresy IP i zakresy są zarezerwowane:

  • 224.x.x.x: Multiemisji
  • 255.255.255.255: Emisja
  • 127.x.x.x: sprzężenia zwrotnego
  • 169.254.x.x: Link-local
  • 168.63.129.16: Wewnętrzny system DNS

Wszystkie inne adresy IP są publiczne.

Podczas przeglądania portalu lub uruchamiania polecenia, które wyświetla adres IP, upewnij się, że można określić, czy ten adres IP jest prywatny, publiczny lub zastrzeżony. Aby linki prywatne działały, nazwa hosta magazynu kluczy musi zostać rozpoznana jako prywatny adres IP należący do przestrzeni adresowej Virtual Network.

Znajdowanie prywatnego adresu IP magazynu kluczy w sieci wirtualnej

Musisz zdiagnozować rozpoznawanie nazw hostów, a w tym celu musisz znać dokładny prywatny adres IP magazynu kluczy z włączonymi linkami prywatnymi. Aby znaleźć ten adres, wykonaj następującą procedurę:

  1. Otwórz witrynę Azure Portal i otwórz zasób magazynu kluczy.
  2. W menu po lewej stronie wybierz pozycję Sieć.
  3. Wybierz kartę Połączenia z prywatnym punktem końcowym. Spowoduje to wyświetlenie wszystkich połączeń prywatnych punktów końcowych i ich stanów.
  4. Znajdź tę, którą diagnozujesz i upewnij się, że stan połączenia to Zatwierdzone , a stan aprowizacji to Powodzenie. Jeśli to nie widzisz, wróć do poprzednich sekcji tego dokumentu.
  5. Po znalezieniu odpowiedniego elementu kliknij link w kolumnie Prywatny punkt końcowy. Spowoduje to otwarcie zasobu prywatnego punktu końcowego.
  6. Strona Przegląd może zawierać sekcję o nazwie Niestandardowe ustawienia DNS. Upewnij się, że istnieje tylko jeden wpis zgodny z nazwą hosta magazynu kluczy. Ten wpis zawiera prywatny adres IP magazynu kluczy.
  7. Możesz również kliknąć link w interfejsie sieciowym i potwierdzić, że prywatny adres IP jest taki sam jak w poprzednim kroku. Interfejs sieciowy to urządzenie wirtualne reprezentujące magazyn kluczy.

Adres IP to ten, który maszyny wirtualne i inne urządzenia działające w tym samym Virtual Network będą używane do nawiązywania połączenia z magazynem kluczy. Zanotuj adres IP lub pozostaw otwartą kartę przeglądarki i nie dotykaj jej podczas dalszych badań.

Uwaga

Jeśli magazyn kluczy ma wiele prywatnych punktów końcowych, ma wiele prywatnych adresów IP. Jest to przydatne tylko wtedy, gdy masz wiele sieci wirtualnych, które uzyskują dostęp do tego samego magazynu kluczy, każdy za pośrednictwem własnego prywatnego punktu końcowego (prywatny punkt końcowy należy do jednego Virtual Network). Upewnij się, że zdiagnozowano problem dla poprawnego Virtual Network i wybierz prawidłowe połączenie prywatnego punktu końcowego w powyższej procedurze. Ponadto nie należy tworzyć wielu prywatnych punktów końcowych dla tego samego Key Vault w tym samym Virtual Network. Nie jest to potrzebne i bywa źródłem nieporozumień.

5. Zweryfikuj rozpoznawanie nazw DNS

Rozpoznawanie nazw DNS to proces tłumaczenia nazwy hosta magazynu kluczy (na przykład: fabrikam.vault.azure.net) na adres IP (na przykład: 10.1.2.3). W poniższych podsekcjach przedstawiono oczekiwane wyniki rozpoznawania nazw DNS w każdym scenariuszu.

Ta sekcja jest przeznaczona do celów szkoleniowych. Jeśli magazyn kluczy nie ma połączenia prywatnego punktu końcowego w stanie zatwierdzonym, rozpoznawanie nazwy hosta daje wynik podobny do następującego:

W systemie 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

W systemie 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

Widać, że nazwa jest rozpoznawana jako publiczny adres IP i nie privatelink ma aliasu. Alias zostanie wyjaśniony później, nie martw się o to teraz.

Powyższy wynik jest oczekiwany niezależnie od tego, czy maszyna jest połączona z Virtual Network, czy dowolną maszyną z połączeniem internetowym. Dzieje się tak, ponieważ magazyn kluczy nie ma połączenia prywatnego punktu końcowego w stanie zatwierdzonym, dlatego nie ma potrzeby obsługi łączy prywatnych w magazynie kluczy.

Gdy magazyn kluczy ma co najmniej jedno połączenie prywatnego punktu końcowego w stanie zatwierdzonym i rozpoznasz nazwę hosta z dowolnej maszyny połączonej z Internetem (maszyna, która nie jest połączona z Virtual Network, gdzie znajduje się prywatny punkt końcowy), znajdziesz następujące informacje:

W systemie 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

W systemie 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

Godną uwagi różnicą w poprzednim scenariuszu jest to, że istnieje nowy alias z wartością {vaultname}.privatelink.vaultcore.azure.net. Oznacza to, że płaszczyzna danych magazynu kluczy jest gotowa do akceptowania żądań z linków prywatnych.

Nie oznacza to, że żądania wykonywane z maszyn spoza Virtual Network (podobnie jak użyte) będą używać linków prywatnych — nie będą. Widać, że z faktu, że nazwa hosta nadal jest rozpoznawana jako publiczny adres IP. Tylko maszyny połączone z Virtual Network mogą używać linków prywatnych. Więcej informacji na ten temat znajdziesz.

Jeśli alias nie jest widoczny privatelink , oznacza to, że magazyn kluczy ma zero prywatnych połączeń punktu końcowego w Approved stanie. Wstecz do tej sekcji przed ponowieniu próby.

Gdy magazyn kluczy ma co najmniej jedno połączenie prywatnego punktu końcowego w stanie zatwierdzonym i rozpoznasz nazwę hosta z maszyny połączonej z Virtual Network, w której utworzono prywatny punkt końcowy, jest to oczekiwana odpowiedź:

W systemie 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

W systemie 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

Istnieją dwie godne uwagi różnice. Najpierw nazwa jest rozpoznawana jako prywatny adres IP. Musi to być adres IP znaleziony w odpowiedniej sekcji tego artykułu. Po drugie, nie ma żadnych innych aliasów po privatelink tym. Dzieje się tak, ponieważ Virtual Network serwery DNS przechwytywać łańcuch aliasów i zwracać prywatny adres IP bezpośrednio z nazwy fabrikam.privatelink.vaultcore.azure.net. Ten wpis jest w rzeczywistości rekordem A w strefie Prywatna strefa DNS. Więcej informacji na ten temat znajdziesz.

Uwaga

Powyższy wynik występuje tylko na maszynie wirtualnej połączonej z Virtual Network, w której utworzono prywatny punkt końcowy. Jeśli nie masz maszyny wirtualnej wdrożonej w Virtual Network, która zawiera prywatny punkt końcowy, wdróż ją i połącz się zdalnie z nią, wykonaj nslookup polecenie (Windows) lub host powyższe polecenie (Linux).

Jeśli uruchomisz te polecenia na maszynie wirtualnej połączonej z Virtual Network, w której utworzono prywatny punkt końcowy, i nie są one wyświetlane prywatnego adresu IP magazynu kluczy, następna sekcja może pomóc w rozwiązaniu problemu.

6. Zweryfikuj strefę Prywatna strefa DNS

Jeśli rozpoznawanie nazw DNS nie działa zgodnie z opisem w poprzedniej sekcji, może wystąpić problem ze strefą Prywatna strefa DNS, a ta sekcja może pomóc. Jeśli rozpoznawanie nazw DNS pokazuje prawidłowy prywatny adres IP magazynu kluczy, prawdopodobnie jest prawidłowa strefa Prywatna strefa DNS. Całą tę sekcję można pominąć.

Upewnij się, że istnieje wymagany zasób strefy Prywatna strefa DNS

Twoja subskrypcja platformy Azure musi mieć zasób strefy Prywatna strefa DNS o tej dokładnej nazwie:

privatelink.vaultcore.azure.net

Możesz sprawdzić obecność tego zasobu, przechodząc do strony subskrypcji w portalu i wybierając pozycję "Zasoby" w menu po lewej stronie. Nazwa zasobu musi mieć privatelink.vaultcore.azure.netwartość , a typ zasobu musi być Prywatna strefa DNS strefie.

Zwykle ten zasób jest tworzony automatycznie podczas tworzenia prywatnego punktu końcowego przy użyciu typowej procedury. Istnieją jednak przypadki, w których ten zasób nie jest tworzony automatycznie i trzeba to zrobić ręcznie. Ten zasób mógł zostać również przypadkowo usunięty.

Jeśli nie masz tego zasobu, utwórz nowy zasób strefy Prywatna strefa DNS w ramach subskrypcji. Pamiętaj, że nazwa musi być dokładnie privatelink.vaultcore.azure.net, bez spacji lub dodatkowych kropek. Jeśli określisz nieprawidłową nazwę, rozpoznawanie nazw wyjaśnione w tym artykule nie będzie działać. Aby uzyskać więcej informacji na temat tworzenia tego zasobu, zobacz Tworzenie prywatnej strefy DNS platformy Azure przy użyciu Azure Portal. W przypadku korzystania z tej strony możesz pominąć tworzenie Virtual Network, ponieważ w tym momencie powinien być już jeden. Możesz również pominąć procedury weryfikacji za pomocą Virtual Machines.

Upewnij się, że strefa Prywatna strefa DNS jest połączona z Virtual Network

Nie wystarczy, aby mieć strefę Prywatna strefa DNS. Musi być również połączony z Virtual Network, który zawiera prywatny punkt końcowy. Jeśli strefa Prywatna strefa DNS nie jest połączona z poprawnym Virtual Network, wszelkie rozpoznawanie nazw DNS z tego Virtual Network zignoruje strefę Prywatna strefa DNS.

Otwórz zasób strefy Prywatna strefa DNS i kliknij opcję Linki sieci wirtualnej w menu po lewej stronie. Spowoduje to wyświetlenie listy łączy, z których każda ma nazwę Virtual Network w subskrypcji. Virtual Network, który zawiera zasób prywatnego punktu końcowego, musi być wymieniony tutaj. Jeśli nie jest tam, dodaj go. Aby uzyskać szczegółowe instrukcje, zobacz Łączenie sieci wirtualnej. Możesz pozostawić niezaznaczone pole wyboru "Włącz automatyczną rejestrację" — ta funkcja nie jest powiązana z linkami prywatnymi.

Po połączeniu strefy Prywatna strefa DNS z Virtual Network żądania DNS pochodzące z Virtual Network będą szukać nazw w strefie Prywatna strefa DNS. Jest to wymagane do poprawnego rozpoznawania adresów wykonywanego w Virtual Machines połączonym z Virtual Network, w którym utworzono prywatny punkt końcowy.

Uwaga

Jeśli właśnie zapisano link, może upłynąć trochę czasu, nawet po zakończeniu operacji przez portal. Może być również konieczne ponowne uruchomienie maszyny wirtualnej, której używasz do testowania rozpoznawania nazw DNS.

Upewnij się, że strefa Prywatna strefa DNS zawiera właściwy rekord A

Za pomocą portalu otwórz strefę Prywatna strefa DNS o nazwie privatelink.vaultcore.azure.net. Na stronie Przegląd są wyświetlane wszystkie rekordy. Domyślnie będzie jeden rekord o nazwie @ i typie SOA, co oznacza Początek urzędu. Nie dotykaj tego.

Aby rozpoznawanie nazw magazynu kluczy działało, musi istnieć A rekord z prostą nazwą magazynu bez sufiksu lub kropek. Jeśli na przykład nazwa hosta to fabrikam.vault.azure.net, musi istnieć A rekord o nazwie fabrikam, bez żadnych sufiksów lub kropek.

Ponadto wartość rekordu A (adresu IP) musi być prywatnym adresem IP magazynu kluczy. Jeśli znajdziesz A rekord, ale zawiera nieprawidłowy adres IP, musisz usunąć nieprawidłowy adres IP i dodać nowy. Zaleca się usunięcie całego A rekordu i dodanie nowego rekordu.

Uwaga

Za każdym razem, gdy usuniesz lub zmodyfikujesz A rekord, maszyna może nadal rozpoznać stary adres IP, ponieważ wartość czasu wygaśnięcia (czas wygaśnięcia) może nie zostać jeszcze wygasła. Zaleca się, aby zawsze określać wartość czasu wygaśnięcia nie mniejszą niż 10 sekund i nie większą niż 600 sekund (10 minut). Jeśli określisz wartość zbyt dużą, klienci mogą trwać zbyt długo, aby odzyskać dane po awarii.

Rozpoznawanie nazw DNS dla więcej niż jednego Virtual Network

Jeśli istnieje wiele sieci wirtualnych i każdy z nich ma własny zasób prywatnego punktu końcowego odwołującego się do tego samego magazynu kluczy, nazwa hosta magazynu kluczy musi rozpoznać inny prywatny adres IP w zależności od sieci. Oznacza to, że potrzebne są również wiele stref Prywatna strefa DNS, z których każdy jest połączony z innym Virtual Network i używając innego adresu IP w rekordzieA.

W bardziej zaawansowanych scenariuszach sieci wirtualne mogą mieć włączoną komunikację równorzędną. W takim przypadku tylko jeden Virtual Network potrzebuje zasobu prywatnego punktu końcowego, chociaż oba te elementy mogą być połączone z zasobem Prywatna strefa DNS Zone. Ten scenariusz nie jest bezpośrednio objęty tym dokumentem.

Dowiedz się, że masz kontrolę nad rozpoznawaniem nazw DNS

Jak wyjaśniono w poprzedniej sekcji, magazyn kluczy z linkami prywatnymi ma alias {vaultname}.privatelink.vaultcore.azure.net w swojej publicznej rejestracji. Serwer DNS używany przez Virtual Network używa rejestracji publicznej, ale sprawdza każdy alias dla rejestracji prywatnej, a jeśli zostanie znaleziony, zatrzyma się po aliasach zdefiniowanych podczas rejestracji publicznej.

Ta logika oznacza, że jeśli Virtual Network jest połączona z strefą Prywatna strefa DNS o nazwie , a publiczna rejestracja DNS magazynu kluczy ma alias fabrikam.privatelink.vaultcore.azure.net (należy pamiętać, że sufiks nazwy hosta magazynu kluczy jest zgodny z nazwą privatelink.vaultcore.azure.netstrefy Prywatna strefa DNS), zapytanie DNS będzie wyszukiwać A rekord o nazwie fabrikam w elemencie strefa Prywatna strefa DNS. A Jeśli rekord zostanie znaleziony, jego adres IP jest zwracany w zapytaniu DNS, a żadne dalsze wyszukiwanie nie jest wykonywane w publicznej rejestracji DNS.

Jak widać, rozpoznawanie nazw jest pod kontrolą. Uzasadnienie tego projektu to:

  • Może istnieć złożony scenariusz obejmujący niestandardowe serwery DNS i integrację z sieciami lokalnymi. W takim przypadku należy kontrolować sposób tłumaczenia nazw na adresy IP.
  • Może być konieczne uzyskanie dostępu do magazynu kluczy bez linków prywatnych. W takim przypadku rozpoznawanie nazwy hosta z Virtual Network musi zwrócić publiczny adres IP i dzieje się tak, ponieważ magazyny kluczy bez łączy prywatnych nie mają privatelink aliasu w rejestracji nazwy.

Wykonywanie zapytań względem /healthstatus punktu końcowego magazynu kluczy

Magazyn kluczy udostępnia /healthstatus punkt końcowy, który może być używany do diagnostyki. Nagłówki odpowiedzi zawierają źródłowy adres IP, jak widać w usłudze magazynu kluczy. Możesz wywołać ten punkt końcowy za pomocą następującego polecenia (pamiętaj, aby użyć nazwy hosta magazynu kluczy):

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 lub najnowsza wersja Windows 10, która obejmuje 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

Jeśli nie otrzymujesz danych wyjściowych podobnych do tych lub jeśli wystąpi błąd sieci, oznacza to, że magazyn kluczy nie jest dostępny za pośrednictwem podanej nazwy hosta (fabrikam.vault.azure.net w przykładzie). Nazwa hosta nie jest rozpoznawana jako poprawny adres IP lub występuje problem z łącznością w warstwie transportu. Może to być spowodowane problemami z routingiem, spadkami pakietów i innymi przyczynami. Musisz dokładniej zbadać problem.

Odpowiedź musi zawierać nagłówek x-ms-keyvault-network-info:

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

Pole addr w nagłówku x-ms-keyvault-network-info zawiera adres IP źródła żądania. Ten adres IP może być jednym z następujących elementów:

  • Prywatny adres IP maszyny wykonującej żądanie. Oznacza to, że żądanie korzysta z linków prywatnych lub punktów końcowych usługi. Jest to oczekiwany wynik dla linków prywatnych.
  • Inny prywatny adres IP, a nie z maszyny wykonującej żądanie. Oznacza to, że niektóre routing niestandardowy jest skuteczny. Nadal wskazuje, że żądanie korzysta z linków prywatnych lub punktów końcowych usługi.
  • Niektóre publiczne adresy IP. Oznacza to, że żądanie jest kierowane do Internetu za pośrednictwem urządzenia bramy (NAT). Oznacza to, że żądanie nie korzysta z linków prywatnych, a niektóre problemy należy rozwiązać. Typowe przyczyny tego stanu to 1) prywatny punkt końcowy nie jest zatwierdzony i zakończony powodzeniem; i 2) nazwa hosta nie jest rozpoznawana jako prywatny adres IP magazynu kluczy. Ten artykuł zawiera akcje rozwiązywania problemów w obu przypadkach.

Uwaga

Jeśli żądanie działa /healthstatus , ale x-ms-keyvault-network-info brakuje nagłówka, punkt końcowy prawdopodobnie nie jest obsługiwany przez magazyn kluczy. Ponieważ powyższe polecenia również weryfikują certyfikat HTTPS, brakujący nagłówek może być znakiem manipulowania.

Zapytanie dotyczące adresu IP magazynu kluczy bezpośrednio

Ważne

Uzyskiwanie dostępu do magazynu kluczy bez weryfikacji certyfikatu HTTPS jest niebezpieczne i może być używane tylko do celów szkoleniowych. Kod produkcyjny nigdy nie może uzyskać dostępu do magazynu kluczy bez weryfikacji po stronie klienta. Nawet jeśli po prostu diagnozujesz problemy, możesz podlegać próbom naruszenia, które nie zostaną ujawnione, jeśli często wyłączasz weryfikację certyfikatu HTTPS w żądaniach do magazynu kluczy.

Jeśli zainstalowano najnowszą wersję programu PowerShell, możesz pominąć -SkipCertificateCheck testy certyfikatów HTTPS, a następnie bezpośrednio wybrać adres IP magazynu kluczy :

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

Jeśli używasz metody curl, możesz wykonać to samo z argumentem -k :

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

Odpowiedzi muszą być takie same w poprzedniej sekcji, co oznacza, że musi zawierać x-ms-keyvault-network-info nagłówek o tej samej wartości. Punkt /healthstatus końcowy nie obchodzi, jeśli używasz nazwy hosta magazynu kluczy lub adresu IP.

Jeśli zostanie wyświetlona x-ms-keyvault-network-info wartość zwracająca jedną wartość żądania przy użyciu nazwy hosta magazynu kluczy, a inna wartość żądania przy użyciu adresu IP, każde żądanie dotyczy innego punktu końcowego. Zapoznaj się z wyjaśnieniem addr pola z x-ms-keyvault-network-info poprzedniej sekcji, aby zdecydować, który przypadek jest nieprawidłowy i należy go naprawić.

8. Inne zmiany i dostosowania, które powodują wpływ

Poniższe elementy to nie wyczerpujące akcje badania. Będą one informować, gdzie szukać dodatkowych problemów, ale musisz mieć zaawansowaną wiedzę na temat sieci, aby rozwiązać problemy w tych scenariuszach.

Diagnozowanie niestandardowych serwerów DNS w Virtual Network

W portalu otwórz zasób Virtual Network. W menu po lewej stronie otwórz serwery DNS. Jeśli używasz opcji "Niestandardowe", rozpoznawanie nazw DNS może nie być tak jak opisano w tym dokumencie. Musisz zdiagnozować sposób rozpoznawania nazwy hosta magazynu kluczy przez serwery DNS.

Jeśli używasz domyślnych serwerów DNS udostępnianych przez platformę Azure, ten cały dokument ma zastosowanie.

Diagnozowanie zastępowania hostów lub niestandardowych serwerów DNS na maszynie wirtualnej

Wiele systemów operacyjnych zezwala na ustawienie jawnego stałego adresu IP na nazwę hosta, zazwyczaj przez zmianę hosts pliku. Mogą również zezwalać na zastępowanie serwerów DNS. Jeśli używasz jednego z tych scenariuszy, przejdź do opcji diagnostyki specyficznej dla systemu.

Serwery proxy promiscuous (Fiddler itp.)

Z wyjątkiem jawnie zanotowanych opcji diagnostycznych w tym artykule działa tylko wtedy, gdy w środowisku nie ma promiskuicznego serwera proxy. Chociaż te serwery proxy są często instalowane wyłącznie na komputerze, który jest diagnozowany (Fiddler jest najbardziej typowym przykładem), zaawansowani administratorzy mogą zastąpić główne urzędy certyfikacji (CA) i zainstalować promiskualny serwer proxy na urządzeniach bramy, które obsługują wiele maszyn w sieci. Te serwery proxy mogą znacząco wpływać zarówno na bezpieczeństwo, jak i niezawodność. Firma Microsoft nie obsługuje konfiguracji korzystających z takich produktów.

Inne kwestie, które mogą mieć wpływ na łączność

Jest to niewyczerpująca lista elementów, które można znaleźć w zaawansowanych lub złożonych scenariuszach:

  • Ustawienia zapory , Azure Firewall połączone z Virtual Network lub niestandardowe rozwiązanie zapory wdrożone w Virtual Network lub na maszynie.
  • Komunikacja równorzędna sieci, która może mieć wpływ na używane serwery DNS i sposób kierowania ruchu.
  • Rozwiązania bramy niestandardowej (NAT), które mogą mieć wpływ na sposób kierowania ruchu, w tym ruch z zapytań DNS.