Teilen über

Was ist die IP-Adresse 168.63.129.16?

  • Artikel

Die IP-Adresse 168.63.129.16 ist eine virtuelle öffentliche IP-Adresse, die verwendet wird, um einen Kommunikationskanal zu den Ressourcen der Azure-Plattform zu ermöglichen. 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 die Kommunikation zwischen VM-Agent und Azure-Plattform, um zu signalisieren, dass er sich im Zustand „Bereit“ befindet.

  • Ermöglicht die Kommunikation mit dem virtuellen DNS-Server, um für die Ressource (z. B. eine VM) eine gefilterte Namensauflösung bereitzustellen, die keinen benutzerdefinierten DNS-Server hat. Dieser Filter stellt sicher, dass Kunden nur die Hostnamen ihrer Ressourcen auflösen können.

  • Ermöglicht Integritätstests mit Azure Load Balancer, um den Integritätszustand der VMs zu ermitteln.

  • Ermöglichen des Abrufs einer dynamischen IP-Adresse vom DHCP-Dienst in Azure durch die VM.

  • Ermöglicht Taktmeldungen für einen Gast-Agent für die PaaS-Rolle.

Hinweis

In einem Szenario ohne virtuelles Netzwerk (klassisch) wird anstelle von 168.63.129.16 eine private IP-Adresse verwendet. Diese private IP-Adresse wird dynamisch per DHCP ermittelt. Speziell für 168.63.129.16 festgelegte Firewallregeln müssen entsprechend angepasst werden.

Bereich der 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. Wir empfehlen Ihnen, diese IP-Adresse in lokalen Firewallrichtlinien (auf der VM, in ausgehender 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.

  • Für den VM-Agent ist ausgehende Kommunikation über die Ports 80/tcp und 32526/tcp mit dem WireServer (168.63.129.16) erforderlich. Diese Ports müssen 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 der VM stammen.

  • 168.63.129.16 kann DNS-Dienste für die VM bereitstellen. Wenn die von 168.63.129.16 bereitgestellten DNS-Dienste nicht erwünscht sind, kann der ausgehende Datenverkehr zu den Ports 53/udp und 53/tcp von 168.63.129.16 von der lokalen Firewall der VM blockiert werden.

    Standardmäßig unterliegt die DNS-Kommunikation nicht den konfigurierten Netzwerksicherheitsgruppen, es sei denn, sie wird über das AzurePlatformDNS-Diensttag gesteuert. 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 umgekehrte DNS-Suche. Dies bedeutet, wenn Sie versuchen, den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) mithilfe von umgekehrten Suchbefehlen wie host, nslookup oder dig -x auf 168.63.129.16 abzurufen, erhalten Sie keinen FQDN.

  • Wenn die VM 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 Tests, die fehlschlagen.

Behandeln von Konnektivitätsproblemen

Hinweis

Beim Ausführen der folgenden Tests muss die Aktion als Administrator (Windows) und Root (Linux) ausgeführt werden, um genaue Ergebnisse sicherzustellen.

Windows-Betriebssystem

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

Test-NetConnection -ComputerName 168.63.129.16 -Port 80
Test-NetConnection -ComputerName 168.63.129.16 -Port 32526
Invoke-RestMethod -Headers @{"Metadata"="true"} -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

Linux-Betriebssystem

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

echo "Testing 80 168.63.129.16 Port 80" > 168-63-129-16_test.txt
traceroute -T -p 80 168.63.129.16 >> 168-63-129-16_test.txt
echo "Testing 80 168.63.129.16 Port 32526" >> 168-63-129-16_test.txt
traceroute -T -p 32526 168.63.129.16 >> 168-63-129-16_test.txt
echo "Test 168.63.129.16 Versions"  >> 168-63-129-16_test.txt
curl http://168.63.129.16/?comp=versions >> 168-63-129-16_test.txt

Die Ergebnisse in der Datei „168-63-129-16_test.txt“ sollten wie folgt zurückgegeben werden.

traceroute -T -p 80 168.63.129.16
traceroute to 168.63.129.16 (168.63.129.16), 30 hops max, 60 byte packets
1  168.63.129.16 (168.63.129.16)  0.974 ms  1.085 ms  1.078 ms

traceroute -T -p 32526 168.63.129.16
traceroute to 168.63.129.16 (168.63.129.16), 30 hops max, 60 byte packets
1  168.63.129.16 (168.63.129.16)  0.883 ms  1.004 ms  1.010 ms

curl http://168.63.129.16/?comp=versions
<?xml version="1.0" encoding="utf-8"?>
<Versions>
<Preferred>
<Version>2015-04-05</Version>
</Preferred>
<Supported>
<Version>2015-04-05</Version>
<Version>2012-11-30</Version>
<Version>2012-09-15</Version>
<Version>2012-05-15</Version>
<Version>2011-12-31</Version>
<Version>2011-10-15</Version>
<Version>2011-08-31</Version>
<Version>2011-04-07</Version>
<Version>2010-12-15</Version>
<Version>2010-28-10</Version>
</Supported>

Nächste Schritte