Przypadek szczególny
Chcesz pingować „najbliższy” stały adres IP, który nie jest routowalny, gdy dostawca usług internetowych wejdzie w stan przeciążenia ruchu. W moim systemie mogę emulować tę sytuację, nie udając uwierzytelnienia ADSL. W takim przypadku, porównując wyniki traceroute -nw warunkach normalnych i anormalnych, widzę, że pierwszy skok do 8.8.8.8 (lub jakakolwiek zewnętrzna strona), który nie odpowiada, to 151,6.68.45, który jest częścią infrastruktury mojego dostawcy usług internetowych.
Używając tego adresu IP jako hosta „sprawdzającego przy życiu” (po powtórzeniu testu, aby upewnić się, że został naprawiony), mogę wykryć anomalię dostawcy usług internetowych bez uzyskiwania fałszywego wyniku na wypadek, gdyby ADSL było OK, ale routing dostawcy usług internetowych ma problemy .
Oczywiście mógłbym celowo użyć wersji 8.8.8.8 , rozumując, że jeśli nie mogę uzyskać dostępu do infrastruktury Google, nie dbam o przyczynę , równie dobrze mogę spróbować z routerem zapasowym.
Ogólna sprawa
„Internet jest dostępny” jest znacznie bardziej skomplikowaną rzeczą niż po prostu „Czy można uzyskać dostęp do 8.8.8.8 (lub innego adresu IP)”.
Dla szybkiego, brudnego i nie zawsze niezawodnego sprawdzania, pingowanie 8.8.8.8 jest dobre. Ale widząc, jak używasz numerycznego adresu IP zamiast nazwy domeny, już zrozumiałeś, że możesz mieć połączenie IP i nadal „nie ma Internetu” z powodu problemów z DNS.
Pełna diagnostyka musiałaby rozpocząć się blisko komputera.
- sprawdzaj konfigurację sieci lokalnej i pobieraj bramę i serwer DNS.
- pingować bramę. Powinien być osiągalny. Jeśli nie, występuje problem lokalny.
- uruchom traceroute z krótkim TTL (w rzeczywistości lepszy jest traceroute TCP taki jak ten dostarczony przez hping) z pewnością zewnętrznego adresu, 8.8.8.8 jest w porządku.
- chcesz zobaczyć, że po bramie niektóre dodatkowe węzły odpowiadają.
Na przykład w systemie Windows XP w domu mam:
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
Teraz spróbuj pingować DNS. Powinien być osiągalny. Co więcej, uruchom proste sprawdzanie DNS. Aby uniknąć pamięci podręcznej DNS, czasami używam domeny, która odpowie na wszystkie zapytania bez względu na wszystko. Na przykład
$ host randomasdfdsasdqwerty987667.godaddy.com
randomasdfdsasdqwerty987667.godaddy.com has address 97.74.104.201
podczas gdy jeśli serwer DNS jest zawodny, to samo zapytanie może zwrócić adres portalu dostępowego dla Wi-Fi
$ host randomasdfdsasdqwerty987667.godaddy.com
captiveportal.homenet has address 192.168.4.200
lub 127.0.0.1, a nawet błąd.
W przypadku awarii DNS mogę wypróbować traceroute adresu IP DNS (lub innego DNS, takiego jak OpenDNS). To nie tylko powie mi, czy problemem jest DNS, czy ISP, ale często pozwoli mi obejść przerwę.
Jeśli w tym momencie wszystko pójdzie dobrze, wiem, że połączenie jest ogólnie sprawne; wciąż może się nie powieść w przypadku niektórych witryn. Teraz muszę isup.metylko wstać :-), a potem sprawdzić
http://www.isup.me/www.google.com
http://www.isup.me/mail.google.com
lub strona taka jak Down Detector informuje mnie o „pogodzie w Internecie”.
Właściwie na moim serwerze domowym jest pamięć podręczna Squid, a strona błędu zawiera ostatnie dane pomyślnie pobrane ze statystyk w dół strony, więc mogę zobaczyć coś takiego
Google.com is not reachable
STORM ALERT: 12 out of 14 sites are unreachable!
tak jak to się stało w ostatni piątek tutaj we Włoszech.