Wdrażanie wystąpienia Azure API Management w sieci wirtualnej — tryb wewnętrzny

DOTYCZY: Developer | Premium

Azure API Management można wdrożyć (wstrzykiwać) wewnątrz sieci wirtualnej Azure w celu uzyskania dostępu do usług zaplecza w sieci. Aby zapoznać się z opcjami, wymaganiami i zagadnieniami dotyczącymi łączności z siecią wirtualną, zobacz:

• Za pomocą sieci wirtualnej z Azure API Management
• Wymagania dotyczące zasobów sieciowych dotyczące wstrzykiwania usługi API Management do sieci wirtualnej

W tym artykule wyjaśniono, jak skonfigurować łączność sieci wirtualnej dla wystąpienia usługi API Management w trybie wewnętrznym . W tym trybie można uzyskać dostęp tylko do następujących punktów końcowych usługi API Management w sieci wirtualnej, której dostęp kontrolujesz.

• Brama interfejsu API
• Portal dla deweloperów
• Zarządzanie bezpośrednie
• Git

Uwaga

• Żaden z punktów końcowych usługi API Management nie jest zarejestrowany w publicznym systemie DNS. Punkty końcowe pozostają niedostępne do momentu skonfigurowania systemu DNS dla sieci wirtualnej.
• Aby użyć bramy z własnym hostingiem w tym trybie, włącz prywatną łączność również z punktem końcowym konfiguracji bramy z własnym hostingiem.

Użyj usługi API Management w trybie wewnętrznym, aby:

• Aby interfejsy API w prywatnym centrum danych były bezpiecznie dostępne dla podmiotów zewnętrznych, wykorzystaj połączenia VPN Azure lub Azure ExpressRoute.
• Włącz scenariusze chmury hybrydowej, uwidaczniając interfejsy API oparte na chmurze i lokalne interfejsy API za pośrednictwem wspólnej bramy.
• Zarządzaj API hostowanymi w wielu lokalizacjach geograficznych za pomocą pojedynczego punktu końcowego bramy.

W przypadku konfiguracji specyficznych dla trybu zewnętrznego, w którym punkty końcowe API Management są dostępne z publicznego internetu, a usługi zaplecza znajdują się w sieci, zobacz Wdróż wystąpienie Azure API Management do sieci wirtualnej — tryb zewnętrzny.

Uwaga

Zalecamy użycie modułu Azure Az programu PowerShell do interakcji z Azure. Aby rozpocząć, zobacz Install Azure PowerShell. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az programu PowerShell, zobacz Migrate Azure PowerShell z modułu AzureRM do modułu Az.

Ważne

Zmiany w infrastrukturze usługi API Management (takie jak konfigurowanie domen niestandardowych, dodawanie certyfikatów urzędu certyfikacji, skalowanie, konfiguracja sieci wirtualnej, zmiany strefy dostępności i dodawanie regionów) mogą potrwać 15 minut lub dłużej, w zależności od warstwy usługi i rozmiaru wdrożenia. Oczekuj dłuższych czasów przetwarzania dla instancji z większą liczbą jednostek skalowania lub konfiguracji wieloregionalnej (z bramami w wielu lokalizacjach). Zmiany etapowe w usłudze API Management są wykonywane ostrożnie, aby zachować pojemność i dostępność.

Podczas aktualizowania usługi nie można wprowadzać innych zmian infrastruktury usług. Można jednak skonfigurować interfejsy API, produkty, zasady i ustawienia użytkownika. Usługa nie doświadczy przestoju bramy, a zarządzanie interfejsem API będzie nadal obsługiwać żądania bez przerwy (z wyjątkiem poziomu Deweloper).

Wymagania wstępne

Przed rozpoczęciem zapoznaj się z wymaganiami dotyczącymi zasobów sieciowych pod kątem wstrzykiwania usługi API Management do sieci wirtualnej .

• Instancja API Management. Aby uzyskać więcej informacji, przejdź do Tworzenie wystąpienia usługi Azure API Management.

