Von OSX Lion aus kann nicht auf pear.php.net zugegriffen werden


8

Ich bin verblüfft über dieses Problem. Ich habe 2 separate Macs, die überhaupt nicht über Name oder IP auf pear.php.net zugreifen können.

Hier sind die Symptome und Schritte, die ich unternommen habe, um dieses Problem zu beheben / 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 sogar das gleiche Ethernet-Kabel verwendet, nur um sicherzugehen)

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
  • Auf beiden Computern wird OSX 10.7 ausgeführt
  • Versuchte sowohl Kabel als auch WLAN, das gleiche Ergebnis
  • Versuchte einen der Macs in einem anderen Netzwerk, das gleiche Ergebnis
  • Versucht mit ein- und ausgeschalteter Firewall, gleiches Ergebnis
  • Habe dieses Problem mit keiner anderen Site / IP gehabt
  • Versucht, sowohl pear.php.net als auch 5.77.39.20 in einem Browser zu öffnen, bekam 404

Bearbeiten: 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

Können Sie eine Routing-Tabelle von OSX aus veröffentlichen? Hoffentlichnetstat -rn
Paul

@ Paul Ich habe es der obigen Beschreibung hinzugefügt.
Peter Meth

Sie haben dort eine seltsame Route für das 5.0.0.0 / 8-Netzwerk, die wahrscheinlich die Ursache des Problems ist. Können Sie Hamachi deaktivieren und es erneut versuchen?
Paul

Wow, du bist ein Genie. Ich habe hamachi deinstalliert und die Dinge fingen an zu funktionieren.
Peter Meth

Fertig - Ich habe unten einige Details hinzugefügt, um zu verdeutlichen, warum dies geschieht
Paul

Antworten:


10

Sie haben dort eine Route für das 5.0.0.0 / 8-Netzwerk, die zur ham0-Schnittstelle führt.

Dies ist die Hamachi-Schnittstelle. Als Hamachi seinen Dienst startete, wählten sie 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 (die für diesen Bereich verantwortlich sind) begonnen, Blöcke im 5/8-Netzwerk zu verkaufen. Dies war unvermeidlich, da die Anzahl der IPv4-Adressen schnell abnahm, Hamachi diesen Block jedoch weiterhin verwendet.

Wenn Sie auf Dienste in diesem Bereich zugreifen möchten, müssen Sie hamachi deinstallieren - oder zumindest deaktivieren, während Sie auf diese Blöcke zugreifen. Sie können die Route auch jedes Mal manuell löschen.

Die eigentliche Lösung besteht darin, dass hamachi einen Block kauft, zu dessen Verwendung es berechtigt ist, oder zu ipv6 wechselt.


Die Deinstallation von hamachi hat das Problem behoben. tolle Erklärung. Das ist genau das, wonach ich gesucht habe.
Peter Meth

3

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 möglich), und ich kann jetzt ohne Probleme darauf zugreifen und gleichzeitig meine Büro- und Heimcomputer weiterhin verbunden halten.

Um zu IPv6 zu wechseln, 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.

Verwenden Sie hier die letzte Hamachi-Client-Version 2.1.0.322 für OSX


guter Punkt. Ich werde es versuchen. Ich habe Hamachi in letzter Zeit nicht viel benutzt, also habe ich seit dem Löschen ohne Hamachi gelebt, aber ich kann sehen, dass ich es eines Tages wieder brauche.
Peter Meth

+1 Vielen Dank für die Standhilfe. Ich habe seit vielen Monaten nach diesem IP 5.xxx-Problem gesucht.
Mike Castro Demaria
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.