나는이 문제로 인해 어려움을 겪고 있습니다. 이름이나 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
답변1
ham0 인터페이스로 이어지는 5.0.0.0/8 네트워크 경로가 있습니다.
하마치 인터페이스 입니다. Hamachi는 서비스를 시작했을 때 기존 범위와의 충돌을 피하기 위해 5.0.0.0/8 네트워크를 주소 풀로 선택했습니다. 그러나 하마치에는 이 범위가 할당되지 않았습니다.
지난 몇 달 동안 RIPE(이 범위를 담당)는 5/8 네트워크에서 블록 판매를 시작했습니다. 이는 IPv4 주소 수가 빠르게 고갈됨에 따라 불가피한 일이었지만 hamachi는 여전히 이 블록을 사용하고 있습니다.
이 범위의 서비스에 액세스하려면 hamachi를 제거하거나 최소한 해당 블록에 액세스하는 동안 비활성화해야 합니다. 매번 경로를 수동으로 삭제할 수도 있습니다.
실제 해결책은 hamachi가 사용할 수 있는 블록을 구매하거나 ipv6로 전환하는 것입니다.
답변2
대안은 Hamachi 클라이언트를 IPv6으로 전환하는 것입니다.
Mountain Lion 10.8.1(동일 문제, pear.php.net에 액세스할 수 없음)에서 이 작업을 수행했으며 이제 문제 없이 액세스할 수 있으며 동시에 사무실과 집 컴퓨터의 연결을 계속 유지할 수 있습니다.
IPv6으로 전환하려면 "LogMeIn Hamachi > 기본 설정 > 설정 > 고급 설정 > 피어 연결 > IP 프로토콜 모드"로 이동하여 "IPv6 전용"으로 전환하세요. 다시 연결하고 pear.php.net에 액세스해 보세요.
여기서는 마지막 Hamachi 클라이언트 버전인 OSX용 2.1.0.322를 사용합니다.