LINUX.ORG.RU

Ping есть, а интернета нет


0

1

Ping есть на 8.8.8.8, а интернета нет 2 месяца на убунту 12.04.причина?

Plugin passwordfd.so loaded.
AT
OK
ATZ
OK
AT+CGDCONT=1,"IP","internet.smarts.ru"
OK
ATD*99***1#
CONNECT
Serial connection established.
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0
CHAP authentication succeeded
CHAP authentication succeeded
Could not determine remote IP address: defaulting to 10.64.64.64
local  IP address 10.20.135.251
remote IP address 10.64.64.64



Последнее исправление: return12 (всего исправлений: 1)

А пинг по названию домена есть, а не по адресу есть? Например, ping ya.ru

hibou ★★★★★
()

фаервол? маршруты?

P.S. пингом мерить доступность хостов - бить линейкой по рукам

wlan ★★
()
Ответ на: комментарий от i_gnatenko_brain

Ошибка 105 (net::ERR_NAME_NOT_RESOLVED): Не удается преобразовать DNS-адрес сервера.

lo        Link encap:Локальная петля (Loopback)  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1453 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:120233 (120.2 KB)  TX bytes:120233 (120.2 KB)

ppp0      Link encap:Протокол PPP (Point-to-Point Protocol)  
          inet addr:10.20.144.168  P-t-P:10.64.64.64  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:296  Metric:1
          RX packets:37 errors:1 dropped:0 overruns:0 frame:0
          TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:1934 (1.9 KB)  TX bytes:2093 (2.0 KB)
ping google.com
ping: unknown host google.com
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=49 time=43.7 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=49 time=43.7 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=49 time=43.4 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=49 time=43.4 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=49 time=43.1 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=49 time=43.1 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 43.179/43.456/43.751/0.330 ms

return12
() автор топика
Ответ на: комментарий от return12
dig google.com

; <<>> DiG 9.8.1-P1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64478
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.			IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan  2 19:51:02 2013
;; MSG SIZE  rcvd: 28
return12
() автор топика
Ответ на: комментарий от wlan
route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
return12
() автор топика
Ответ на: комментарий от i_gnatenko_brain
 dig google.com @92.43.0.53

; <<>> DiG 9.8.1-P1 <<>> google.com @92.43.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58999
;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		163	IN	A	188.43.66.144
google.com.		163	IN	A	188.43.66.177
google.com.		163	IN	A	188.43.66.159
google.com.		163	IN	A	188.43.66.148
google.com.		163	IN	A	188.43.66.170
google.com.		163	IN	A	188.43.66.181
google.com.		163	IN	A	188.43.66.174
google.com.		163	IN	A	188.43.66.163
google.com.		163	IN	A	188.43.66.154
google.com.		163	IN	A	188.43.66.176
google.com.		163	IN	A	188.43.66.165
google.com.		163	IN	A	188.43.66.155
google.com.		163	IN	A	188.43.66.187
google.com.		163	IN	A	188.43.66.185
google.com.		163	IN	A	188.43.66.152
google.com.		163	IN	A	188.43.66.166

;; AUTHORITY SECTION:
google.com.		156215	IN	NS	ns3.google.com.
google.com.		156215	IN	NS	ns1.google.com.
google.com.		156215	IN	NS	ns4.google.com.
google.com.		156215	IN	NS	ns2.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.		217318	IN	A	216.239.34.10
ns1.google.com.		214811	IN	A	216.239.32.10
ns3.google.com.		217360	IN	A	216.239.36.10
ns4.google.com.		228527	IN	A	216.239.38.10

;; Query time: 4 msec
;; SERVER: 92.43.0.53#53(92.43.0.53)
;; WHEN: Wed Jan  2 20:23:22 2013
;; MSG SIZE  rcvd: 420
return12
() автор топика

Проверь на всякий случай $ grep hosts /etc/nsswitch.conf

А вообще, я так однажды два часа искал проблемы в настройках сети, а всего лишь закончились деньги на счете за интернет. Работал DNS и иногда проходила пара пингов.

TuxR ★★★★
()
Ответ на: комментарий от TuxR
dig google.com @78.24.56.4

; <<>> DiG 9.8.1-P1 <<>> google.com @78.24.56.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63373
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		170	IN	A	173.194.65.139
google.com.		170	IN	A	173.194.65.100
google.com.		170	IN	A	173.194.65.101
google.com.		170	IN	A	173.194.65.102
google.com.		170	IN	A	173.194.65.113
google.com.		170	IN	A	173.194.65.138

