Особый случай
Вы хотите пропинговать "ближайший" фиксированный IP-адрес, который не маршрутизируется, когда провайдер входит в состояние перегрузки трафика. В моей системе я могу эмулировать эту ситуацию, не пройдя аутентификацию ADSL. В этом случае, сравнивая результаты traceroute -n
в нормальных и ненормальных условиях, я вижу, что первый переход к 8.8.8.8 (или любому другому внешнему сайту), который не отвечает, - 151.6.68.45, который является частью моего провайдера. инфраструктуры.
Используя этот IP в качестве хоста «чек-живого» (после того, как повторить тест , просто чтобы убедиться , что фиксировано), можно обнаружить ISP аномалии без получения ложных срабатываний в случае ADSL в порядке, но маршрутизация ISP имеет проблемы ,
Конечно, я мог бы использовать 8.8.8.8 специально, полагая, что если я не смогу добраться до инфраструктуры Google, меня не волнует причина, я мог бы также попытаться использовать резервный маршрутизатор.
Общий случай
"Интернет доступен" - гораздо более сложная вещь, чем просто «Доступен ли 8.8.8.8 (или другой IP)».
Для быстрой, грязной и не всегда надежной проверки пинг 8.8.8.8 хорош. Но, видя, как вы используете числовой IP вместо доменного имени, вы уже смирились с тем фактом, что у вас может быть IP-соединение и все еще "нет Интернета" из-за проблем с DNS.
Полная диагностика должна начинаться рядом с вашим ПК.
- запросить конфигурацию локальной сети и получить шлюз и DNS-сервер.
- пинг в ворота. Это должно быть достижимо. Если нет, то есть локальная проблема.
- запустить traceroute с коротким TTL (на самом деле лучше использовать трассировку TCP, такую как предоставляемая hping) с несомненно внешним адресом, 8.8.8.8 - это нормально.
- Вы хотите видеть, что после вашего шлюза некоторые дополнительные узлы отвечают.
Например в Windows XP дома у меня есть:
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
Теперь попробуйте пинговать DNS. Это должно быть достижимо. Еще лучше запустить простую проверку DNS. Чтобы избежать кеширования DNS, я иногда использую какой-то домен, который будет отвечать на все запросы, несмотря ни на что. Так например
$ host randomasdfdsasdqwerty987667.godaddy.com
randomasdfdsasdqwerty987667.godaddy.com has address 97.74.104.201
в то время как DNS-сервер ненадежен, тот же запрос может вернуть адрес неавтоматического портала для Wi-Fi
$ host randomasdfdsasdqwerty987667.godaddy.com
captiveportal.homenet has address 192.168.4.200
или 127.0.0.1, или даже ошибка.
В случае сбоев DNS я могу попробовать трассировку IP-адреса DNS (или другого DNS, такого как OpenDNS). Это не только скажет мне, является ли проблема DNS или провайдером, но и позволит мне обойти прерывание.
Если в этот момент все идет хорошо, я знаю, что соединение в целом исправно; это все еще может потерпеть неудачу для некоторых сайтов. Все, что мне нужно сейчас, это чтобы isup.me
был активен :-), затем проверял
http://www.isup.me/www.google.com
http://www.isup.me/mail.google.com
или такой сайт, как Down Detector, будет информировать меня о погоде в Интернете.
На самом деле, на моем домашнем сервере есть кеш Squid, а страница ошибок содержит последние данные, успешно извлеченные из статистики сайта, поэтому я могу увидеть что-то вроде
Google.com is not reachable
STORM ALERT: 12 out of 14 sites are unreachable!
как это случилось в прошлую пятницу здесь, в Италии.