Udostępnij za pośrednictwem

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

Wprowadzenie

Ten artykuł ułatwia użytkownikom diagnozowanie i rozwiązywanie problemów związanych z usługą Key Vault i funkcją Łącza prywatne. Ten przewodnik pomaga w aspektach konfiguracji, takich jak uzyskiwanie linków prywatnych działających po raz pierwszy lub naprawianie sytuacji, w której linki prywatne przestały działać z powodu niektórych zmian.

Jeśli dopiero zaczynasz korzystać z tej funkcji, zobacz Integracja usługi Key Vault z usługą Azure Private Link.

Problemy omówione w tym artykule

  • Zapytania DNS nadal zwracają publiczny adres IP magazynu kluczy zamiast prywatnego adresu 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 występuje sporadycznie.
  • Magazyn kluczy ma prywatny adres IP, ale żądania nadal otrzymują odpowiedź 403 z wewnętrznym kodem błędu ForbiddenByFirewall.
  • 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ą korzystającą z linków prywatnych. Chcesz utworzyć nowe podobne wdrożenie, ale nie możesz uzyskać linków prywatnych, aby tam pracować.

Problemy NIEobjęte tym artykułem

  • Występuje sporadyczne problemy z łącznością. W danym kliencie niektóre żądania działają, a inne nie. Sporadyczne problemy są rzadko powodowane przez problem w konfiguracji łączy prywatnych; są one oznaką przeciążenia sieci lub klienta.
  • Używasz produktu platformy Azure, który obsługuje BYOK (Bring Your Own Key), CMK (klucze zarządzane przez klienta) lub dostęp do tajnych danych przechowywanych w skarbcu 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 wyraźnie wskazuje na wsparcie dla 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 na celu pomóc ci w naprawie połączeń z magazynem kluczy pochodzących z kodu aplikacji. Przykłady to aplikacje i skrypty wykonywane w usłudze Azure Virtual Machines, klastrach usługi Azure Service Fabric, usłudze Azure App Service, usłudze Azure Kubernetes Service (AKS) i innych podobnych. Ten przewodnik ma również zastosowanie do dostępów wykonywanych w internetowym interfejsie użytkownika portalu Azure, w którym przeglądarka uzyskuje bezpośredni dostęp do Twojego magazynu kluczy.

Zgodnie z definicją łączy prywatnych aplikacja, skrypt lub portal muszą być uruchomione na maszynie, klastrze lub środowisku połączonym z siecią wirtualną, w której 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ą 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ą

Zarządzane usługi platformy Azure wymagają innej konfiguracji

Ten przewodnik nie dotyczy usług zarządzanych przez firmę Microsoft, które uzyskują dostęp do usługi Key Vault spoza sieci wirtualnej. Takie scenariusze obejmują:

  • Usługa Azure Storage skonfigurowana z szyfrowaniem podczas przechowywania
  • Usługa Azure SQL korzystająca z kluczy zarządzanych przez klienta
  • Szyfrowanie danych za pomocą kluczy w usłudze Azure Event Hubs
  • Usługa Azure Data Factory uzyskuje dostęp do poświadczeń przechowywanych w usłudze Key Vault
  • Usługa Azure Pipelines pobiera tajne dane z usługi Azure Key Vault

W tych scenariuszach należy sprawdzić, czy określona usługa platformy Azure obsługuje dostęp do usługi Key Vault z włączonymi zaporami. Wiele usług używa funkcji Zaufane usługi , aby bezpiecznie uzyskać dostęp do usługi Key Vault pomimo ograniczeń zapory. Jednak nie wszystkie usługi platformy Azure są wyświetlane na liście zaufanych usług ze względu na różne przyczyny architektury.

Jeśli masz problemy z konkretną usługą platformy Azure, która uzyskuje dostęp do usługi Key Vault, zapoznaj się z dokumentacją tej usługi lub skontaktuj się z zespołem pomocy technicznej, aby uzyskać szczegółowe wskazówki.

