Конкретний випадок
Ви хочете прописати "найближчий" фіксований IP, який не є маршрутизованим, коли ISP переходить у стан перевантаження трафіку. У моїй системі я можу наслідувати цю ситуацію, відмовивши аутентифікацію 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) доступний".
Для швидкої, брудної та не завжди надійної перевірки добре підходить pinging 8.8.8.8. Але бачачи, як ви використовуєте числовий IP замість доменного імені, ви вже придумали той факт, що у вас може бути IP-зв’язок і все ще "відсутність Інтернету" через проблеми з DNS.
Повна діагностика повинна початися близько до вашого ПК.
- запитувати конфігурацію локальної мережі та отримати шлюз та DNS-сервер.
- ping шлюз. Він повинен бути доступним. Якщо ні, то існує локальна проблема.
- запустити traceroute з коротким TTL (насправді, TCP traceroute, такий як той, який надає 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
Тепер спробуйте pinging DNS. Він повинен бути доступним. Ще краще, запустіть просту перевірку DNS. Щоб уникнути кешів DNS, я іноді використовую деякий домен, який відповість на всі запити незалежно від того. Так, наприклад
$ host randomasdfdsasdqwerty987667.godaddy.com
randomasdfdsasdqwerty987667.godaddy.com has address 97.74.104.201
хоча DNS-сервер ненадійний, той же запит може повернути адресу порталу, що перебуває в положенні, для wifi
$ 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, буде інформувати мене про "погоду в Інтернеті".
Насправді на моєму домашньому сервері є кеш кальмарів, а сторінка помилок містить останні дані, успішно отримані зі статистики вниз, тому я можу побачити щось подібне
Google.com is not reachable
STORM ALERT: 12 out of 14 sites are unreachable!
так, як це сталося минулої п’ятниці тут, в Італії.