• Sieć wirtualna i podsieć w tym samym regionie i subskrypcji co instancja API Management.

  • Podsieć używana do nawiązywania połączenia z wystąpieniem usługi API Management może zawierać inne typy zasobów Azure.
  • Podsieć nie powinna mieć włączonego delegowania. Ustawienie Delegowanie podsieci do usługi powinno być ustawione na Brak.

• Sieciowa grupa zabezpieczeń dołączona do powyższej podsieci. Sieciowa grupa zabezpieczeń jest wymagana do jawnego zezwalania na łączność przychodzącą, ponieważ moduł równoważenia obciążenia używany wewnętrznie przez usługę API Management jest domyślnie bezpieczny i odrzuca cały ruch przychodzący. W celu uzyskania szczegółowej konfiguracji, zobacz Konfigurowanie reguł sieciowej grupy zabezpieczeń w późniejszej części artykułu.

• W przypadku niektórych scenariuszy włącz punkty końcowe usługi service w podsieci do usług zależnych, takich jak Azure Storage lub Azure SQL. Aby uzyskać więcej informacji, zobacz Wymuszanie tunelowania ruchu do zapory lokalnej przy użyciu usługi ExpressRoute lub wirtualnego urządzenia sieciowego w dalszej części tego artykułu.

• (Opcjonalnie) adres IPv4 publiczny SKU Standard.

  Ważne

  • Od maja 2024 r. zasób publicznego adresu IP nie jest już potrzebny podczas wdrażania (wstrzykiwania) wystąpienia usługi API Management w sieci wirtualnej w trybie wewnętrznym lub migrowania wewnętrznej konfiguracji sieci wirtualnej do nowej podsieci. W trybie zewnętrznej sieci wirtualnej określenie publicznego adresu IP to optional; Jeśli go nie podasz, publiczny adres IP zarządzany przez Azure jest automatycznie konfigurowany i używany do ruchu interfejsu API środowiska uruchomieniowego. Podaj tylko publiczny adres IP, jeśli chcesz być właścicielem i kontrolować publiczny adres IP używany do komunikacji przychodzącej lub wychodzącej z Internetem.

  • Jeśli zostanie podany, adres IP musi znajdować się w tym samym regionie i subskrypcji co wystąpienie usługi API Management i sieć wirtualna.

  • Podczas tworzenia zasobu publicznego adresu IP upewnij się, że przypiszesz do niego etykietę nazwy DNS. Ogólnie rzecz biorąc, należy użyć tej samej nazwy DNS co wystąpienie usługi API Management. W przypadku zmiany ponownie wdróż wystąpienie, aby nowa etykieta DNS była stosowana.

  • Aby uzyskać najlepszą wydajność sieci, zaleca się użycie domyślnej preferencji Routing: Microsoft sieci.

  • Podczas tworzenia publicznego adresu IP w regionie, w którym planujesz włączyć nadmiarowość strefową dla wystąpienia usługi API Management, skonfiguruj ustawienie "Strefowo nadmiarowe".

  • Wartość adresu IP jest przypisywana jako wirtualny publiczny adres IPv4 wystąpienia usługi API Management w tym regionie.

• W przypadku wdrożeń usługi API Management w wielu regionach skonfiguruj zasoby sieci wirtualnej oddzielnie dla każdej lokalizacji.

Włączanie połączenia z siecią wirtualną

Włącz łączność z siecią VNet przy użyciu portalu Azure

1. Przejdź do portalu Azure aby znaleźć wystąpienie usługi API Management. Wyszukaj i wybierz Usługi zarządzania API.
2. Wybierz wystąpienie usługi API Management.
3. Wybierz pozycję Sieć wirtualna>.
4. Wybierz typ dostępu wewnętrznego.
5. Na liście lokalizacji (regionów), w których aprowizowana jest usługa API Management:
   1. Wybierz lokalizację.
   2. Wybierz pozycję Sieć wirtualna i Podsieć.
      • Lista sieci wirtualnych jest wypełniana Resource Manager sieciami wirtualnymi dostępnymi w subskrypcjach Azure, skonfigurowanym w skonfigurowanym regionie.