Kilka produktów platformy Azure obsługuje koncepcję wstrzykiwania sieci wirtualnej. Mówiąc prosto, produkt dodaje urządzenie sieciowe do sieci wirtualnej klienta, umożliwiając wysyłanie żądań tak, jakby zostało wdrożone w sieci wirtualnej. Godnym uwagi przykładem jest usługa Azure Databricks. Produkty tego typu mogą wysyłać żądania do magazynu kluczy za pomocą prywatnych linków, a ten przewodnik rozwiązywania problemów może okazać się pomocny.

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 prywatnego punktu końcowego , aby wyświetlić wszystkie połączenia prywatnego punktu końcowego i ich odpowiednie stany. Jeśli nie ma żadnych połączeń lub jeśli brakuje połączenia dla sieci wirtualnej, musisz utworzyć nowy prywatny punkt końcowy. Zostanie to omówione później.
  4. Nadal w Połączenia prywatnego punktu końcowego, znajdź to, które diagnozujesz i upewnij się, że "Stan połączenia" jest Zatwierdzony i "Stan aprowizacji" to Pomyślnie zakończono.
    • Jeśli połączenie ma stan "Oczekiwanie", może być możliwe jego zatwierdzenie.
    • Jeśli połączenie ma stan "Odrzucone", "Niepowodzenie", "Błąd", "Rozłączone" lub inny, to połączenie nie jest w ogóle skuteczne i musisz utworzyć nowy zasób prywatnego punktu końcowego.

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

3. Upewnij się, że zapora skarbca kluczy jest odpowiednio skonfigurowana

Ważne

Zmiana ustawień zapory może odebrać dostęp uprawnionym klientom, którzy nadal nie korzystają z prywatnych łączy. Upewnij się, że znasz konsekwencje każdej zmiany konfiguracji zapory.

Ważne jest, że funkcja łączy prywatnych zapewnia dostęp tylko do magazynu kluczy w sieci wirtualnej, która jest zamknięta, 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 Azure Portal i otwórz zasób Key Vault.
  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 zostanie wybrana opcja Zezwalaj na dostęp publiczny ze wszystkich sieci , wyjaśnia to, dlaczego klienci zewnętrzni nadal mogą uzyskiwać dostęp do magazynu kluczy. Jeśli chcesz, aby usługa Key Vault była dostępna tylko za pośrednictwem usługi 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 korzystające z 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, niektóre używają publicznego adresu IP.
  • Przechodzisz do linków prywatnych. W takim przypadku, po potwierdzeniu, że wszyscy klienci korzystają z linków prywatnych, należy usunąć sieci wirtualne i adresy IP z ustawień zapory skrytki 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: Multicast
  • 255.255.255.255: Emisja
  • 127.x.x.x: Pętla zwrotna
  • 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 zarezerwowany. Aby prywatne łącza działały, nazwa hosta sejfu kluczy musi być rozpoznawana jako prywatny adres IP należący do przestrzeni adresowej sieci wirtualnej.

Znaleźć prywatny adres IP magazynu kluczy w sieci wirtualnej

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

  1. Otwórz portal Azure i otwórz swój zasób Key Vault.
  2. W menu po lewej stronie wybierz pozycję Sieć.
  3. Wybierz kartę Połączenia prywatnego punktu końcowego . Widok wynikowy przedstawia wszystkie połączenia prywatnego punktu końcowego i ich odpowiednie stany.
  4. Znajdź połączenie, które diagnozujesz, i upewnij się, że "Stan połączenia" to Zatwierdzone , a stan aprowizacji to Powodzenie. Jeśli stan się różni, wróć do poprzednich sekcji dokumentu.
  5. Po znalezieniu odpowiedniego elementu kliknij link w kolumnie Prywatny punkt końcowy . Akcja spowoduje otwarcie zasobu prywatnego punktu końcowego.
  6. Na stronie Przegląd może być wyświetlana sekcja o nazwie Niestandardowe ustawienia DNS. Upewnij się, że istnieje tylko jeden wpis pasujący do nazwy hosta sejfu kluczy. Ten wpis pokazuje prywatny adres IP skarbca kluczy.
  7. Możesz również wybrać 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 jest wykorzystywany przez maszyny wirtualne i inne urządzenia działające w tej samej sieci wirtualnej do łączenia się ze skrytką kluczy. Zanotuj adres IP lub pozostaw otwartą kartę przeglądarki i nie dotykaj jej podczas dalszych badań.

