이 문제로 인해 혼란에 빠졌습니다. 이름이나 IP로 pear.php.net에 전혀 접근 할 수없는 2 개의 별도 Mac이 있습니다.
이 문제를 해결 / 좁히기 위해 수행 한 증상과 단계는 다음과 같습니다.
$ 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
동일한 네트워크의 Windows PC에서 (나는 심지어 동일한 이더넷 케이블을 사용하여 확인했습니다)
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
- 두 시스템 모두 OSX 10.7을 실행 중입니다.
- 유선 및 Wi-Fi를 모두 시도했지만 동일한 결과
- 다른 네트워크에서 Mac 중 하나를 시도했지만 동일한 결과
- 방화벽을 켜고 끄는 시도, 동일한 결과
- 다른 사이트 / IP에서이 문제가 발생하지 않았습니다
- 브라우저에서 pear.php.net과 5.77.39.20을 모두 열려고 시도했습니다 .404
편집 : Paul의 의견에 대한 답변
$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
답변
ham0 인터페이스로 연결되는 5.0.0.0/8 네트워크 경로가 있습니다.
하마치 인터페이스입니다. Hamachi는 서비스를 시작할 때 기존 범위와의 충돌을 피하기 위해 5.0.0.0/8 네트워크를 주소 풀로 선택했습니다. 그러나 hamachi에는이 범위가 할당되지 않았습니다.
지난 몇 달 동안 RIPE (이 범위를 책임지는 사람)는 5/8 네트워크에서 블록을 판매하기 시작했습니다. ipv4 주소가 빠르게 고갈되면서 이것은 불가피했지만, hamachi는 여전히이 블록을 사용하고 있습니다.
이 범위의 서비스에 액세스하려면 hamachi를 제거하거나 최소한 해당 블록에 액세스하는 동안 hamachi를 비활성화해야합니다. 매번 경로를 수동으로 삭제할 수도 있습니다.
실제 수정은 hamachi가 사용할 수있는 블록을 구매하거나 ipv6으로 전환하는 것입니다.
답변
대안은 Hamachi 클라이언트를 IPv6으로 전환하는 것입니다.
Mountain Lion 10.8.1 (동일한 문제, pear.php.net에 액세스 할 수 없음)에서이 작업을 수행했으며 이제 문제없이 액세스 할 수 있으며 동시에 사무실과 가정용 컴퓨터를 계속 연결 상태로 유지할 수 있습니다.
IPv6으로 전환하려면 “LogMeIn Hamachi> 환경 설정> 설정> 고급 설정> 피어 연결> IP 프로토콜 모드”로 이동하여 “IPv6 전용”으로 전환하십시오. 다시 연결하고 pear.php.net에 액세스하십시오.
여기에서 마지막 Hamachi 클라이언트 버전 사용, OSX 용 2.1.0.322