6. Wybierz Zastosuj. Strona Sieć wirtualna dla Twojego wystąpienia usługi API Management została zaktualizowana zgodnie z wybranymi przez Ciebie opcjami sieci VNet i podsieci.
7. Kontynuuj konfigurowanie ustawień sieci wirtualnej dla pozostałych lokalizacji wystąpienia usługi API Management.
8. Na górnym pasku nawigacyjnym wybierz pozycję Zapisz.

Po pomyślnym wdrożeniu w bloku Przegląd powinien zostać wyświetlony prywatny wirtualny adres IP usługi API Management i publiczny wirtualny adres IP. Aby uzyskać więcej informacji na temat adresów IP, zobacz Routing w tym artykule.

Uwaga

Ponieważ adres URL bramy nie jest zarejestrowany w publicznym systemie DNS, konsola testowa dostępna w portalu Azure nie będzie działać dla usługi wdrożonej w wewnętrznej sieci VNet. Zamiast tego użyj konsoli testowej udostępnionej w portalu dla deweloperów.

Włączanie łączności przy użyciu szablonu Resource Manager

• Azure Resource Manager szablon (API wersja 2021-08-01)

  

Konfigurowanie reguł NSG (grup zabezpieczeń sieciowych)

Skonfiguruj niestandardowe reguły zabezpieczeń sieci w podsieci usługi API Management, aby filtrować ruch do i z wystąpienia usługi API Management. Zalecamy przestrzeganie następujących minimalnych zasad grupy zabezpieczeń (NSG) w celu zapewnienia prawidłowego działania i dostępu do instancji. Uważnie przejrzyj środowisko, aby określić więcej reguł, które mogą być potrzebne.

Ważne

W zależności od użycia cachowania i innych funkcji może być konieczne skonfigurowanie dodatkowych reguł NSG poza minimalnymi regułami w poniższej tabeli. Aby uzyskać szczegółowe informacje na temat ustawień, zobacz Dokumentacja konfiguracji sieci wirtualnej.

• W większości scenariuszy użyj wskazanych tagów usługi zamiast adresów IP usługi, aby określić źródła sieci i miejsca docelowe.
• Ustaw priorytet tych reguł wyższy niż w przypadku reguł domyślnych.

Kierunek	Tag usługi źródłowej	Zakresy portów źródłowych	Docelowy tag usługi	Zakresy portów docelowych	Protokół	Akcja	Przeznaczenie	Typ sieci wirtualnej
Przychodzący	Internet	*	Sieć wirtualna	[80], 443	TCP	Zezwalaj	Komunikacja klienta z usługą API Management	Tylko zewnętrzne
Przychodzący	ApiManagement	*	Sieć wirtualna	3443	TCP	Zezwalaj	Punkt końcowy zarządzania dla portalu Azure i programu PowerShell	Zewnętrzne i wewnętrzne
Przychodzący	AzureLoadBalancer (równoważnik obciążenia)	*	Sieć wirtualna	6390	TCP	Zezwalaj	Równoważnik obciążenia dla infrastruktury Azure	Zewnętrzne i wewnętrzne
Przychodzący	AzureTrafficManager	*	Sieć wirtualna	443	TCP	Zezwalaj	Routing w Azure Traffic Manager dla wdrożenia w wielu regionach	Tylko zewnętrzne
Wychodzący	Sieć wirtualna	*	Internet	80	TCP	Zezwalaj	Walidacja i zarządzanie certyfikatami zarządzanymi Microsoft i zarządzanymi przez klienta	Zewnętrzne i wewnętrzne
Wychodzący	Sieć wirtualna	*	Magazyn	443	TCP	Zezwalaj	Zależność od Azure Storage dla podstawowych funkcji usługi	Zewnętrzne i wewnętrzne
Wychodzący	Sieć wirtualna	*	SQL	1433	TCP	Zezwalaj	Dostęp do punktów dostępowych Azure SQL dla kluczowych funkcji usługowych	Zewnętrzne i wewnętrzne
Wychodzący	Sieć wirtualna	*	AzureKeyVault	443	TCP	Zezwalaj	Dostęp do Azure Key Vault na potrzeby podstawowych funkcji usługi	Zewnętrzne i wewnętrzne
Wychodzący	Sieć wirtualna	*	AzureMonitor	1886, 443	TCP	Zezwalaj	Opublikuj Diagnostics Logs and Metrics, Resource Health i Application Insights	Zewnętrzne i wewnętrzne