Uwaga / Notatka

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 jednej sieci wirtualnej). Upewnij się, że zdiagnozowano problem dla prawidłowej sieci wirtualnej, a następnie 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 magazynu kluczy w tej samej sieci wirtualnej. Nie jest to potrzebne i bywa źródłem nieporozumień.

5. Zweryfikuj rozpoznawanie nazw DNS

Rozwiązywanie nazw DNS to proces, w którym nazwa hosta magazynu kluczy (na przykład: fabrikam.vault.azure.net) jest tłumaczona 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 skarbiec kluczy nie ma połączenia z prywatnym punktem końcowym w stanie zatwierdzonym, rozpoznanie nazwy hosta prowadzi do wyniku podobnego do tego.

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

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

Ten wynik jest wyświetlany w taki sam sposób, czy uruchamiasz zapytanie z maszyny podłączonej do sieci wirtualnej, czy z dowolnego komputera z połączeniem internetowym. Wynik występuje, ponieważ magazyn kluczy nie ma prywatnych połączeń punktu końcowego w stanie zatwierdzonym, więc nie ma potrzeby obsługi łączy prywatnych przez magazyn kluczy.

Gdy magazyn kluczy ma co najmniej jedno połączenie prywatnego punktu końcowego w stanie zatwierdzonym i rozpoznasz nazwę hosta z dowolnej maszyny podłączonej do Internetu (maszyny, która nie jest połączona z siecią wirtualną, w której znajduje się prywatny punkt końcowy), otrzymasz wynik podobny do następującego:

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

Możliwą różnicą w porównaniu z poprzednim scenariuszem jest to, że istnieje nowy alias z wartością {vaultname}.privatelink.vaultcore.azure.net. Płaszczyzna danych magazynu kluczy jest gotowa do akceptowania żądań z prywatnych połączeń.

Nie oznacza to, że żądania wykonywane z maszyn spoza sieci wirtualnej (podobnie jak ta, której właśnie użyłeś) korzystają z prywatnych łączy — bo tak nie jest. To widać z faktu, że nazwa hosta nadal jest rozpoznawana jako publiczny adres IP. Tylko maszyny połączone z siecią wirtualną mogą używać łączy prywatnych.

Jeśli nie widzisz aliasu privatelink, oznacza to, że magazyn kluczy nie ma żadnych prywatnych połączeń punktu końcowego w stanie Approved. Wróć do tej sekcji przed ponowieniu próby.

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

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

Istnieją dwie istotne 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ż serwery DNS sieci wirtualnej przechwytują łańcuch aliasów i zwracają prywatny adres IP bezpośrednio z nazwy. Ten wpis jest w rzeczywistości rekordem A w prywatnej strefie DNS.

Uwaga / Notatka

Ten wynik występuje tylko na maszynie wirtualnej połączonej z siecią wirtualną, w której utworzono prywatny punkt końcowy. Jeśli nie masz maszyny wirtualnej wdrożonej w sieci wirtualnej zawierającej prywatny punkt końcowy, wdróż go i połącz się zdalnie z nią, wykonaj nslookup polecenie (Windows) lub host polecenie (Linux).

Jeśli uruchomisz te polecenia na maszynie wirtualnej połączonej z siecią wirtualną, w której utworzono prywatny punkt końcowy, i nie wyświetlają one prywatnego adresu IP Key Vault, następna sekcja może pomóc rozwiązać ten problem.

Zweryfikuj prywatną strefę DNS

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

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

Subskrypcja platformy Azure musi mieć zasób prywatnej strefy 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 być privatelink.vaultcore.azure.net, a typ zasobu musi być Prywatna strefa DNS.

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 Prywatnej strefy 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ę, rozwiązanie nazwy wyjaśnione w tym artykule zakończy się niepowodzeniem. Aby uzyskać więcej informacji na temat tworzenia tego zasobu, zobacz Tworzenie prywatnej strefy DNS platformy Azure przy użyciu witryny Azure Portal. Jeśli korzystasz z tej strony, możesz pominąć tworzenie sieci wirtualnej, ponieważ w tym momencie powinna być już utworzona sieć wirtualna. Procedury weryfikacji można również pominąć za pomocą usługi Virtual Machines.

