Você está executando o Hamachi na máquina que não pode se conectar ao semaphoreapp.com?
Se estiver, posso sugerir que você desative o Hamachi e repita a conexão; você pode descobrir mais sobre o bloco Hamachi em:
RESOLVIDO:
O problema é com o cliente hamachi, hamachi é oi-jacking todo o bloco de endereços 5.0.0.0/8
A correção no Mac
Se você puder conectar-se apenas a um pouco da sua rede através do IPv4, essa 'correção' NÃO funcionará para você
-----
Há algumas semanas, comecei a usar um serviço - link Eu acho que eles fizeram alterações no DNS há uma semana e desde então eu não consigo acessar o site da minha máquina Mac OSX Lion (10.7.4) (minha máquina principal de desenvolvimento)
mas eu posso acessar o site de outras máquinas na minha rede
Depois de algumas pesquisas no Google, eu tentei as duas
mas não, contatei semaphoreapp também, mas nada até agora - também de interesse, um dos meus colegas tem exatamente o mesmo problema, não pode acessar via Mac OSX Lion mas pode via máquina windows, trabalhamos remotamente e não estão no mesmo ISP
alguma informação adicional
O Leão (10.7.4) não pode acessar o site
host semaphoreapp.com
semaphoreapp.com has address 5.9.53.16
ping semaphoreapp.com
PING semaphoreapp.com (5.9.53.16): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6
ping: sendto: Host is down
Request timeout for icmp_seq 7
....
traceroute semaphoreapp.com
traceroute to semaphoreapp.com (5.9.53.16), 64 hops max, 52 byte packets
1 * * *
2 * * *
traceroute: sendto: No route to host
3 traceroute: wrote semaphoreapp.com 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote semaphoreapp.com 52 chars, ret=-1
....
e MacMini (10.6.8) podem acessá-lo
host semaphoreapp.com
semaphoreapp.com has address 5.9.53.16
ping semaphoreapp.com
PING semaphoreapp.com (5.9.53.16): 56 data bytes
64 bytes from 5.9.53.16: icmp_seq=0 ttl=44 time=191.458 ms
64 bytes from 5.9.53.16: icmp_seq=1 ttl=44 time=202.923 ms
64 bytes from 5.9.53.16: icmp_seq=2 ttl=44 time=180.746 ms
64 bytes from 5.9.53.16: icmp_seq=3 ttl=44 time=200.616 ms
64 bytes from 5.9.53.16: icmp_seq=4 ttl=44 time=178.818 ms
....
traceroute semaphoreapp.com
traceroute to semaphoreapp.com (5.9.53.16), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 1.677 ms 1.446 ms 1.445 ms
2 * LOCAL ISP 11.957 ms *
3 etc... 10.704 ms 14.183 ms 9.341 ms
4 etc... 32.641 ms 12.147 ms 10.850 ms
5 etc.... 44.205 ms 54.563 ms 36.243 ms
6 vlan139.car1.seattle1.level3.net (4.53.145.165) 50.136 ms 45.873 ms 30.396 ms
7 ae-32-52.ebr2.seattle1.level3.net (4.69.147.182) 31.926 ms 40.507 ms 49.993 ms
8 ae-2-2.ebr2.denver1.level3.net (4.69.132.54) 78.129 ms 59.674 ms 49.905 ms
9 ae-3-3.ebr1.chicago2.level3.net (4.69.132.62) 99.019 ms 82.008 ms 76.074 ms
10 ae-1-100.ebr2.chicago2.level3.net (4.69.132.114) 96.185 ms 75.658 ms 75.662 ms
11 ae-6-6.ebr2.washington12.level3.net (4.69.148.145) 104.322 ms 105.563 ms 118.480 ms
12 ae-5-5.ebr2.washington1.level3.net (4.69.143.221) 93.646 ms 99.423 ms 96.067 ms
13 ae-41-41.ebr2.paris1.level3.net (4.69.137.49) 177.744 ms
ae-44-44.ebr2.paris1.level3.net (4.69.137.61) 199.363 ms 198.405 ms
14 ae-47-47.ebr1.frankfurt1.level3.net (4.69.143.141) 176.876 ms
ae-45-45.ebr1.frankfurt1.level3.net (4.69.143.133) 170.994 ms
ae-46-46.ebr1.frankfurt1.level3.net (4.69.143.137) 177.308 ms
15 ae-61-61.csw1.frankfurt1.level3.net (4.69.140.2) 176.769 ms
ae-91-91.csw4.frankfurt1.level3.net (4.69.140.14) 178.676 ms 173.644 ms
16 ae-2-70.edge7.frankfurt1.level3.net (4.69.154.75) 180.407 ms
ae-3-80.edge7.frankfurt1.level3.net (4.69.154.139) 174.861 ms 176.578 ms
17 as33891-net.edge7.frankfurt1.level3.net (195.16.162.94) 175.448 ms 185.658 ms 177.081 ms
18 hos-bb1.juniper4.rz16.hetzner.de (213.239.240.202) 188.700 ms 190.332 ms 188.196 ms
19 hos-tr4.ex3k14.rz16.hetzner.de (213.239.233.98) 199.632 ms
hos-tr3.ex3k14.rz16.hetzner.de (213.239.233.66) 185.938 ms
hos-tr2.ex3k14.rz16.hetzner.de (213.239.230.34) 182.378 ms
20 * * *
21 * * *
22 * * *
alguma ideia?
EDITAR: adicionando o tcpdump
MacMini (que pode se conectar) durante a execução - ping semaphoreapp.com
sudo tcpdump -v -i en0 dst semaphoreapp.com
Password:
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:33:03.337165 IP (tos 0x0, ttl 64, id 20153, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->3129)!)
192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 0, length 64
17:33:04.337279 IP (tos 0x0, ttl 64, id 26049, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->1a21)!)
192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 1, length 64
17:33:05.337425 IP (tos 0x0, ttl 64, id 47854, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->c4f3)!)
192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 2, length 64
17:33:06.337548 IP (tos 0x0, ttl 64, id 24772, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->1f1e)!)
192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 3, length 64
17:33:07.337670 IP (tos 0x0, ttl 64, id 8171, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->5ff7)!)
192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 4, length 64
17:33:08.337816 IP (tos 0x0, ttl 64, id 35810, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->f3ff)!)
192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 5, length 64
17:33:09.337948 IP (tos 0x0, ttl 64, id 31120, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->652)!)
192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 6, length 64
^C
7 packets captured
1047 packets received by filter
0 packets dropped by kernel
O OSX Lion (não pode se conectar) durante a execução - ping semaphoreapp.com
# wireless
~ $ sudo tcpdump -v -i en1 dst semaphoreapp.com
Password:
tcpdump: listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
262 packets received by filter
0 packets dropped by kernel
e
# wired
~ $ sudo tcpdump -v -i en0 dst semaphoreapp.com
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
219 packets received by filter
0 packets dropped by kernel
acima da saída após Request timeout for icmp_seq 25 ou 30 vezes do ping. Eu não sei muito sobre o tcpdump, mas para mim não parece que os pedidos de ping estão saindo da minha máquina?
Você está executando o Hamachi na máquina que não pode se conectar ao semaphoreapp.com?
Se estiver, posso sugerir que você desative o Hamachi e repita a conexão; você pode descobrir mais sobre o bloco Hamachi em:
A resolução de DNS parece bem, já que você pode resolver o nome para o endereço IP correto. Eu posso acessar o site no Lion e no Mountain Lion.
Você pode tentar reiniciar sua interface de rede.
sudo ifconfig en0 down
sudo ifconfig en0 up
Substituindo en0 pela interface de rede em uso. Use ifconfig sem argumentos para descobrir a interface correta.
Se você estiver usando duas interfaces de rede - sem fio e com fio, por exemplo - isso pode estar causando um problema.
Se você estiver usando uma VPN que possa causar um problema. Basicamente, procure por qualquer maneira na qual a rede na sua caixa Lion possa ser configurada de forma diferente do que em seus outros hosts.
E, por pior que seja, se você não tentou, a reinicialização pode estar em ordem:)
Em Lion dscacheutil -flushcache é tudo o que é necessário para limpar o cache. Se isso não funcionar, pode haver outra coisa no caminho, como proxies ou sistemas com cache DNS próprio, que são o problema. Pode haver pouco que você possa fazer sobre eles além de dar um pouco de tempo.
Se tudo mais falhar, obtenha o endereço IP do site em uma máquina que possa se conectar e tente usá-lo. Em um host compartilhado, você pode não conseguir o site que está procurando, mas pelo menos poderá confirmar a conectividade. Se isso também não levar a lugar algum, você pode ter algo em seu sistema que está bloqueando, portanto, verifique qualquer tipo de aplicativo ou sistema de firewall que você esteja executando.
Sim, eu vi esse problema. Às vezes é um problema de MTU; especificamente detecção de PMTU ...
Você pode acessar outros sites https sem incidentes? Você pode tentar reduzir seu MTU em Preferências do Sistema - > Rede - > Interface - > Avançado - > Hardware - > Configurar manualmente. Talvez configurado para 1460 ou menor em vez do padrão 1500.
Veja também:
Fico feliz que você tenha resolvido seu problema, mas um problema que descobri na rede Mac OSX é que colocar mais de um domínio em uma única linha em seu arquivo / etc / hosts pode fazer com que coisas aleatórias aconteçam com sua pilha de rede. Eu estou esperando que isso possa ajudar os outros que procuram o caminho para essa pergunta.
Então, ao invés de fazer isso:
127.0.0.1 mylocalsite myotherlocalsite localhost eviladnetworksite.com
você deve colocar cada um deles em uma linha sozinhos
127.0.0.1 mylocalsite
127.0.0.1 myotherlocalsite
127.0.0.1 localhost
127.0.0.1 eviladnetworksite.com
Você deve reinicializar após fazer essa alteração para obter uma pilha de rede não corrompida.
Ref: link