Konfiguracja DNS

W trybie wewnętrznej sieci wirtualnej musisz zarządzać własnym systemem DNS, aby umożliwić dostęp przychodzący do punktów końcowych usługi API Management.

Zalecamy:

1. Skonfiguruj strefę prywatną Azure DNS.
2. Połącz strefę prywatną Azure DNS z siecią wirtualną, w której wdrożono usługę API Management.

Dowiedz się, jak skonfigurować strefę prywatną w Azure DNS.

Uwaga

Usługa API Management nie nasłuchuje żądań na swoich adresach IP. Odpowiada tylko na żądania do nazwy hosta skonfigurowanej w swoich punktach końcowych. Te punkty końcowe obejmują:

• brama interfejsów API
• Portal Azure
• Portal dla deweloperów
• Bezpośredni punkt końcowy zarządzania
• Git

Dostęp do domyślnych nazw hostów

Podczas tworzenia usługi API Management (contosointernalvnetna przykład) domyślnie konfigurowane są następujące punkty końcowe:

Punkt końcowy	Konfiguracja punktu końcowego
Bramka API	contosointernalvnet.azure-api.net
Portal deweloperów	contosointernalvnet.portal.azure-api.net
Nowy portal dla deweloperów	contosointernalvnet.developer.azure-api.net
Bezpośredni punkt końcowy zarządzania	contosointernalvnet.management.azure-api.net
Git	contosointernalvnet.scm.azure-api.net

Dostęp do niestandardowych nazw domen

Jeśli nie chcesz uzyskiwać dostępu do usługi API Management przy użyciu domyślnych nazw hostów, skonfiguruj niestandardowe nazwy domen dla wszystkich punktów końcowych, jak pokazano na poniższej ilustracji:

Konfigurowanie rekordów DNS

Utwórz rekordy na serwerze DNS, aby uzyskać dostęp do punktów końcowych dostępnych z poziomu sieci wirtualnej. Przypisz rekordy punktów końcowych do prywatnego wirtualnego adresu IP swojej usługi.

W celach testowych można zaktualizować plik hostów na maszynie wirtualnej w podsieci połączonej z siecią wirtualną, w której wdrożono usługę API Management. Zakładając, że prywatny wirtualny adres IP usługi to 10.1.0.5, możesz mapować plik hostów w następujący sposób. Plik mapowania hostów znajduje się w %SystemDrive%\drivers\etc\hosts (Windows) lub /etc/hosts (Linux, macOS).

Wewnętrzny wirtualny adres IP	Konfiguracja punktu końcowego
10.1.0.5	contosointernalvnet.azure-api.net
10.1.0.5	contosointernalvnet.portal.azure-api.net
10.1.0.5	contosointernalvnet.developer.azure-api.net
10.1.0.5	contosointernalvnet.management.azure-api.net
10.1.0.5	contosointernalvnet.scm.azure-api.net

Następnie możesz uzyskać dostęp do wszystkich punktów końcowych usługi API Management z utworzonej maszyny wirtualnej.

Trasowanie

Następujące wirtualne adresy IP są skonfigurowane dla wystąpienia usługi API Management w wewnętrznej sieci wirtualnej.

Wirtualny adres IP	opis
Prywatny wirtualny adres IP	Adres IP o zrównoważonym obciążeniu z zakresu podsieci wystąpienia usługi API Management (DIP), za pośrednictwem którego można uzyskać dostęp do bramy interfejsu API, portalu dla deweloperów, zarządzania i punktów końcowych usługi Git. Zarejestruj ten adres przy użyciu serwerów DNS używanych przez sieć wirtualną.
Publiczny wirtualny adres IP	Używany tylko dla ruchu płaszczyzny sterowania do punktu końcowego zarządzania przez port 3443. Można ograniczyć dostęp do tagu usługi ApiManagement.

