Freigeben über

Azure IP-Adresse 168.63.129.16 – Übersicht

Azure IP-Adresse 168.63.129.16 ist eine virtuelle öffentliche IP-Adresse, die Kommunikationskanäle zu Azure-Plattformressourcen erleichtert. Kunden können in Azure einen beliebigen Adressraum für ihr privates virtuelles Netzwerk definieren. Daher müssen die Ressourcen der Azure-Plattform als eindeutige öffentliche IP-Adresse dargestellt werden. Diese virtuelle öffentliche IP-Adresse erleichtert die folgenden Vorgänge:

  • Ermöglicht dem Agent des virtuellen Computers die Kommunikation mit der Azure-Plattform, um zu signalisieren, dass er sich im Zustand "Bereit" befindet.
  • Ermöglicht die Kommunikation mit dem virtuellen DNS-Server, um eine gefilterte Namensauflösung für die Ressourcen (z. B. virtuelle Computer) bereitzustellen, die keinen benutzerdefinierten DNS-Server besitzen. Dieser Filter stellt sicher, dass Kunden nur die Hostnamen ihrer Ressourcen auflösen können.
  • Ermöglicht Integritätstests von Azure Load Balancer, um den Integritätszustand von VMs zu ermitteln.
  • Ermöglicht dem virtuellen Computer das Abrufen einer dynamischen IP-Adresse aus dem DHCP-Dienst in Azure.
  • Ermöglicht Taktmeldungen für einen Gast-Agent für die PaaS-Rolle.

Umfang der Azure IP-Adresse 168.63.129.16

Die öffentliche IP-Adresse 168.63.129.16 wird in allen Regionen und allen nationalen Clouds verwendet. Microsoft besitzt diese spezielle öffentliche IP-Adresse und sie ändert sich nicht. Es wird empfohlen, diese IP-Adresse in allen lokalen Firewallrichtlinien (in der virtuellen Maschine) (ausgehende Richtung) zuzulassen. Die Kommunikation zwischen dieser speziellen IP-Adresse und den Ressourcen ist sicher, da nur die interne Azure-Plattform eine Nachricht von dieser IP-Adresse beziehen kann. Wenn diese Adresse blockiert ist, kann in verschiedenen Szenarien ein unerwartetes Verhalten auftreten. 168.63.129.16 ist eine virtuelle IP des Hostknotens und unterliegt daher keinen benutzerdefinierten Routen.

  • Der Agent für virtuelle Computer erfordert ausgehende Kommunikation über ports 80/tcp und 32526/tcp mit WireServer (168.63.129.16). Diese Ports sollten in der lokalen Firewall auf dem virtuellen Computer geöffnet sein. Die Kommunikation mit 168.63.129.16 über diese Ports unterliegt nicht den konfigurierten Netzwerksicherheitsgruppen. Der Datenverkehr muss immer von der primären Netzwerkschnittstelle des virtuellen Computers stammen.

  • 168.63.129.16 kann DNS-Dienste für den virtuellen Computer bereitstellen. Wenn DNS-Dienste, die von 168.63.129.16 bereitgestellt werden, nicht erwünscht sind, können ausgehende Datenverkehr zu 168.63.129.16 Ports 53/udp und 53/tcp in der lokalen Firewall auf dem virtuellen Computer blockiert werden.

    Standardmäßig unterliegt die DNS-Kommunikation nicht den konfigurierten Netzwerksicherheitsgruppen, es sei denn, sie wird gezielt über das AzurePlatformDNS-Dienst-Tag angesprochen. Um DNS-Datenverkehr an Azure DNS über NSG zu blockieren, erstellen Sie eine Ausgangsregel, um Datenverkehr an AzurePlatformDNS zu verweigern. Geben Sie „Beliebig(e)“ als „Quelle“, „*“ als „Zielportbereiche“, „Beliebig(e)“ als Protokoll und „Verweigern“ als Aktion an.

    Darüber hinaus unterstützt die IP-Adresse 168.63.129.16 keine Reverse-DNS-Suche. Dies bedeutet, wenn Sie versuchen, den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) mithilfe von Reverse-Nachschlagebefehlen wie host, nslookupoder dig -x auf 168.63.129.16 abzurufen, wird kein FQDN empfangen.

  • Wenn der virtuelle Computer Teil eines Back-End-Pools für den Lastenausgleich ist, sollte für die Integritätstest-Kommunikation zugelassen werden, dass sie von 168.63.129.16 ausgeht. Die Standardkonfiguration der Netzwerksicherheitsgruppen enthält eine Regel, die diese Kommunikation zulässt. Für diese Regel wird das Diensttag AzureLoadBalancer genutzt. Dieser Datenverkehr kann bei Bedarf blockiert werden, indem die Netzwerksicherheitsgruppe konfiguriert wird. Die Konfiguration des Blocks führt zu Sonden, die fehlschlagen.

Problembehandlung bei Azure IP-Konnektivität

Note

Die Ausführung der folgenden Tests muss als Administrator (Windows) und Root (Linux) ausgeführt werden, um genaue Ergebnisse sicherzustellen.

Sie können die Kommunikation mit 168.63.129.16 testen, indem Sie die folgenden Tests mit PowerShell verwenden.

$Params = @{
  ComputerName = "168.63.129.16"
  Port         = 80
}
Test-NetConnection @Params

$Params.Port = 32526
Test-NetConnection @Params

$Headers = @{
  Metadata = "true"
}
Invoke-RestMethod -Headers $Headers -Method GET -Uri "http://168.63.129.16/?comp=versions"

Die Ergebnisse sollten wie folgt zurückgegeben werden.

Test-NetConnection -ComputerName 168.63.129.16 -Port 80
ComputerName     : 168.63.129.16
RemoteAddress    : 168.63.129.16
RemotePort       : 80
InterfaceAlias   : Ethernet
SourceAddress    : 10.0.0.4
TcpTestSucceeded : True

Test-NetConnection -ComputerName 168.63.129.16 -Port 32526
ComputerName     : 168.63.129.16
RemoteAddress    : 168.63.129.16
RemotePort       : 32526
InterfaceAlias   : Ethernet
SourceAddress    : 10.0.0.4
TcpTestSucceeded : True

Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri http://168.63.129.16/?comp=versions
xml                            Versions
---                            --------
version="1.0" encoding="utf-8" Versions

Sie können auch die Kommunikation mit 168.63.129.16 testen, indem Sie telnet oder psping verwenden.

Bei erfolgreicher Ausführung sollte telnet eine Verbindung herstellen und die erstellte Datei ist leer.

telnet 168.63.129.16 80 >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test-port80.txt
telnet 168.63.129.16 32526 >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test--port32526.txt

Psping 168.63.129.16:80 >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test--port80.txt
Psping 168.63.129.16:32526 >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test-port32526.txt

Next steps

  • Last updated on