Cas spécifique
Vous voulez envoyer un ping à l'IP fixe "la plus proche" qui n'est pas routable lorsque le FAI entre en état de surcharge de trafic. Sur mon système, je peux émuler cette situation en faisant échouer l'authentification ADSL. Dans ce cas, en comparant les résultats de traceroute -n dans des conditions normales et anormales, je constate que le premier saut vers 8.8.8.8 (ou tout autre site externe sûr) qui ne répond pas est 151.6.68.45, qui fait partie de l'infrastructure de mon FAI.
En utilisant que IP comme hôte de "vérification de la validité" (après avoir répété le test juste pour être sûr qu'il es ), je peux détecter une anomalie du FAI sans obtenir un faux positif dans le cas où l'ADSL est OK, mais le routage du FAI a des problèmes.
Bien sûr, je pourrais utiliser 8.8.8.8. à dessein en se disant que si je ne peux pas atteindre l'infrastructure de Google, Je ne me soucie pas de la raison je pourrais aussi bien essayer avec le routeur de secours.
Cas général
" l'internet est disponible " est un beaucoup plus complexe que le simple "Est-ce que 8.8.8.8 (ou une autre IP) est accessible".
Pour une vérification rapide, sale et pas toujours fiable, le ping 8.8.8.8 est bon. Mais vu que vous utilisez une adresse IP numérique au lieu d'un nom de domaine, vous avez déjà compris que vous pourriez avoir une connectivité IP. et toujours "pas d'Internet" à cause de problèmes de DNS.
Un diagnostic complet devrait commencer à proximité de votre PC.
- interroger la configuration du réseau local et récupérer la passerelle et le serveur DNS.
- ping la passerelle. Elle devrait être joignable. Si ce n'est pas le cas, il y a un problème local.
- Exécutez un traceroute avec un TTL court (en fait, un traceroute TCP tel que celui fourni par hping est meilleur) d'une adresse externe sûre, 8.8.8.8 est bien.
- vous voulez voir que, après votre passerelle, quelques noeuds supplémentaires répondent.
Par exemple, dans Windows XP à la maison, j'ai :
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
Maintenant, essayez d'envoyer une requête au DNS. Il devrait être joignable. Encore mieux, lancez une vérification DNS simple. Afin d'éviter les caches DNS, j'utilise parfois un domaine qui répond à tous des requêtes, quoi qu'il arrive. Ainsi, par exemple
$ host randomasdfdsasdqwerty987667.godaddy.com
randomasdfdsasdqwerty987667.godaddy.com has address 97.74.104.201
tandis que si le serveur DNS n'est pas fiable, la même requête peut renvoyer l'adresse du portail captif pour le wifi.
$ host randomasdfdsasdqwerty987667.godaddy.com
captiveportal.homenet has address 192.168.4.200
ou 127.0.0.1, ou même une erreur.
En cas d'échec du DNS, je peux essayer un traceroute de l'adresse IP du DNS (ou un DNS différent tel que ceux d'OpenDNS). Cela me permettra non seulement de savoir si le problème vient du DNS ou du FAI, mais aussi de contourner l'interruption.
Si tout se passe bien à ce stade, je sais que la connexion est en état de marche, en général ; elle peut encore échouer pour certains sites. Tout ce dont j'ai besoin maintenant, c'est que isup.me pour être debout :-), puis en vérifiant
http://www.isup.me/www.google.com
http://www.isup.me/mail.google.com
ou un site tel que Détecteur de chute me tiendra informé de la "météo Internet".
En fait, sur mon serveur d'origine, il y a un cache Squid et la page d'erreur contient les dernières données récupérées avec succès à partir des statistiques en aval, donc je peux voir quelque chose comme
Google.com is not reachable
STORM ALERT: 12 out of 14 sites are unreachable!
tout comme c'est arrivé vendredi dernier ici en Italie.
