Udostępnij za pośrednictwem

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 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ą 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ą 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 są widoczne niektóre żą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śla 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 ułatwia naprawianie 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 aplikacja systemu Azure Service, usłudze Azure Kubernetes Service (AKS) i podobnych innych. Ten przewodnik ma również zastosowanie do dostępu wykonywanych w internetowym interfejsie użytkownika witryny Azure Portal, w którym przeglądarka uzyskuje bezpośredni dostęp do 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ą

Ten przewodnik nie ma zastosowania do rozwiązań zarządzanych przez firmę Microsoft, gdzie magazyn kluczy jest uzyskiwany przez produkt platformy Azure, który istnieje niezależnie od sieci wirtualnej klienta. Przykładami takich scenariuszy są usługi Azure Storage lub Azure SQL skonfigurowane do szyfrowania magazynowanego, usługa Azure Event Hubs szyfruje dane przy użyciu kluczy dostarczonych przez klienta, usługa Azure Data Factory uzyskuje dostęp do poświadczeń usługi przechowywanych w magazynie kluczy, usługa Azure Pipelines pobiera wpisy tajne 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 usługi 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ę 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. 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 sieci wirtualnej, musisz utworzyć nowy prywatny punkt końcowy. Zostanie to omówione później.
  4. Nadal w obszarze Połączenia prywatnego punktu końcowego znajdź diagnozę i upewnij się, że "Stan połączenia" jest zatwierdzony , a stan "Aprowizacja" to Powodzenie.
    • Jeśli połączenie ma stan "Oczekiwanie", może być możliwe jego zatwierdzenie.
    • Jeśli połączenie "Odrzucone", "Niepowodzenie", "Błąd", "Rozłączone" lub inny stan, nie jest to w ogóle skuteczne, 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 magazynu kluczy jest prawidłowo skonfigurowana

Ważne

Zmiana ustawień zapory może usunąć dostęp z legalnych klientów, którzy nadal nie korzystają z linków prywatnych. 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 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 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 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. 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 zarezerwowany. Aby łącza prywatne działały, nazwa hosta magazynu kluczy musi być rozpoznawana jako prywatny adres IP należący do przestrzeni adresowej sieci wirtualnej.

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ź diagnozę i upewnij się, że stan połączenia to Zatwierdzone , a stan aprowizacji to Powodzenie. Jeśli nie widzisz tego elementu, 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. Na stronie Przegląd może być wyświetlana sekcja 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 uruchomione w tej samej sieci wirtualnej 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 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

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:

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 i nie privatelink ma aliasu. Alias jest 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 siecią wirtualną, 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 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), znajdziesz następujące informacje:

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. 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 sieci wirtualnej (na przykład używanej) będą używać linków prywatnych — nie będą one używane. Widać, że z faktu, że nazwa hosta nadal jest rozpoznawana jako publiczny adres IP. Tylko maszyny połączone z siecią wirtualną mogą używać łączy 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. 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 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 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) powyżej.

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

6. Weryfikowanie strefy 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 i ta sekcja może pomóc. Jeśli rozpoznawanie nazw DNS pokazuje prawidłowy prywatny adres IP magazynu kluczy, Prywatna strefa DNS Strefa jest prawdopodobnie poprawna. Całą tę sekcję można pominąć.

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

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 strefą.

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 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 strefa Prywatna strefa DNS jest połączona z siecią wirtualną

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

Otwórz zasób strefy Prywatna strefa DNS i kliknij opcję Łącza sieci wirtualnej w menu po lewej stronie. Spowoduje to wyświetlenie listy łączy, z których każda ma nazwę sieci wirtualnej w ramach 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 strefy Prywatna strefa DNS z siecią wirtualną żądania DNS pochodzące z sieci wirtualnej będą szukać nazw w strefie Prywatna strefa DNS. Jest to wymagane do poprawnego rozpoznawania adresów wykonywanego na maszynach wirtualnych połączonych z siecią wirtualną, w której utworzono prywatny punkt końcowy.

Uwaga

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

Upewnij się, że strefa Prywatna strefa DNS zawiera odpowiedni 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 istnieć 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 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

Za każdym razem, gdy usuniesz lub zmodyfikujesz A rekord, maszyna nadal może rozpoznać stary adres IP, ponieważ wartość czasu wygaśnięcia (czas wygaśnięcia) może jeszcze nie 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ść, która jest zbyt duża, klienci mogą trwać zbyt długo, aby odzyskać dane 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 stref Prywatna strefa DNS, z których każda jest połączona z inną siecią wirtualną 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 jedna sieć wirtualna wymaga zasobu prywatnego punktu końcowego, chociaż oba mogą być połączone z zasobem strefy Prywatna strefa DNS. Ten scenariusz nie jest bezpośrednio opisany w tym dokumencie.

Zrozumienie, ż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 rejestracji publicznej . Serwer DNS używany przez sieć wirtualną używa rejestracji publicznej, ale sprawdza każdy alias dla rejestracji prywatnej , a jeśli zostanie znaleziony, przestanie obserwować aliasy zdefiniowane podczas rejestracji publicznej.

Ta logika oznacza, że jeśli sieć wirtualna jest połączona z strefą Prywatna strefa DNS o nazwie privatelink.vaultcore.azure.net, a publiczna rejestracja DNS w magazynie kluczy ma alias fabrikam.privatelink.vaultcore.azure.net (należy pamiętać, że sufiks nazwy hosta magazynu kluczy jest zgodny z nazwą strefy Prywatna strefa DNS), zapytanie DNS będzie wyszukiwać A rekord o nazwie fabrikam w Prywatna strefa DNS strefy. 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 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 sieci wirtualnej musi zwrócić publiczny adres IP i dzieje się tak, 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 /healthstatus punkt końcowy, który może służyć do diagnostyki. Nagłówki odpowiedzi zawierają adres IP pochodzenia, 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 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, a nie 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

Jeśli żądanie /healthstatus działa, 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.

Bezpośrednie wykonywanie zapytań dotyczących adresu 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 musi uzyskiwać dostępu do magazynu kluczy bez sprawdzania poprawności 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 najnowszą wersję programu PowerShell, możesz pominąć -SkipCertificateCheck kontrole certyfikatów HTTPS, a następnie bezpośrednio określić adres IP magazynu kluczy:

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

Jeśli używasz metody , możesz wykonać to samo za pomocą curlargumentu -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 cię, jeśli używasz nazwy hosta magazynu kluczy lub adresu IP.

Jeśli widzisz x-ms-keyvault-network-info zwracanie jednej wartości dla żądania przy użyciu nazwy hosta magazynu kluczy i innej wartości dla żądania przy użyciu adresu IP, każde żądanie jest przeznaczone dla 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 nieu wyczerpujące akcje badania. 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 polecenia "Niestandardowy", 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 hostów zastępowania 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ą 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.
  • 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.