adresy IP komunikacji sieci szkieletowej Azure

Azure hosty sesji usługi Virtual Desktop (AVD) i komputery Windows 365 Cloud wymagają łączności z dwoma adresami IP platformy Azure. Te adresy zapewniają dostęp do podstawowych usług infrastruktury, które obsługują aprowizację, monitorowanie kondycji, tożsamość i komunikację platformy.

Ruch do tych adresów działa na poziomie sieci szkieletowej platformy Azure. Zachowuje się inaczej niż ruch do punktów końcowych opartych na FQDN i musi być odpowiednio obsługiwany.

W tym artykule wyjaśniono, czym są te adresy IP, dlaczego są one niezbędne, czym różnią się od innych punktów końcowych i jak zapewnić pomyślne połączenie.

Omówienie

Azure hosty sesji usługi Virtual Desktop i komputery w chmurze Windows 365 wymagają łączności z następującymi adresami IP:

Adres	Protocol (Protokół)	Port wychodzący	Celu	Tag usługi
169.254.169.254	TCP	80	Azure Instance Metadata Service (IMDS)	Nie dotyczy
168.63.129.16	TCP/UDP	80, 32526 (TCP), 53 (TCP/UDP)	łączność usługi platformy Azure	Nie dotyczy

Ważna

Te adresy są używane we wszystkich regionach Azure i środowiskach chmury, w tym w Azure chmury publicznej, Azure Government i Azure Chinach. Utrata łączności z adresem powoduje błędy aprowizacji, problemy z raportowaniem kondycji i obniżenie wydajności usługi.

usługa metadanych wystąpienia Azure (169.254.169.254)

Azure Instance Metadata Service (IMDS) to punkt końcowy interfejsu API REST, który udostępnia informacje o uruchomionej maszynie wirtualnej. Oprogramowanie wewnątrz maszyny wirtualnej używa usług IMDS do integracji ze środowiskiem Azure.

Maszyny wirtualne używają usługi IMDS do pobierania:

• Dane dotyczące tożsamości i konfiguracji maszyny wirtualnej

• Tokeny tożsamości zarządzanej na potrzeby uwierzytelniania w usługach Azure

• Powiadomienia o zaplanowanych zdarzeniach i konserwacji

• Metadane, takie jak region, strefa dostępności, rozmiar maszyny wirtualnej i konfiguracja sieci

Adres 169.254.169.254 jest adresem IP typu link-local. Nie można go rozsyłać i jest dostępny tylko z poziomu maszyny wirtualnej. Żądania do tego adresu nigdy nie opuszczają hosta fizycznego. Funkcja hypervisor Azure przechwytuje ruch i reaguje na nie lokalnie.

Usługa IMDS działa na poziomie funkcji hypervisor. Nie ma to wpływu na sieciowe grupy zabezpieczeń, trasy zdefiniowane przez użytkownika ani reguły Azure Firewall. Jednak konfiguracja systemu operacyjnego wewnątrz maszyny wirtualnej, taka jak zapory hostów lub klienci sieci VPN, może blokować dostęp.

Azure monitorowanie kondycji platformy (168.63.129.16)

Adres 168.63.129.16 jest wirtualnym publicznym adresem IP używanym przez usługi platformy Azure do komunikacji z maszynami wirtualnymi. Ten adres jest również nazywany punktem końcowym WireServer.

Maszyny wirtualne używają tego adresu w następujących celach:

• Monitorowanie kondycji i komunikacja pulsu z agenta maszyny wirtualnej Azure