Publiczne i prywatne adresy IP ze zrównoważonym obciążeniem można znaleźć w bloku Overview w portalu Azure.

Aby uzyskać więcej informacji i rozważań, zobacz adresy IP Azure API Management.

Adresy VIP i DIP

Dynamiczne adresy IP (DIP) zostaną przypisane do każdej podstawowej maszyny wirtualnej w usłudze i będą używane do uzyskiwania dostępu do punktów końcowych i zasobów w sieci wirtualnej oraz w równorzędnych sieciach wirtualnych. Publiczny adres IP (VIP) usługi API Management będzie używany do uzyskiwania dostępu do zasobów publicznych.

Jeśli ograniczenie adresu IP zawiera listę bezpiecznych zasobów w sieci wirtualnej lub równorzędnych sieciach wirtualnych, zalecamy określenie całego zakresu podsieci, w którym usługa API Management jest wdrażana w celu udzielenia lub ograniczenia dostępu z usługi.

Dowiedz się więcej o zalecanym rozmiarze podsieci.

Przykład

W przypadku wdrożenia 1 jednostki pojemności usługi API Management w warstwie Premium w wewnętrznej sieci wirtualnej będą używane 3 adresy IP: 1 dla prywatnego adresu VIP i po jednym dla adresów IP dla dwóch maszyn wirtualnych. W przypadku skalowania horyzontalnego do 4 jednostek więcej adresów IP zostanie zużytych na dodatkowe DIPs z podsieci.

Jeśli docelowy punkt końcowy ma umieszczony na liście dozwolonych tylko stały zestaw adresów IP, dodanie nowych jednostek w przyszłości spowoduje błędy połączeń. Z tego powodu i ponieważ podsieć jest całkowicie w Twojej kontroli, zalecamy umieszczenie całej podsieci w systemie backendowym na liście dopuszczonych.

Wymuszanie tunelowania ruchu do zapory lokalnej przy użyciu usługi ExpressRoute lub wirtualnego urządzenia sieciowego

Wymuszone tunelowanie umożliwia przekierowanie lub "wymuszenie" całego ruchu przeznaczonego do Internetu z podsieci z powrotem do środowiska lokalnego na potrzeby inspekcji i audytu. Często konfigurujesz i definiujesz własną trasę domyślną (0.0.0.0/0), wymuszając cały ruch z podsieci usługi API Management do przepływu przez lokalną zaporę lub do wirtualnego urządzenia sieciowego. Ten przepływ ruchu przerywa łączność z usługą API Management, ponieważ ruch wychodzący jest albo blokowany na miejscu, albo jego adresy sieciowe są przekładane na nierozpoznawalny zestaw adresów, które już nie działają z różnymi punktami końcowymi Azure. Ten problem można rozwiązać za pomocą następujących metod:

• Włącz punkty końcowe usługi w podsieci , w której jest wdrażana usługa API Management dla:

  • Azure SQL (wymagane tylko w regionie podstawowym, jeśli usługa API Management jest wdrożona w wielu regionach)
  • Azure Storage
  • Azure Event Hubs
  • Azure Key Vault

  Włączając punkty końcowe bezpośrednio z podsieci usługi API Management do tych usług, można użyć sieci szkieletowej Microsoft Azure, zapewniając optymalny routing ruchu usług. Jeśli używasz punktów końcowych usługi Azure z wymuszonym tunelowaniem w API Management, ruch dla wspomnianych wcześniej usług Azure nie jest tunelowany. Jednak pozostały ruch związany z zależnościami usługi API Management jest nadal przekierowywany siłą. Upewnij się, że zapora lub urządzenie wirtualne nie blokują tego ruchu lub usługa API Management może nie działać prawidłowo.

  Uwaga

  Zdecydowanie zalecamy włączenie punktów końcowych usługi bezpośrednio z podsieci usługi API Management do usług zależnych, takich jak Azure SQL i Azure Storage, które je obsługują. Jednak niektóre organizacje mogą mieć wymagania dotyczące wymuszania tunelowania całego ruchu z podsieci usługi API Management. W takim przypadku upewnij się, że skonfigurujesz zaporę lub urządzenie wirtualne, aby zezwolić na ten ruch. Musisz zezwolić na pełny zakres adresów IP każdej usługi zależnej i zachować tę konfigurację na bieżąco po zmianie infrastruktury Azure. Usługa API Management może również napotkać opóźnienia lub nieoczekiwane przekroczenia limitu czasu z powodu wymuszonego tunelowania tego ruchu sieciowego.

