Способный Проверить с помощью ping-запросов и Telnet, но не Обзор любой веб-сайт
У меня есть новая установка 14,04. Я не могу просмотреть любой веб-сайт с помощью и браузера Ubuntu и Firefox (единственные браузеры, установленные по умолчанию). Однако, когда я отбрасываю терминал, я могу проверить с помощью ping-запросов все веб-сайты, и я получаю успешное соединение с помощью telnet. Другие компьютеры в сети могут просмотреть без проблемы.
Я испытываю очень похожие проблемы ко Времени соединения во всех браузерах, но ping и работа telnet кроме я не могу просмотреть к своему веб-интерфейсу маршрутизатора также, в отличие от предыдущего плаката.
Я сделал tcpdump, хотя я не действительно уверен, что я ищу. Я действительно вижу, что мой компьютер (10.0.0.23) запрашивает запись с сервера DNS и получает его затем пытающийся соединиться с сервером, но мимо этого я не уверен, на что я смотрю:
11:38:25.938342 IP 10.0.0.23.32925 > 75.75.75.75.53: 15275+ A? www.google.com. (32)
11:38:25.938416 IP 10.0.0.23.32925 > 75.75.76.76.53: 15275+ A? www.google.com. (32)
11:38:25.975842 IP 75.75.75.75.53 > 10.0.0.23.32925: 15275 6/0/0 A 64.233.176.105, A 64.233.176.103, A 64.233.176.106, A 64.233.176.147, A 64.233.176.104, A 64.233.176.99 (128)
11:38:25.976955 IP 10.0.0.23.57541 > 64.233.176.105.80: Flags [S], seq 2691308772, win 29200, options [mss 1460,sackOK,TS val 91559 ecr 0,nop,wscale 7], length 0
11:38:25.998335 IP 75.75.76.76.53 > 10.0.0.23.32925: 15275 5/0/0 A 173.194.37.51, A 173.194.37.52, A 173.194.37.48, A 173.194.37.50, A 173.194.37.49 (112)
11:38:25.998411 IP 10.0.0.23 > 75.75.76.76: ICMP 10.0.0.23 udp port 32925 unreachable, length 148
11:38:26.028372 IP 64.233.176.105.80 > 10.0.0.23.57541: Flags [S.], seq 4291033804, ack 2691308773, win 42540, options [mss 1430,sackOK,TS val 2140513279 ecr 91559,nop,wscale 7], length 0
11:38:26.028456 IP 10.0.0.23.57541 > 64.233.176.105.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 91572 ecr 2140513279], length 0
11:38:26.028815 IP 10.0.0.23.57541 > 64.233.176.105.80: Flags [P.], seq 1:291, ack 1, win 229, options [nop,nop,TS val 91572 ecr 2140513279], length 290
11:38:26.056790 IP 64.233.176.105.80 > 10.0.0.23.57541: Flags [.], ack 291, win 341, options [nop,nop,TS val 2140513334 ecr 91572], length 0
11:38:30.995159 IP6 fe80::5e57:1aff:fed3:ee91 > ff02::1: ICMP6, router advertisement, length 104
11:38:32.966693 IP 10.0.0.1 > 224.0.0.1: igmp query v3 [max resp time 1.0s]
11:38:33.085665 IP 10.0.0.23 > 224.0.0.22: igmp v3 report, 1 group record(s)
11:38:33.108831 IP 10.0.0.15 > 224.0.0.22: igmp v3 report, 3 group record(s)
11:38:33.132271 IP 10.0.0.10 > 224.0.0.22: igmp v3 report, 3 group record(s)
11:38:33.296856 IP 169.254.237.81 > 224.0.0.22: igmp v3 report, 3 group record(s)
11:38:33.337661 IP 10.0.0.23.45440 > 74.125.137.136.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 93400 ecr 2013263489,nop,nop,sack 1 {3928:3929}], length 0
11:38:33.357832 IP 74.125.137.136.443 > 10.0.0.23.45440: Flags [R], seq 1761464578, win 0, length 0
11:38:33.359058 IP 10.0.0.23.34167 > 216.58.216.64.443: Flags [S], seq 2488380, win 29200, options [mss 1460,sackOK,TS val 93405 ecr 0,nop,wscale 7], length 0
11:38:33.402075 IP 216.58.216.64.443 > 10.0.0.23.34167: Flags [S.], seq 3539282909, ack 2488381, win 42540, options [mss 1430,sackOK,TS val 2608512891 ecr 93405,nop,wscale 7], length 0
11:38:33.402158 IP 10.0.0.23.34167 > 216.58.216.64.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 93416 ecr 2608512891], length 0
11:38:33.402789 IP 10.0.0.23.34167 > 216.58.216.64.443: Flags [P.], seq 1:165, ack 1, win 229, options [nop,nop,TS val 93416 ecr 2608512891], length 164
11:38:33.443965 IP 216.58.216.64.443 > 10.0.0.23.34167: Flags [.], ack 165, win 341, options [nop,nop,TS val 2608512935 ecr 93416], length 0
11:38:34.003661 IP6 fe80::5e57:1aff:fed3:ee91 > ff02::1: ICMP6, router advertisement, length 104
11:38:34.297675 IP 10.0.0.23.41148 > 91.189.90.40.80: Flags [F.], seq 0, ack 1, win 229, options [nop,nop,TS val 93640 ecr 2356877716,nop,nop,sack 1 {2459:2460}], length 0
11:38:36.057656 IP 10.0.0.23.57541 > 64.233.176.105.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 94080 ecr 2140513334], length 0
11:38:36.995166 IP6 fe80::5e57:1aff:fed3:ee91 > ff02::1: ICMP6, router advertisement, length 104
11:38:37.057655 IP 10.0.0.23.57541 > 64.233.176.105.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 94330 ecr 2140513334], length 0
11:38:37.083973 IP 64.233.176.105.80 > 10.0.0.23.57541: Flags [.], ack 291, win 341, options [nop,nop,TS val 2140524366 ecr 91572], length 0
11:38:38.342793 IP 10.0.0.15.58164 > 10.0.0.255.32414: UDP, length 21
11:38:39.996784 IP6 fe80::5e57:1aff:fed3:ee91 > ff02::1: ICMP6, router advertisement, length 104
11:38:42.996470 IP6 fe80::5e57:1aff:fed3:ee91 > ff02::1: ICMP6, router advertisement, length 104
11:38:43.344242 IP 10.0.0.15.58164 > 10.0.0.255.32414: UDP, length 21
11:38:43.441646 IP 10.0.0.23.34167 > 216.58.216.64.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 95926 ecr 2608512935], length 0
11:38:43.455840 IP 216.58.216.64.443 > 10.0.0.23.34167: Flags [F.], seq 3927, ack 165, win 341, options [nop,nop,TS val 2608522948 ecr 93416], length 0
11:38:43.455896 IP 10.0.0.23.34167 > 216.58.216.64.443: Flags [.], ack 1, win 229, options [nop,nop,TS val 95929 ecr 2608512935,nop,nop,sack 1 {3927:3928}], length 0
11:38:43.476817 IP 216.58.216.64.443 > 10.0.0.23.34167: Flags [.], ack 165, win 341, options [nop,nop,TS val 2608522968 ecr 93416], length 0
11:38:46.000627 IP6 fe80::5e57:1aff:fed3:ee91 > ff02::1: ICMP6, router advertisement, length 104
11:38:47.097652 IP 10.0.0.23.57541 > 64.233.176.105.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 96840 ecr 2140513334], length 0
11:38:47.117175 IP 64.233.176.105.80 > 10.0.0.23.57541: Flags [.], ack 291, win 341, options [nop,nop,TS val 2140534396 ecr 91572], length 0
11:38:48.349341 IP 10.0.0.15.58164 > 10.0.0.255.32414: UDP, length 21
Вывод от команд ping:
jtsmith2@SmallServer:~$ ping -c 5 google.com
PING google.com (74.125.196.138) 56(84) bytes of data.
64 bytes from yk-in-f139.1e100.net (74.125.196.139): icmp_seq=1 ttl=44 time=26.5 ms
64 bytes from yk-in-f139.1e100.net (74.125.196.139): icmp_seq=2 ttl=44 time=23.5 ms
64 bytes from yk-in-f139.1e100.net (74.125.196.139): icmp_seq=3 ttl=44 time=18.4 ms
64 bytes from yk-in-f139.1e100.net (74.125.196.139): icmp_seq=4 ttl=44 time=17.1 ms
64 bytes from yk-in-f139.1e100.net (74.125.196.139): icmp_seq=5 ttl=44 time=20.0 ms
--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 17.160/21.144/26.523/3.434 ms
и
jtsmith2@SmallServer:~$ ping -c 5 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_seq=1 ttl=57 time=24.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=20.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=19.5 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=16.3 ms
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 16.360/19.942/24.802/2.859 ms
Править:
Я также не могу использовать http через wget:
jtsmith2@SmallServer:~$ wget -v www.google.com/robots.txt
--2015-01-09 12:45:42-- http://www.google.com/robots.txt
Resolving www.google.com (www.google.com)... 64.233.185.147, 64.233.185.99, 64.233.185.103, ...
Connectiong to www.google.com (www.google.com)|64.233.185.147|:80... connected.
HTTP request sent, awaiting response...
и это просто зависает там.
Редактирование № 2 с большим количеством диагностической информации:
jtsmith2@SmallServer:~$ sudo traceroute -n -T -p 80 www.google.com
sudo: traceroute: command not found
jtsmith2@SmallServer:~$ ip route
default via 10.0.0.1 dev wlan0 proto static
10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.23 metric 9
jtsmith2@SmallServer:~$ ip route get 8.8.8.8
8.8.8.8 via 10.0.0.1 dev wlan0 src 10.0.0.23
cache
jtsmith2@SmallServer:~$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr e0:91:53:1a:c2:92
inet addr:10.0.0.23 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 METRIC:1
RX packets:4758 errors:0 dropped:0 overruns:0 frame:0
TX packets:770 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:600533 (600.5 KB) TX bytes:87112 (87.1 KB)
jtsmith2@SmallServer:~$ sudo ping -c3 -Mdo -n -s1472 www.google.com
PING www.google.com (173.194.37.83) 1472(1500) bytes of data.
--- www.google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms
однако приблизительно 10 секунд спустя...
jtsmith2@SmallServer:~$ sudo ping -c3 -Mdo -n -s1472 www.google.com
PING www.google.com (64.233.185.103) 1472(1500) bytes of data.
72 bytes from 64.233.185.103: icmp_seq=1 ttl=44 (truncated)
72 bytes from 64.233.185.103: icmp_seq=2 ttl=44 (truncated)
72 bytes from 64.233.185.103: icmp_seq=3 ttl=44 (truncated)
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 39.738/50.665/72.381/15.357 ms
увеличение одного байта, хотя:
jtsmith2@SmallServer:~$ sudo ping -c3 -Mdo -n -s1473 www.google.com
PING www.google.com (74.125.196.105) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
--- www.google.com ping statistics ---
3 packets transmitted, 0 received, 3+ errors, 100% packet loss, time 1999ms
Любые идеи или решения были бы очень полезны и ценились бы.
1 ответ
Отправьте вывод следующих команд, и я попытаюсь помочь. Легче изменить мой ответ здесь вместо в комментариях.
Проверка путь к www.google.com с помощью TCP traceroute для портирования 80:
sudo traceroute -n -T -p 80 www.google.com
конфигурация маршрутизации:
ip route
интерфейс раньше отправлял пакеты во внешние сети:
ip route get 8.8.8.8
Шоу конфигурация интерфейса Вы видели в выводе команды выше с:
ifconfig <interface>
я особенно интересуюсь информацией о том, какую технологию доступа в Интернет Вы используете.
Иногда при использовании методов доступа, таких как ADSL, VDSL, и т.д. инкапсуляции протокола наверху могут означать, что MTU по умолчанию 1 500 байтов позволит маленьким ответам (таким как пакеты ICMP или простые запросы telnet) возвращаться к машине, но большие ответы будут тихо отброшены, потому что размер ответа + размер заголовков протокола инкапсуляции нескольких слоев превысит MTU.
, Если Вы понимаете понятие MTU и хотите экспериментировать для обнаружения, в какой MTU возможность соединения начинает повреждаться, можно использовать ping в качестве инструмента диагностики и запросить, чтобы никакая фрагментация не была сделана, и пакеты определенного размера отправляются. Пример:
sudo ping -c3 -Mdo -n -s1472 www.google.com
Вышеупомянутое попытается отослать пакеты с 1 472 байтами полезной нагрузки ICMP + 28 байтов заголовков (1500 байтов всего), который, вероятно, перестанет работать. Попытайтесь понизить размер полезной нагрузки путем корректировки-s параметра, пока Вы не начинаете получать ответы и сообщаете мне, каково это.
обновите свой вопрос, и я попытаюсь помочь Вам понять его.
ОБНОВЛЕНИЕ:
Вы могли попробовать команду ниже и видеть, начинает ли просмотр работать впоследствии?
sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o wlan0 -j TCPMSS --set-mss 1460