Caso específico
Desea hacer ping a la IP fija "más cercana" que no es enrutable cuando el ISP entra en estado de sobrecarga de tráfico. En mi sistema, puedo emular esta situación al fallar la autenticación ADSL. En ese caso, al comparar los resultados traceroute -n
en condiciones normales y anormales, veo que el primer salto a 8.8.8.8 (o cualquier sitio seguramente externo) que no responda es 151.6.68.45, que es parte de la infraestructura de mi ISP.
Al usar esa IP como un host "check-alive" (después de repetir la prueba solo para asegurarme de que está reparada), puedo detectar una anomalía de ISP sin obtener un falso positivo en caso de que ADSL esté bien, pero el enrutamiento de ISP tiene problemas .
Por supuesto, podría usar 8.8.8.8 a propósito , razonando que si no puedo acceder a la infraestructura de Google, no me importa la razón , también podría intentar con el enrutador de respaldo.
Caso general
"Internet está disponible" es una cosa mucho más complicada que simplemente "Es 8.8.8.8 (u otra IP) accesible".
Para una verificación rápida, sucia y no siempre confiable, hacer ping a 8.8.8.8 es bueno. Pero viendo cómo usa una IP numérica en lugar de un nombre de dominio, ya se ha adaptado al hecho de que podría tener conectividad IP y aún "no tener Internet" debido a problemas de DNS.
Un diagnóstico completo tendría que comenzar cerca de su PC.
- consultar la configuración de la red local y recuperar la puerta de enlace y el servidor DNS.
- haga ping a la puerta de enlace. Debería ser accesible. Si no, hay un problema local.
- ejecute un traceroute con TTL corto (en realidad, un traceroute TCP como el proporcionado por hping es mejor) de una dirección seguramente externa, 8.8.8.8 está bien.
- desea ver que, después de su puerta de enlace, algunos nodos adicionales están respondiendo.
Por ejemplo, en Windows XP en casa tengo:
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
Ahora intente hacer ping a DNS. Debería ser accesible. Aún mejor, ejecute una simple verificación de DNS. Para evitar las memorias caché de DNS, a veces uso un dominio que responderá a todas las consultas sin importar qué. Así por ejemplo
$ host randomasdfdsasdqwerty987667.godaddy.com
randomasdfdsasdqwerty987667.godaddy.com has address 97.74.104.201
mientras que si el servidor DNS no es confiable, la misma consulta podría devolver la dirección del portal cautivo para wifi
$ host randomasdfdsasdqwerty987667.godaddy.com
captiveportal.homenet has address 192.168.4.200
o 127.0.0.1, o incluso un error.
En caso de fallas de DNS, puedo probar una ruta de seguimiento de la dirección IP de DNS (o un DNS diferente como los de OpenDNS). Eso no solo me dirá si el problema es el DNS o el ISP, sino que a menudo me permitirá evitar la interrupción.
Si todo va bien en este momento, sé que la conexión funciona, en general; aún puede fallar en algunos sitios. Todo lo que necesito ahora es isup.me
estar despierto :-), luego verificar
http://www.isup.me/www.google.com
http://www.isup.me/mail.google.com
o un sitio como Down Detector me mantendrá informado sobre el "clima de Internet".
En realidad, en mi servidor doméstico hay un caché de Squid y la página de error contiene los últimos datos recuperados con éxito de las estadísticas del sitio, por lo que puedo ver algo como
Google.com is not reachable
STORM ALERT: 12 out of 14 sites are unreachable!
tal como sucedió este último viernes aquí en Italia.