Caso específico
Você deseja executar ping no IP fixo "mais próximo" que não pode ser roteado quando o ISP entra no estado de sobrecarga de tráfego. No meu sistema, eu posso emular essa situação falhando na autenticação ADSL. Nesse caso, comparando os resultados de traceroute -n
condições normais e anormais, vejo que o primeiro salto para 8.8.8.8 (ou qualquer site certamente externo) que não responda é 151.6.68.45, que faz parte da infraestrutura do meu ISP.
Usando esse IP como um host "check-alive" (depois de repetir o teste apenas para ter certeza de que está corrigido), posso detectar uma anomalia no ISP sem obter um falso positivo, caso o ADSL esteja OK, mas o roteamento do ISP apresenta problemas .
É claro que eu poderia usar o 8.8.8.8 de propósito , argumentando que, se não conseguir acessar a infraestrutura do Google, não me importo com o motivo , mas também com o roteador de backup.
Caso Geral
"Internet está disponível" é uma coisa muito mais complicada do que simplesmente "É 8.8.8.8 (ou outro IP) acessível".
Para uma verificação rápida, suja e nem sempre confiável, executar o ping 8.8.8.8 é bom. Mas, como você usa um IP numérico em vez de um nome de domínio, já percebeu que pode ter conectividade IP e ainda "sem Internet" devido a problemas de DNS.
Um diagnóstico completo teria que começar perto do seu PC.
- consulte a configuração da rede local e recupere o gateway e o servidor DNS.
- execute ping no gateway. Deve ser alcançável. Caso contrário, há um problema local.
- executar um traceroute com TTL curto (na verdade, um traceroute TCP como o fornecido pelo hping é melhor) de um endereço certamente externo, 8.8.8.8 está bom.
- Você deseja ver que, após o seu gateway, alguns nós extras estão respondendo.
Por exemplo, no Windows XP em casa, tenho:
1 <1 ms <1 ms <1 ms 192.168.4.200 -- (constant) Home Linux box (gateway)
2 <1 ms <1 ms <1 ms 192.168.0.1 -- (constant) ADSL modem
3 * * * * -- WAN interface, always fails; expected
4 * 6 ms 6 ms 151.6.64.30 -- (varies) ISP gateway
Agora tente executar ping no DNS. Deve ser alcançável. Melhor ainda, execute uma verificação simples de DNS. Para evitar caches de DNS, às vezes uso um domínio que responde a todas as consultas, não importa o quê. Então por exemplo
$ host randomasdfdsasdqwerty987667.godaddy.com
randomasdfdsasdqwerty987667.godaddy.com has address 97.74.104.201
enquanto o servidor DNS não for confiável, a mesma consulta poderá retornar o endereço do portal cativo para wifi
$ host randomasdfdsasdqwerty987667.godaddy.com
captiveportal.homenet has address 192.168.4.200
ou 127.0.0.1, ou mesmo um erro.
No caso de falhas no DNS, posso tentar um traceroute do endereço IP do DNS (ou um DNS diferente, como o do OpenDNS). Isso não só me diz se o problema é o DNS ou o ISP, como também me permite contornar a interrupção.
Se tudo correr bem neste momento, sei que a conexão está funcionando corretamente, em geral; ainda pode falhar em alguns sites. Tudo o que eu preciso agora é de isup.me
estar acordado :-), depois checando
http://www.isup.me/www.google.com
http://www.isup.me/mail.google.com
ou um site como o Down Detector me manterá informado sobre o "clima da Internet".
Na verdade, no meu servidor doméstico, há um cache do Squid e a página de erro contém os últimos dados recuperados com sucesso das estatísticas do site, portanto, posso ver algo como
Google.com is not reachable
STORM ALERT: 12 out of 14 sites are unreachable!
assim como aconteceu nesta última sexta-feira aqui na Itália.