Upewnij się, że prywatna strefa DNS jest połączona z siecią wirtualną

Nie wystarczy mieć prywatną strefę DNS. Musi być również połączony z siecią wirtualną zawierającą prywatny punkt końcowy. Jeśli prywatna strefa DNS nie jest połączona z poprawną siecią wirtualną, każde rozpoznawanie nazw DNS z tej sieci wirtualnej zignoruje prywatną strefę DNS.

Otwórz zasób Prywatnej strefy DNS i wybierz opcję Łącza sieci wirtualnej w menu po lewej stronie. Zostanie wyświetlona lista łączy, z których każda ma nazwę sieci wirtualnej w subskrypcji. Sieć wirtualna zawierająca zasób prywatnego punktu końcowego musi być wymieniona tutaj. Jeśli tak nie jest, dodaj ją. 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 prywatnej strefy DNS z siecią wirtualną wszystkie żądania DNS pochodzące z tej sieci będą automatycznie sprawdzać tę strefę prywatną pod kątem rozpoznawania nazw. To połączenie jest niezbędne dla maszyn wirtualnych w tej samej sieci wirtualnej co prywatny punkt końcowy, aby poprawnie rozwiązać nazwę hosta usługi Azure Key Vault na jego prywatny adres IP, zamiast na publiczny adres.

Uwaga / Notatka

Jeśli link został dopiero co zapisany, może upłynąć trochę czasu, zanim zmiana wejdzie w życie, nawet po tym, jak Portal poinformuje o zakończeniu operacji. Może być również konieczne ponowne uruchomienie maszyny wirtualnej używanej do testowania rozpoznawania nazw DNS.

Upewnij się, że Prywatna strefa DNS zawiera odpowiedni rekord A

Za pomocą Portalu otwórz Prywatną strefę DNS o nazwie privatelink.vaultcore.azure.net. Na stronie Przegląd są wyświetlane wszystkie rekordy. Domyślnie istnieje jeden rekord o nazwie @ i typie SOA, co oznacza Początek autorytetu (SOA). Nie dotykaj tego.

Aby rozwiązanie nazw magazynu kluczy działało, musi istnieć rekord A z prostą nazwą magazynu, bez sufiksu ani 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 rekord, A 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.

Uwaga / Notatka

Za każdym razem, gdy usuniesz lub zmodyfikujesz A rekord, maszyna nadal może rozpoznać stary adres IP, ponieważ wartość TTL (Time To Live) może jeszcze nie wygasnąć. 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ść, która jest zbyt duża, klientom może zająć zbyt dużo czasu na powrót do działania po awarii.

Rozpoznawanie nazw DNS dla więcej niż jednej sieci wirtualnej

Jeśli istnieje wiele sieci wirtualnych, z których każdy ma własny zasób prywatnego punktu końcowego odwołującego się do tego samego magazynu kluczy, nazwa hosta magazynu kluczy musi być rozpoznawana jako inny prywatny adres IP w zależności od sieci. Oznacza to, że potrzebne są również wiele prywatnych stref DNS, z których każda jest połączona z inną siecią wirtualną i używająca innego adresu IP w rekordzie A.

W bardziej zaawansowanych scenariuszach sieci wirtualne mogą mieć włączone peering. W takim przypadku tylko jedna sieć wirtualna wymaga prywatnego punktu końcowego, chociaż obie mogą wymagać połączenia z zasobem strefy prywatnej DNS. Ten scenariusz nie jest bezpośrednio opisany w tym dokumencie.

Zrozum, że masz kontrolę nad rozpoznawaniem nazw DNS

W poprzedniej sekcji wyjaśniono, że magazyn kluczy z prywatnymi łączami ma alias {vaultname}.privatelink.vaultcore.azure.net w publicznej rejestracji. Serwer DNS używany przez sieć wirtualną korzysta z rejestracji publicznej, ale sprawdza, czy dla każdego aliasu istnieje rejestracja prywatna, a jeśli taką znajdzie, przestaje śledzić aliasy zdefiniowane w rejestracji publicznej.