• Cały ruch płaszczyzny sterowania z Internetu do punktu końcowego zarządzania usługi API Management jest kierowany przez określony zestaw przychodzących adresów IP hostowanych przez usługę API Management, obejmujący tag usługiApiManagement. W przypadku wymuszonego tunelowania ruchu odpowiedzi nie będą odwzorowane w sposób symetryczny na te źródłowe adresy IP ruchu przychodzącego, co prowadzi do utraty łączności z punktem końcowym zarządzania. Aby wyeliminować to ograniczenie, skonfiguruj trasę zdefiniowaną przez użytkownika (UDR) dla tagu usługi ApiManagement z typem następnego przeskoku ustawionym na "Internet", aby kierować ruch z powrotem do Azure.

  Uwaga

  Zezwalanie na ruch związany z zarządzaniem usługą API Management w celu ominięcia lokalnej zapory sieciowej lub wirtualnego urządzenia sieciowego nie jest uznawane za znaczące zagrożenie dla bezpieczeństwa. Zalecana konfiguracja dla podsieci usługi API Management zezwala na ruch zarządzania na porcie 3443 jedynie z zestawu adresów IP Azure objętych tagiem usługi ApiManagement. Zalecana konfiguracja UDR (trasy zdefiniowanej przez użytkownika) dotyczy tylko ścieżki powrotnej tego ruchu Azure.

• (Tryb zewnętrznej sieci wirtualnej) Ruch płaszczyzny danych dla klientów próbujących uzyskać dostęp do bramy usługi API Management i portalu deweloperów z Internetu również zostanie domyślnie porzucony z powodu routingu asymetrycznego wprowadzonego przez wymuszone tunelowanie. Dla każdego klienta wymagającego dostępu skonfiguruj jawną UDR z typem następnego przeskoku "Internet", aby ominąć zaporę lub wirtualne urządzenie sieciowe.

• W przypadku innych zależności usługi API Management, które korzystają z przymusowego tunelowania, rozwiąż nazwę hosta i połącz się z punktem końcowym. Są to:

  • Metryki i monitorowanie kondycji
  • Diagnostyka portalu Azure
  • Przekaźnik SMTP
  • CapTCHA portalu dla deweloperów
  • serwer usługi Azure KMS

Aby uzyskać więcej informacji, zobacz Dokumentacja konfiguracji sieci wirtualnej.

Typowe problemy z konfiguracją sieci

Ta sekcja została przeniesiona. Zobacz Dokumentacja konfiguracji sieci wirtualnej.

Rozwiązywanie problemów

Nieudane początkowe wdrożenie usługi API Management w podsieci

• Wdróż maszynę wirtualną w tej samej podsieci.
• Połącz się z maszyną wirtualną i zweryfikuj łączność z jednym z następujących zasobów w subskrypcji Azure:
  • blob usługi Azure Storage
  • Azure SQL Database
  • usługa Azure Storage Table
  • Azure Key Vault

Ważne

Po zweryfikowaniu łączności usuń wszystkie zasoby w podsieci przed wdrożeniem usługi API Management w podsieci.

Weryfikowanie stanu sieci

• Po wdrożeniu usługi API Management w podsieci użyj portalu, aby zweryfikować połączenie instancji z zależnościami, takimi jak Azure Storage.