• Rozpoznawanie nazw DNS podczas korzystania z systemu DNS dostarczonego przez Azure. (Port 53 (UDP/TCP) jest wymagany tylko w przypadku korzystania z systemu DNS dostarczonego Azure. Jeśli niestandardowy serwer DNS jest używany dla sieci wirtualnej, ten port nie jest wymagany.

• Komunikacja DHCP na potrzeby przypisywania i odnawiania adresów IP

Ruch do wersji 168.63.129.16 przechodzi przez sieć szkieletową sieci wirtualnej Azure. Azure routing platformy stosuje specjalną obsługę, aby zapewnić, że adres pozostaje dostępny w sieciach z restrykcyjnymi konfiguracjami zabezpieczeń lub routingu.

Różnice między standardowymi punktami końcowymi

Azure virtual desktop i Windows 365 również wymagają łączności z punktami końcowymi opartymi na FQDN, takimi jak usługi płaszczyzny sterowania, Microsoft Entra ID itp. Ruch do tych punktów końcowych zachowuje się jak standardowy ruch internetowy do publicznych adresów IP. Niektóre z tych ruchów, takie jak RDP, wymagają optymalizacji w sieciach klientów, ale zazwyczaj mogą być traktowane jak zwykłe publiczne punkty końcowe.

Ruch do wersji 169.254.169.254 i 168.63.129.16 zachowuje się jednak inaczej.

• Azure wewnętrzne i niezmierne do routingu. Te adresy są częścią Azure wewnętrznej infrastruktury platformy. Nie są to internetowe punkty końcowe, nie są rozpoznane za pośrednictwem publicznego systemu DNS i nie można uzyskać do nich dostępu z zewnątrz Azure ani z sieci lokalnych.

• Nie można ich połączyć, ponieważ serwery proxy nie są w stanie uzyskać dostępu do tych adresów. Próby wysłania tego ruchu za pośrednictwem serwera proxy nie zakończą się pomyślnie— za pośrednictwem plików PAC, zasady grupy lub ustawień serwera proxy aplikacji.

• Nie mogą przechodzić przez tunele sieci VPN ani zabezpieczać bram internetowych. Klienci sieci VPN i bezpieczni agenci bramy internetowej, którzy działają w trybie pełnego tunelu lub wymuszonego tunelu, przechwytują cały ruch z maszyny wirtualnej. Gdy przechwytują ruch do tych adresów, łączność kończy się niepowodzeniem, ponieważ adresy nie są osiągalne za pośrednictwem tuneli SIECI VPN lub infrastruktury zabezpieczeń innych firm.

• Częściowo chronione przez routing platformy Azure. Azure sieci obejmuje ochronę zapewniającą łączność z tymi adresami w warstwie sieci szkieletowej. Trasy domyślne, takie jak 0.0.0.0/0 i większość reguł sieciowych grup zabezpieczeń, nie blokują tego ruchu. Jednak te zabezpieczenia nie mają zastosowania do konfiguracji wewnątrz maszyny wirtualnej ani do jawnych reguł sieciowych, które są przeznaczone dla tych adresów lub tagów usługi.

Dlatego ważne jest, aby upewnić się, że w środowisku nie występują następujące problemy z konfiguracją:

Problemy z konfiguracją maszyny wirtualnej

Większość problemów z łącznością wynika z konfiguracji wewnątrz maszyny wirtualnej, a nie Azure konfiguracji warstwy sieciowej.

Klienci sieci VPN i bezpieczni agenci bramy internetowej

Organizacje wdrażają klientów sieci VPN lub bezpiecznych agentów bramy internetowej na komputerach w chmurze i hostach sesji w celu wymuszania zasad zabezpieczeń. Przykłady obejmują Zscaler Internet Access, Dostęp do Internetu Microsoft Entra, PaloAlto Global Protect itp.

Gdy ci agenci działają w trybie wymuszonego tunelu, przekierowują cały ruch za pośrednictwem karty wirtualnej. Ta konfiguracja może obejmować ruch do adresów platformy Azure, co powoduje przerwanie łączności.

Co należy sprawdzić:

• Używanie tunelowania podzielonego, aby Azure ruch platformy pozostaje lokalny

• Konfigurowanie jawnych reguł obejścia lub wykluczania dla wersji 169.254.169.254 i 168.63.129.16

Konfiguracja serwera proxy i pac

Ustawienia serwera proxy stosowane za pośrednictwem plików PAC, zasady grupy, WinHTTP, WinINET lub ustawień specyficznych dla aplikacji mogą spowodować, że maszyna wirtualna będzie serwerem proxy Azure ruch platformy.

Co należy sprawdzić:

• Pliki PAC zwracają bezpośrednie połączenie dla tych adresów

• Listy obejścia serwera proxy obejmują oba adresy

• Przegląd ustawień serwera proxy na poziomie użytkownika i komputera

Reguły zapory hosta

Zapory oparte na hostach lub oprogramowanie endpoint protection mogą blokować wychodzący ruch TCP.

Co należy sprawdzić:

• Zezwalaj na wychodzący ruch TCP do 169.254.169.254 na porcie 80

• Zezwalaj na ruch wychodzący TCP do 168.63.129.16 na portach 80 i 32526

Zabezpieczenia punktu końcowego i oprogramowanie do filtrowania sieci

Programy antywirusowe, wykrywanie punktów końcowych & Response (EDR) lub narzędzia do ochrony przed utratą danych (DLP) mogą obejmować funkcje inspekcji sieci.

Co należy sprawdzić:

• Upewnij się, że te narzędzia nie blokują ani nie sprawdzają ruchu do tych adresów

• Dodaj reguły zezwalania lub wykluczania oparte na protokole IP, jeśli jest to wymagane

---

Azure problemy z konfiguracją warstwy sieciowej

Sieciowe grupy zabezpieczeń

Azure definiuje tagi usługi dla tych punktów końcowych:

• AzurePlatformIMDS dla wersji 169.254.169.254

• AzurePlatformDNS dla wersji 168.63.129.16

Jawne reguły odmowy przeznaczone dla tych tagów usługi mogą zakłócać łączność.

Co należy sprawdzić:

• Usuwanie reguł odmowy przeznaczonych dla tych tagów lub adresów usługi

• Upewnij się, że restrykcyjne reguły ruchu wychodzącego odmów obejmują jawne reguły zezwalania dla tych tagów usługi

Trasy zdefiniowane przez użytkownika i wirtualne urządzenia sieciowe

Azure routing platformy zwykle zapewnia osiągalność niezależnie od tras domyślnych. Jednak jawne trasy lub złożone topologie routingu mogą powodować problemy.

Co należy sprawdzić:

• Brak tras jawnie docelowych 169.254.169.254 lub 168.63.129.16

• Zapory lub wirtualne urządzenia sieciowe w ścieżce zezwalają na ruch wychodzący do tych adresów i portów

sprawdzanie kondycji połączenia sieciowego Azure

Windows 365 Enterprise używa Azure połączeń sieciowych do aprowizacji komputerów w chmurze. Każde połączenie obejmuje automatyczne kontrole kondycji, które weryfikują łączność sieciową.

Jakie testy kondycji są weryfikowane

• Łączność sieci szkieletowej z punktami końcowymi platformy Azure

• Konfiguracja sieciowej grupy zabezpieczeń

• Konfiguracja tabeli tras

• Rozpoznawanie nazw DNS przy użyciu systemu DNS dostarczonego Azure

Jakie kontrole kondycji nie są weryfikowane

• Klienci sieci VPN lub bezpieczni agenci bramy internetowej zainstalowani po aprowizacji

• Konfiguracja serwera proxy lub pac stosowana za pośrednictwem zasady grupy lub Intune

• Reguły zapory hosta lub oprogramowanie zabezpieczeń punktu końcowego

• Konfiguracja zastosowana wewnątrz maszyny wirtualnej po przypisaniu

Przechodząca kontrola kondycji potwierdza, że sieć Azure zezwala na ruch platformy. Nie gwarantuje to, że komputery w chmurze lub hosty sesji mogą dotrzeć do tych punktów końcowych po zastosowaniu konfiguracji maszyny wirtualnej.

Podsumowanie

Łączność z wersjami 169.254.169.254 i 168.63.129.16 jest wymagana dla Azure Virtual Desktop i Windows 365. Blokowanie tych punktów końcowych prowadzi do aprowizowania i problemów operacyjnych zarówno z usługami Windows 365, jak i Azure Virtual Desktop.

Te adresy są Azure wewnętrznymi punktami końcowymi platformy. Ruch do tych adresów nie może być przekazywany, przechwytywany ani kierowany przez tunele SIECI VPN ani bezpieczne bramy sieci Web.

Większość błędów łączności wynika z konfiguracji wewnątrz maszyny wirtualnej, takiej jak klienci sieci VPN, ustawienia serwera proxy, zapory hosta lub oprogramowanie zabezpieczeń punktu końcowego. Problemy z warstwą sieciową są mniej typowe, ale mogą wystąpić, gdy jawne reguły są przeznaczone dla tych adresów lub tagów usługi.

Azure testy kondycji połączenia sieciowego sprawdzają tylko łączność warstwy sieciowej. Nie wykrywają problemów z konfiguracją maszyny wirtualnej.