Dieses Problem bringt mich nicht weiter. Ich habe zwei verschiedene Macs, die weder über den Namen noch über die IP-Adresse auf pear.php.net zugreifen können.
Hier sind die Symptome und Schritte, die ich unternommen habe, um dieses Problem zu lösen/einzugrenzen.
$ ping -c 4 pear.php.net
PING euk1.php.net (5.77.39.20): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
--- euk1.php.net ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 4 5.77.39.20
PING 5.77.39.20 (5.77.39.20): 56 data bytes
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: Host is down
Request timeout for icmp_seq 1
ping: sendto: Host is down
Request timeout for icmp_seq 2
--- 5.77.39.20 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
Von einem Windows-PC im selben Netzwerk (ich habe zur Sicherheit sogar dasselbe Ethernet-Kabel verwendet)
c:\>ping pear.php.net
Pinging euk1.php.net [5.77.39.20] with 32 bytes of data:
Reply from 5.77.39.20: bytes=32 time=102ms TTL=51
Reply from 5.77.39.20: bytes=32 time=102ms TTL=51
Reply from 5.77.39.20: bytes=32 time=100ms TTL=51
Reply from 5.77.39.20: bytes=32 time=102ms TTL=51
Ping statistics for 5.77.39.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 100ms, Maximum = 102ms, Average = 101ms
- Beide Maschinen laufen unter OSX 10.7
- Habe es sowohl per Kabel als auch per WLAN probiert, gleiches Ergebnis
- Habe einen der Macs in einem anderen Netzwerk ausprobiert, gleiches Ergebnis
- Habe es mit ein- und ausgeschalteter Firewall versucht, gleiches Ergebnis
- Dieses Problem hatte ich mit keiner anderen Site/IP
- Versuchte, sowohl pear.php.net als auch 5.77.39.20 in einem Browser zu öffnen, bekam 404
Edit: Als Antwort auf Pauls Kommentar
$netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 18 0 en1
5 link#8 UC 2 0 ham0
5.255.255.255 ff:ff:ff:ff:ff:ff UHLWbI 0 10 ham0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 3 152 lo0
169.254 link#5 UCS 0 0 en1
192.168.0 link#5 UCS 4 0 en1
192.168.0.1 0:1b:6c:69:19:8f UHLWIi 28 634 en1 1141
192.168.0.192 127.0.0.1 UHS 0 0 lo0
192.168.0.194 0:21:a0:50:4d:70 UHLWIi 0 498 en1 669
192.168.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 10 en1
Internet6:
Destination Gateway Flags Netif Expire
::1 link#1 UHL lo0
2620:9b::/96 link#8 UC ham0
2620:9c::5f7:6deb 7a:7c:5:f7:6d:eb UHL lo0
fe80::%lo0/64 fe80::1%lo0 UcI lo0
fe80::1%lo0 link#1 UHLI lo0
fe80::%en0/64 link#4 UCI en0
fe80::205:ff:fee1:a1a2%en0 0:5:0:e1:a1:a2 UHLWIi en0
fe80::%en1/64 link#5 UCI en1
fe80::1240:d3ff:feaf:8974%en1 10:40:d3:af:89:74 UHLI lo0
fe80::%ham0/64 link#8 UCI ham0
fe80::7879:5ff:fec7:6deb%ham0 7a:79:5:c7:6d:eb UHLI lo0
ff01::%lo0/32 fe80::1%lo0 UmCI lo0
ff01::%en0/32 link#4 UmCI en0
ff01::%en1/32 link#5 UmCI en1
ff01::%ham0/32 link#8 UmCI ham0
ff02::%lo0/32 fe80::1%lo0 UmCI lo0
ff02::%en0/32 link#4 UmCI en0
ff02::%en1/32 link#5 UmCI en1
ff02::%ham0/32 link#8 UmCI ham0
Antwort1
Sie haben dort eine Route für das Netzwerk 5.0.0.0/8, die zur Schnittstelle ham0 führt.
Dies ist die Hamachi-Schnittstelle. Als Hamachi seinen Dienst startete, wählte das Unternehmen das Netzwerk 5.0.0.0/8 als Adresspool, um Konflikte mit vorhandenen Bereichen zu vermeiden. Hamachi wurde dieser Bereich jedoch nie zugewiesen.
In den letzten Monaten hat RIPE (verantwortlich für diesen Bereich) begonnen, Blöcke im 5/8-Netzwerk zu verkaufen. Dies war angesichts der schnell abnehmenden Anzahl an IPv4-Adressen unvermeidlich, doch Hamachi verwendet diesen Block immer noch.
Wenn Sie auf Dienste in diesem Bereich zugreifen möchten, müssen Sie Hamachi deinstallieren – oder es zumindest während des Zugriffs auf diese Blöcke deaktivieren. Sie können die Route auch jedes Mal manuell löschen.
Die wirkliche Lösung besteht für Hamachi darin, einen Block zu kaufen, zu dessen Nutzung es berechtigt ist, oder auf IPv6 umzusteigen.
Antwort2
Eine Alternative besteht darin, Ihren Hamachi-Client auf IPv6 umzustellen.
Ich habe es unter Mountain Lion 10.8.1 gemacht (dasselbe Problem, kein Zugriff auf pear.php.net) und kann jetzt problemlos darauf zugreifen und gleichzeitig die Verbindung zu meinen Büro- und Heimcomputern aufrechterhalten.
Um auf IPv6 umzustellen, gehen Sie einfach zu „LogMeIn Hamachi > Einstellungen > Einstellungen > Erweiterte Einstellungen > Peer-Verbindungen > IP-Protokollmodus“ und wechseln Sie zu „Nur IPv6“. Stellen Sie die Verbindung erneut her und versuchen Sie, auf pear.php.net zuzugreifen.
Hier wird die letzte Hamachi-Clientversion verwendet, 2.1.0.322 für OSX