;; AUTHORITY SECTION:
google.com.		50210	IN	NS	ns3.google.com.
google.com.		50210	IN	NS	ns4.google.com.
google.com.		50210	IN	NS	ns1.google.com.
google.com.		50210	IN	NS	ns2.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.		151222	IN	A	216.239.32.10
ns2.google.com.		151222	IN	A	216.239.34.10
ns3.google.com.		151222	IN	A	216.239.36.10
ns4.google.com.		151222	IN	A	216.239.38.10

;; Query time: 985 msec
;; SERVER: 78.24.56.4#53(78.24.56.4)
;; WHEN: Wed Jan  2 20:20:29 2013
;; MSG SIZE  rcvd: 260

return12
() автор топика
Ответ на: комментарий от return12
dig google.com @194.84.23.125

; <<>> DiG 9.8.1-P1 <<>> google.com @194.84.23.125
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17583
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.com.			IN	A

;; Query time: 649 msec
;; SERVER: 194.84.23.125#53(194.84.23.125)
;; WHEN: Wed Jan  2 20:22:14 2013
;; MSG SIZE  rcvd: 28
return12
() автор топика
Ответ на: комментарий от return12

вобщем-то у тебя просто неправильные днски по умолсанию работают. попробуй отредактировать /etc/resolv.conf... удалив оттуда 127.0.0.1

i_gnatenko_brain ★★★★
()

Дай угадаю у тебя локальная сетка, а интернет тебе провайдер через vpn даёт?

Dron ★★★★★
()
Ответ на: комментарий от return12

проверил, а suse какие места- нет разницы

return12
() автор топика
Ответ на: комментарий от wlan

P.S. пингом мерить доступность хостов - бить линейкой по рукам

Вах, да у нас тут папа интернета объявился.
Расскажи, папа, для чего же ты ICMP изобрёл, а то я всё мучаюсь этим вопросом, а пока ответа нет, «мерию» доступность LAN тестером

zolden ★★★★★
()
Ответ на: комментарий от zolden

Вопрос не в том, для чего он был изобретен, а в том, как он сейчас используется :)

leave ★★★★★
()
Ответ на: комментарий от zolden

Ну раз ты такой тупенький давай для начала почитаем википедию:

Утилита отправляет запросы (ICMP Echo-Request) протокола ICMP указанному узлу сети и фиксирует поступающие ответы (ICMP Echo-Reply). Время между отправкой запроса и получением ответа (RTT, от англ. Round Trip Time) позволяет определять двусторонние задержки (RTT) по маршруту и частоту потери пакетов, то есть косвенно определять загруженность на каналах передачи данных и промежуточных устройствах.

А теперь для самых маленьких:

Полное отсутствие ICMP-ответов может также означать, что удалённый узел (или какой-либо из промежуточных маршрутизаторов) блокирует ICMP Echo-Reply или игнорирует ICMP Echo-Request.

Выводы тебя мама, надеюсь, делать научила.

wlan ★★
()
Ответ на: комментарий от wlan

Я тебе открою тайну, мальчик выращенный википедией - удалённый хост вообще все твои пакеты (а не только пинги) может игнорировать/дропать.
Страшно тебе жить и работать братюнь, наверно вместо ICMP звонишь напрямую админу каждого хоста, чтобы узнать его состояние.
А, не не, это тоже слишком ненадёжно, ведь оператор связи может твои звонки админу дропать.
Ты, как реальный гуру, просто приходишь в серверную нужного хоста и смотришь.

zolden ★★★★★
()

у моего провайдера днс ломается через день , поставил pdnsd + root dns настройка и рад жизни

hellysmile
()
Ответ на: комментарий от zolden

Википедию я тебе привэл лишь только потому, что ничего сложнее ты понять не сможешь.

Ну подумай уже свои куцым мозгом. Если в доме есть открытая дверь, глупо бросать камни в закрытое окно в надежде, что хозяин выглянет и крикнет тебе что-то. Зайди уже в дверь.

Ты, как реальный гуру, просто приходишь в серверную нужного хоста и смотришь.

Ты хоть раз в серверной был? Ты думаешь там флажки с именами доступных хостов подняты?

wlan ★★
()
Ответ на: комментарий от zolden

Я тебе объяснил почему нельзя определять доступность хостов по пингу. Твоих аргументов я не увидел. Но ты можешь думать всё что угодно.

wlan ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.