Ta logika oznacza, że jeśli sieć wirtualna jest połączona z prywatną strefą DNS o nazwie privatelink.vaultcore.azure.net, a publiczna rejestracja DNS dla magazynu kluczy ma alias fabrikam.privatelink.vaultcore.azure.net (należy pamiętać, że sufiks nazwy hosta magazynu kluczy pasuje dokładnie do nazwy prywatnej strefy DNS), zapytanie DNS szuka A rekordu o nazwie fabrikamw prywatnej strefie DNS. A Jeśli rekord zostanie znaleziony, jego adres IP zostanie zwrócony w zapytaniu DNS i nie zostanie wykonane dalsze wyszukiwanie w publicznej rejestracji DNS.

Jak widać, rozpoznawanie nazw jest pod Twoją kontrolą. Uzasadnieniem tego projektu jest:

  • 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 prywatnych połączeń. W takim przypadku rozpoznawanie nazwy hosta z sieci wirtualnej musi zwrócić publiczny adres IP, ponieważ magazyny kluczy bez linków prywatnych nie mają privatelink aliasu w rejestracji nazw.

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

Magazyn kluczy udostępnia punkt końcowy /healthstatus, który może być używany do diagnostyki. Nagłówki odpowiedzi zawierają adres IP pochodzenia, widziany przez usługę Key Vault. 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 systemu 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 prawidłowy adres IP lub występuje problem z łącznością w warstwie transportu. Może to być spowodowane problemami z routingiem, porzuceniem pakietu 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 łączy prywatnych.
  • Inny prywatny adres IP, który nie pochodzi z maszyny wykonującej żądanie. Oznacza to, że niektóre routingi niestandardowe są skuteczne. 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 problemu to 1) prywatny punkt końcowy nie jest w stanie zatwierdzonym i zakończonym 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 / Notatka

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

Bezpośrednie zapytanie o adres IP magazynu kluczy

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 powinien uzyskiwać 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łączysz walidację certyfikatu HTTPS w żądaniach do magazynu kluczy.

Jeśli zainstalowano nowszą wersję programu PowerShell, możesz pominąć -SkipCertificateCheck kontrole certyfikatów HTTPS, a następnie przechodzić bezpośrednio do adresu IP magazynu kluczy:

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

Jeśli używasz curl, możesz wykonać to samo za pomocą argumentu -k.

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

Odpowiedzi muszą być takie same jak 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, czy używasz nazwy hosta usługi Key Vault lub adresu IP.

Jeśli widzisz x-ms-keyvault-network-info zwraca jedną wartość dla żądania z użyciem nazwy hosta magazynu kluczy, a inną wartość dla żądania z użyciem adresu IP, to każde żądanie kierowane jest do 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 są niewyczerpujące czynności dochodzeniowe. Poinformują Cię, 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 usłudze Virtual Network

W Portalu otwórz zasób Sieć Wirtualna. W menu po lewej stronie otwórz serwery DNS. Jeśli używasz opcji "Niestandardowy", rozpoznawanie nazw DNS może nie być zgodne z opisem w tym dokumencie. Musisz zdiagnozować, w jaki sposób serwery DNS rozpoznają nazwę hosta magazynu kluczy.

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

Diagnozowanie hostów z nadpisywanymi lub niestandardowymi serwerami 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ą one również zezwalać na zastępowanie serwerów DNS. Jeśli używasz jednego z tych scenariuszy, przejdź do opcji diagnostyki specyficznych dla systemu.

Promiscuous proxy (Fiddler itp.)

Z wyjątkiem sytuacji, gdy jawnie zaznaczono, opcje diagnostyki w tym artykule działają 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ć promiscyjny 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 elementy, 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 — usługa Azure Firewall połączona z siecią wirtualną lub niestandardowe rozwiązanie zapory wdrożone w sieci wirtualnej lub na maszynie.
  • Peering sieciowy, który 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.