• W portalu w menu paska bocznego w obszarze Wdrażanie i infrastruktura wybierz pozycjęStan sieci sieciowej>.

  

Filtr	opis
Wymagane	Wybierz, aby przejrzeć wymaganą łączność usług Azure dla usługi API Management. Błąd wskazuje, że instancja nie może wykonać podstawowych operacji do zarządzania API.
Fakultatywny	Wybierz, aby przejrzeć łączność usług opcjonalnych. Błąd wskazuje tylko, że określona funkcja nie będzie działać (na przykład SMTP). Niepowodzenie może prowadzić do pogorszenia zdolności użycia i monitorowania wystąpienia usługi API Management oraz zapewnienia gwarantowanego poziomu SLA.

Aby ułatwić rozwiązywanie problemów z łącznością, wybierz pozycję:

• Metryki — aby przejrzeć metryki stanu łączności sieciowej

• Diagnozowanie — uruchamianie weryfikatora sieci wirtualnej w określonym przedziale czasu

Aby rozwiązać problemy z łącznością, przejrzyj ustawienia konfiguracji sieci i napraw wymagane ustawienia sieciowe.

Aktualizacje przyrostowe

Podczas wprowadzania zmian w sieci zapoznaj się z interfejsem API NetworkStatus , aby sprawdzić, czy usługa API Management nie utraciła dostępu do krytycznych zasobów. Stan łączności powinien być aktualizowany co 15 minut.

Aby zastosować zmianę konfiguracji sieci w wystąpieniu Zarządzania API za pomocą portalu:

1. W menu po lewej stronie wystąpienia w obszarze Wdrażanie i infrastruktura wybierz pozycję Sieć>Sieć wirtualna.
2. Wybierz pozycję Zastosuj konfigurację sieci.

Wyzwania napotkane podczas ponownego przypisania wystąpienia usługi API Management do poprzedniej podsieci

• Blokada sieci wirtualnej — podczas przenoszenia wystąpienia usługi API Management z powrotem do oryginalnej podsieci natychmiastowe ponowne przypisanie może nie być możliwe z powodu blokady sieci wirtualnej, która może potrwać do jednej godziny.
• Blokada grupy zasobów — innym scenariuszem, który należy wziąć pod uwagę, jest obecność blokady zakresu na poziomie grupy zasobów lub wyższym, co utrudnia proces usunięcia linku nawigacyjnego zasobu. Aby rozwiązać ten problem, usuń blokadę zakresu i zezwól na opóźnienie około 4–6 godzin, aby usługa API Management odłączyła się od oryginalnej podsieci przed usunięciem blokady, umożliwiając wdrożenie w żądanej podsieci.

Rozwiązywanie problemów z połączeniem z Microsoft Graph z wnętrza sieci wirtualnej

Łączność sieciowa z Microsoft Graph jest wymagana w przypadku funkcji, w tym logowania użytkownika do portalu deweloperów przy użyciu dostawcy tożsamości Microsoft Entra.

Aby rozwiązać problemy z łącznością z Microsoft Graph z sieci wirtualnej:

• Upewnij się, że grupa zabezpieczeń sieci (NSG) i inne reguły sieciowe zostały skonfigurowane pod kątem łączności wychodzącej z instancji API Management z usługą Microsoft Graph (przy użyciu tagu usługi AzureActiveDirectory).

• Upewnij się, że rozpoznawanie nazw DNS i dostęp sieciowy do graph.microsoft.com z sieci wirtualnej. Na przykład aprowizuj nową maszynę wirtualną w sieci wirtualnej, połącz się z nią i spróbuj GET https://graph.microsoft.com/v1.0/$metadata w przeglądarce lub używając cURL-a, PowerShella lub innych narzędzi.

Treści powiązane

Dowiedz się więcej na następujące tematy:

• Dokumentacja konfiguracji sieci wirtualnej
• Często zadawane pytania dotyczące sieci wirtualnej
• Tworzenie rekordu w usłudze DNS