форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Изначальное сообщение		[ Отслеживать ]

"MTU 1492"	+/–
Сообщение от ego on 26-Сен-17, 07:16
в настройках DSL соединении через network manager выставил параметр MTU 1492, но все равно некоторые сайты не открывает. Что еще можно сделать?
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "MTU 1492"	+/–
Сообщение от zanswer CCNA RS and S on 26-Сен-17, 07:46
> в настройках DSL соединении через network manager выставил параметр MTU 1492, но > все равно некоторые сайты не открывает. Что еще можно сделать? А почему вы установили Layer 3 MTU именно в такое значение и самое главное зачем? Каждый Internet Host RFC 1122: Requirements for Internet Hosts -- Communication Layers, кроме случаев, когда это запрещено или по каким-то причинам блокируется, выполняет Path MTU Discovery, RFC 1191: Path MTU Discovery. Иными словами, узел сам пытается определить максимальный Layer 3 MTU. И всё же, если вы считаете, что проблема у вас с MTU, установите его в значение 1400 байт, рекомендуемое MTU для случаев, когда используются протоколы туннелирования.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 09:31
	выставил значением 1400 не помогает
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 09:47
	> выставил значением 1400 не помогает Значит ваша проблема лежит вне поля Layer 3 MTU, к тому же, маршрутизаторы кроме опять же случая с установленным DF битом, будут выполнять фрагментацию.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 09:53
	и что же тогда делать в этом случае? Если провайдер рекомендует выставлять значение MTU на 1492
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	7. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 10:01
	> и что же тогда делать в этом случае? Если провайдер рекомендует выставлять > значение MTU на 1492 Хорошо, давайте в таком случае приступим к поиску вашей неисправности. Для начала опишите ваши конфигурацию, как именно подключен ваш узел к сети интернет, какая ОС у вас установлена на вашем узле, какое оконечное устройство вы используете для подключения к сети интернет провайдера. Раз речь идёт о MTU 1492 байта, значит с большой долей вероятности мы говорим о PPPoE протоколе. Чем подробнее вы опишите вашу конфигурацию, тем понятнее будет, куда нам двигаться дальше.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 10:09
	OS - Linux Mint 18.2 сетевая карта Killer Ethernet E2400 network - Ethernet PPPoE через кабель подключённый к компьютеру Создал в network manager dsl соединение PPPoE выставил логин и пароль по договору. А также с сайта провайдера рекомендуемое значение MTU 1492 байта
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 10:15
	> OS - Linux Mint 18.2 > сетевая карта Killer Ethernet E2400 > network - Ethernet PPPoE > через кабель подключённый к компьютеру > Создал в network manager dsl соединение PPPoE выставил логин и пароль по > договору. А также с сайта провайдера рекомендуемое значение MTU 1492 байта Замечательно, давайте перейдём теперь к тому, какие именно сайты вам не удаётся открыть, укажите пару таких. И попутно выполните к одному из них команду в вашей консоли: ping dns_address_of_site traceroute dns_address_of_site Делать это само-собой необходимо при подключенном PPPoE соединение, MTU 1492 является стандартным MTU, поэтому установите его, как рекомендует ваш ISP.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 10:44
	например сайты linux.org.ru speedtest.net пинги идут хорошо до них, а трэйсроуты соединяются но дальше не грузятся
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 10:46
	> например сайты linux.org.ru speedtest.net > пинги идут хорошо до них, а трэйсроуты соединяются но дальше не грузятся Покажите мне вывод команд, что я написал выше, я проанализирую их.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 10:57
	kool@hous25:~$ ping linux.org.ru PING linux.org.ru (178.248.233.6) 56(84) bytes of data. 64 bytes from 178.248.233.6: icmp_seq=1 ttl=58 time=31.0 ms 64 bytes from 178.248.233.6: icmp_seq=2 ttl=58 time=31.1 ms ^C --- linux.org.ru ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 31.092/31.124/31.156/0.032 ms kool@hous25:~$ traceroute linux.org.ru traceroute to linux.org.ru (178.248.233.6), 30 hops max, 60 byte packets 1  10.254.253.253 (10.254.253.253)  0.531 ms  0.502 ms  0.647 ms 2  mx480.omkc.ru (217.25.208.197)  0.476 ms  0.615 ms  0.602 ms 3  rt1.omkc.ru (217.25.208.157)  51.538 ms  51.527 ms  51.515 ms 4  omk02.transtelecom.net (188.43.2.66)  1.946 ms  2.137 ms  2.123 ms 5  mskn06.transtelecom.net (188.43.15.238)  30.582 ms  30.571 ms  31.578 ms 6  HLL-gw.transtelecom.net (188.43.15.237)  31.079 ms  30.050 ms  30.947 ms 7  * * * 8  * * * 9  * * * 10  * * * 11  * * * 12  * * * 13  * * * 14  * * * 15  * * * 16  * * * 17  * * * 18  * * * 19  * * * 20  * * * 21  * * * 22  * * * 23  * * * 24  * * * 25  * * * 26  * * * 27  * * * 28  * * * 29  * * * 30  * * *
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	15. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:27
	>[оверквотинг удален] > 21  * * * > 22  * * * > 23  * * * > 24  * * * > 25  * * * > 26  * * * > 27  * * * > 28  * * * > 29  * * * > 30  * * * Отсутствие ответа после 6 HLL-gw.transtelecom.net (188.43.15.237) 31.079 ms 30.050 ms 30.947 ms хопа, уже говорит о том, что проблема лежит вне вашей зоны ответственности. Но, всё же выполните команду: ping -s 1464 linux.org.ru Данная команда сформирует ICMP type 8 code 0 (ICMP Request) заполненный данными расширителями, на столько, чтобы общая сумма ICMP (1464 + 8 байт) + IP (20 байт) + PPPoE (8 байт) = 1500 байт Layer 2 MTU Ethernet интерфейса. Полученный итоговый Ethernet, после добавлении 18 байт заголовка Ethernet будет максимально допустимым для передачи через сеть вашего ISP до NAS, где будет отброшен Ethernet заголовок, а после и PPPoE заголовок. И итоговый IP пакет, который будет направлен с ISP NAS будет равен 1492 байтам. Если в результате мы не увидим ICMP type 0 code 0 (ICMP Reply), значит вы сможете смело обратиться к вашему интернет провайдеру, предоставив ему полученную информацию, поскольку в таком случае, Layer 2 MTU вашего провайдера ниже заявленных в 1500 байт. Если же мы увидим ICMP type 0 code 0 (ICMP Reply), значит проблема кроется на более высоких уровнях, например на транспортном уровне, в таком случае нам понадобится дамп трафика, собранный на PPPoE интерфейсе. Но для начала покажите вывод команды, что я написал выше.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	17. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 11:30
	~$ ping -s 1464 linux.org.ru PING linux.org.ru (178.248.233.6) 1464(1492) bytes of data. 1472 bytes from 178.248.233.6: icmp_seq=1 ttl=58 time=31.3 ms 1472 bytes from 178.248.233.6: icmp_seq=2 ttl=58 time=31.2 ms 1472 bytes from 178.248.233.6: icmp_seq=3 ttl=58 time=31.2 ms ^C --- linux.org.ru ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 31.282/31.301/31.329/0.020 ms
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	21. "MTU 1492"	+1 +/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:43
	> ~$ ping -s 1464 linux.org.ru > PING linux.org.ru (178.248.233.6) 1464(1492) bytes of data. > 1472 bytes from 178.248.233.6: icmp_seq=1 ttl=58 time=31.3 ms > 1472 bytes from 178.248.233.6: icmp_seq=2 ttl=58 time=31.2 ms > 1472 bytes from 178.248.233.6: icmp_seq=3 ttl=58 time=31.2 ms > ^C > --- linux.org.ru ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2002ms > rtt min/avg/max/mdev = 31.282/31.301/31.329/0.020 ms И так, не каких проблем с Layer 3 MTU у нас стало быть нет. Значит пора перейти к более сложной магии, мы будем снимать с вами дамп пакетов с вашего PPPoE интерфейса. Для этого выполните следующую команду: tcpdump -s 0 -i ppp0 (ppp0 нужно заменить на ваш PPPoE интерфейс) -w mycap.pcap Пока команда выполняется, введите в командную строку вашего браузера адрес: https://linux.org.ru После того, как ваш браузер закончит попытки подключится к сайту, нажмите Ctrl+C в консоли, а полученный файл можете разместить на любом удобном вам хостинге или же можете направить мне на почту zanswer сетевой пёс gmail та самая точка com. :) P/S/ Нет, входить на какие-либо сайты в это время не желательно, если вы при это закроете текущую сессию в браузере и откроете новое окно, то будет совсем хорошо.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	19. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 11:34
	при этом MTU=1492
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	20. "MTU 1492"	+/–
	Сообщение от karen durinyan (ok) on 26-Сен-17, 11:37
	> при этом MTU=1492 try with user root traceroute -I linux.org.ru usually udp is blocked
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	22. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:46
	>> при этом MTU=1492 > try with user root > traceroute -I linux.org.ru > usually udp is blocked Not a bad idea, but in my opinion, packet dump would answer to all our questions.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	23. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 11:48
	root@hous25 /home/kool # traceroute -l linux.org.ru Cannot handle `-l' option with arg `linux.org.ru' (argc 2) root@hous25 /home/kool # traceroute -I linux.org.ru traceroute to linux.org.ru (178.248.233.6), 30 hops max, 60 byte packets 1  10.254.253.253 (10.254.253.253)  0.441 ms  0.621 ms  0.617 ms 2  mx480.omkc.ru (217.25.208.197)  0.607 ms  0.604 ms  0.603 ms 3  rt1.omkc.ru (217.25.208.181)  0.796 ms  0.793 ms  0.790 ms 4  omk02.transtelecom.net (188.43.2.66)  1.318 ms  1.745 ms  1.742 ms 5  mskn06.transtelecom.net (188.43.15.238)  31.601 ms  31.599 ms  31.651 ms 6  HLL-gw.transtelecom.net (188.43.15.237)  31.074 ms  30.881 ms  30.854 ms 7  178.248.233.6 (178.248.233.6)  30.835 ms  30.828 ms  30.790 ms
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	25. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:51
	>[оверквотинг удален] >  3  rt1.omkc.ru (217.25.208.181)  0.796 ms  0.793 ms   > 0.790 ms >  4  omk02.transtelecom.net (188.43.2.66)  1.318 ms  1.745 ms   > 1.742 ms >  5  mskn06.transtelecom.net (188.43.15.238)  31.601 ms  31.599 ms   > 31.651 ms >  6  HLL-gw.transtelecom.net (188.43.15.237)  31.074 ms  30.881 ms   > 30.854 ms >  7  178.248.233.6 (178.248.233.6)  30.835 ms  30.828 ms   > 30.790 ms Наличие возможности передачи пакетов показал ещё ICMP ping, поэтому важно понять, что происходит на транспортном уровне с TCP.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

4. "MTU 1492"	+/–
Сообщение от eek (ok) on 26-Сен-17, 09:50
> в настройках DSL соединении через network manager выставил параметр MTU 1492, но > все равно некоторые сайты не открывает. Что еще можно сделать? Не теряйте времени, звоните в службу технической поддержки вашего провайдера.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 09:53
	не помогли провайдеры
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

13. "MTU 1492"	+/–
Сообщение от keir (ok) on 26-Сен-17, 11:14
> в настройках DSL соединении через network manager выставил параметр MTU 1492, но > все равно некоторые сайты не открывает. Что еще можно сделать? Вам нужен clamp-mss-to-pmtu (см. линк) https://www.opennet.me/docs/RUS/LARTC/x2657.html
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 11:19
	Я уже устанавливал значение MTU=63 байта и это всё равно не помогало и даже 6001 выставлял. Тот же вариант
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	16. "MTU 1492"	+/–
	Сообщение от keir (ok) on 26-Сен-17, 11:27
	>  Я уже устанавливал значение MTU=63 байта и это всё равно не > помогало и даже 6001 выставлял. Тот же вариант Хм, ну клево, че. Только я про MTU ничего не говорил и по ссылке речь не об MTU. Удачи в настройках.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	18. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:34
	>>  Я уже устанавливал значение MTU=63 байта и это всё равно не >> помогало и даже 6001 выставлял. Тот же вариант > Хм, ну клево, че. Только я про MTU ничего не говорил и > по ссылке речь не об MTU. Удачи в настройках. Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому, если даже он выполнит указанные в статье команды, то они не коснутся TCP SYN сегментов которые будут направленны его узлом.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	24. "MTU 1492"	+/–
	Сообщение от keir (ok) on 26-Сен-17, 11:50
	> Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально > порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому, > если даже он выполнит указанные в статье команды, то они не > коснутся TCP SYN сегментов которые будут направленны его узлом. Вы все правильно говорите. Я немного поторопился - мое изначальное сообщение было направлением, куда копать. Совсем верный вариант должен выглядеть так - http://help.ubuntu.ru/wiki/mtu
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	26. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 11:54
	>> Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально >> порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому, >> если даже он выполнит указанные в статье команды, то они не >> коснутся TCP SYN сегментов которые будут направленны его узлом. > Вы все правильно говорите. Я немного поторопился - мое изначальное сообщение было > направлением, куда копать. Совсем верный вариант должен выглядеть так - http://help.ubuntu.ru/wiki/mtu Отличная ссылка, теперь автор ветки, сможет попробовать данный вариант, хотя я бы всё таки хотел увидеть дамп. :)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	27. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 12:07
	~$ ping -c 4 -M do -s 1500 ya.ru PING ya.ru (87.250.250.242) 1500(1528) 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 ping: local error: Message too long, mtu=1500 --- ya.ru ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3053ms kool@hous25:~$ ping ya.ru PING ya.ru (87.250.250.242) 56(84) bytes of data. 64 bytes from ya.ru (87.250.250.242): icmp_seq=1 ttl=53 time=40.3 ms 64 bytes from ya.ru (87.250.250.242): icmp_seq=2 ttl=53 time=40.2 ms 64 bytes from ya.ru (87.250.250.242): icmp_seq=3 ttl=53 time=40.5 ms ^C --- ya.ru ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 40.219/40.366/40.517/0.261 ms kool@hous25:~$ tracepatch ya.ru Команда 'tracepatch' не найдена, возможно вы имели в виду: Команда 'tracepath' из пакета 'iputils-tracepath' (main) tracepatch: команда не найдена kool@hous25:~$ tracepath ya.ru 1?: [LOCALHOST]                                         pmtu 1500 1:  no reply 2:  no reply 3:  no reply 4:  no reply 5:  no reply 6:  no reply
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	28. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 12:15
	>[оверквотинг удален] >  1?: [LOCALHOST]           >             >             >          pmtu 1500 >  1:  no reply >  2:  no reply >  3:  no reply >  4:  no reply >  5:  no reply >  6:  no reply Мы уже выяснили, что проблема лежит выше уровнем, чем IP MTU, обратите внимание на это моё сообщение № 21.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	29. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 12:18
	>[оверквотинг удален] >  1?: [LOCALHOST]           >             >             >          pmtu 1500 >  1:  no reply >  2:  no reply >  3:  no reply >  4:  no reply >  5:  no reply >  6:  no reply Адрес моего сообщения: https://www.opennet.me/openforum/vsluhforumID6/2208.html#21
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	30. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 16:21
	я вам отправил письмо на почтовый ящик в 16:21 МСК
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 16:37
	> я вам отправил письмо на почтовый ящик в 16:21 МСК Уже смотрю его, как только появятся комментарии, я напишу их следующим сообщением.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	32. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 17:06
	буду признателен
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	33. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 17:58
	>> я вам отправил письмо на почтовый ящик в 16:21 МСК > Уже смотрю его, как только появятся комментарии, я напишу их следующим сообщением. Некоторые записки по ходу, TCP MSS = 1460 байт, как Receive MSS, так и Send MSS: TCP Option - Maximum segment size: 1460 bytes Ваш узел успешно устанавливает TCP сессию с узлом linux.org.ru по порту 80: 113    0.000000    x.x.x.x    178.248.233.6    TCP    41942 → http(80) [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1415704725 TSecr=0 WS=128 114    0.031953    178.248.233.6    x.x.x.x    TCP    http(80) → 41942 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=3286174551 TSecr=1415704725 WS=512 115    0.000054    x.x.x.x    178.248.233.6    TCP    41942 → http(80) [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1415704733 TSecr=3286174551 Результатом является следующий HTTP обмен: GET / HTTP/1.1 Host: linux.org.ru User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate DNT: 1 Connection: keep-alive Upgrade-Insecure-Requests: 1 HTTP/1.1 302 Found Server: QRATOR Date: Tue, 26 Sep 2017 13:16:33 GMT Content-Length: 0 Connection: keep-alive Keep-Alive: timeout=15 Location: https://www.linux.org.ru/ Как мы видим, узел при этом выполняет перенаправление вас на другой HTTP URI, на HTTPS версию. Что автоматически приводит к инициализации новой TCP сессии с узлом linux.org.ru но уже по порту 443: 128    0.214430    x.x.x.x    178.248.233.6    TCP    51902 → https(443) [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1415704797 TSecr=0 WS=128 129    0.031019    178.248.233.6    x.x.x.x    TCP    https(443) → 51902 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=3286174871 TSecr=1415704797 WS=512 130    0.000030    x.x.x.x    178.248.233.6    TCP    51902 → https(443) [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1415704805 TSecr=3286174871 Далее идёт TLS Client Hello: 131    0.000155    x.x.x.x    178.248.233.6    TLSv1    Client Hello linux.org.ru подтверждает получение данного сегмента: 132    0.031161    178.248.233.6    x.x.x.x    TCP    https(443) → 51902 [ACK] Seq=1 Ack=194 Win=30720 Len=0 TSval=3286174905 TSecr=1415704805 После чего linux.org.ru отвечает нам уже в рамках защищённого соединения, но тут есть нюанс: Обратите внимание, это TCP пакет номер 132, только развёрнутый, обратите внимание на Sequence number: 1 и Acknowledgment number: 194. Internet Protocol Version 4, Src: 178.248.233.6, Dst: x.x.x.x Transmission Control Protocol, Src Port: https (443), Dst Port: 51902 (51902), Seq: 1, Ack: 194, Len: 0     Source Port: https (443)     Destination Port: 51902 (51902)     Sequence number: 1    (relative sequence number)     Acknowledgment number: 194    (relative ack number)     1000 .... = Header Length: 32 bytes (8)     Flags: 0x010 (ACK)     Window size value: 60     Checksum: 0xe04f [unverified]     Urgent pointer: 0     Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps А теперь следующий, пакет под номером 133: 133    0.000491    178.248.233.6    x.x.x.x    SSL    [TCP Previous segment not captured] , Continuation Data Но самое интересно внутри, снова обратите внимание на Sequence number: 2897 и Acknowledgment number: 194. Frame 133: 1268 bytes on wire (10144 bits), 1268 bytes captured (10144 bits) Linux cooked capture Internet Protocol Version 4, Src: 178.248.233.6, Dst: 94.137.13.87 Transmission Control Protocol, Src Port: https (443), Dst Port: 51902 (51902), Seq: 2897, Ack: 194, Len: 1200     Source Port: https (443)     Destination Port: 51902 (51902)     Sequence number: 2897    (relative sequence number)     [Next sequence number: 4097    (relative sequence number)]     Acknowledgment number: 194    (relative ack number)     1000 .... = Header Length: 32 bytes (8)     Flags: 0x018 (PSH, ACK)     Window size value: 60     Checksum: 0x7518 [unverified]     Urgent pointer: 0     Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps     TCP payload (1200 bytes) Secure Sockets Layer При этом размер TCP Payload = 1200 байт! Но, Sequence number уже 2897, это значит, что мы потеряли 1697 байт где-то, при значение нашего Receive MSS = 1460 байт, это значит, что по меньшей мере два сегмента. Дальше мы видим следующую картину, linux.org.ru сообщает нам о том, что он завершает свою часть соединения: 143    4.998799    178.248.233.6    x.x.x.x    TCP    https(443) → 51902 [FIN, PSH, ACK] Seq=4097 Ack=194 Win=30720 Len=646 TSval=3286179905 TSecr=1415704813 Ваш узел какое-то время отправляет тем не менее TCP keep-alive пакеты, поскольку он свою часть соединения не закрывал. 186    10.228250    x.x.x.x    178.248.233.6    TCP    [TCP Keep-Alive] 51902 → https(443) [ACK] Seq=193 Ack=1 Win=33408 Len=0 TSval=1415708620 TSecr=3286174905 SLE=2897 SRE=4744 Но в итоге и он посылает пакет для завершения соединения, причём в виде быстрого завершения соединения, через RST флаг: 220    1.023881    x.x.x.x    178.248.233.6    TCP    51902 → https(443) [RST, ACK] Seq=194 Ack=1 Win=33408 Len=0 TSval=1415709644 TSecr=3286174905 SLE=2897 SRE=4744 И того мы имеем следующую картину, а именно потерю двух TCP сегментов, при этом linux.org.ru узел не получив ACK с подтверждением их получения, не осуществляет их повторную пересылку, а завершает соединение. Но, очевидно, что установить в таком случае полноценное TLS соединение вашему узлу не удаётся, поскольку он не получает полный набор байт, из которых может быть реконструирован Application Layer TLS пакет ядром. По какой причине были потеряны два недостающих TCP сегмента, с точки зрения вашего узла установить не возможно. Можно, было бы установить Receive MSS скажем в 1400 байт, но, как мы выяснили ранее, linux.org.ru прекрасно получает и отправляет обратно ICMP пакеты с Layer 3 PDU размером 1492 байта. При размере Receive MSS равным 1460 байт, мы имеем Layer 3 PDU размером 1490 байт. Отсюда я рекомендую вам открыть повторный кейс у вашего интернет провайдера, вы можете передать им сделанный вами дамп, для анализа или они могут выполнить тестирование собственными силами. P/S/ Можно было бы конечно предположить, что по какой-то причине эти два TCP сегмента не были просто отражены в дампе, но увы, ваш узел подтвердил получение только данного набора байт TCP Option - SACK 2897-4744.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	34. "MTU 1492"	+/–
	Сообщение от universite (ok) on 26-Сен-17, 18:29
	Переведу вышенаписанное :) Проблемы с (прозрачным) DPI, установленным вашим ISP.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	37. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 18:52
	> Переведу вышенаписанное :) > Проблемы с (прозрачным) DPI, установленным вашим ISP. Вполне себе вариант, учитывая, что потерь пакетов мы на прошлых этапах не обнаружили.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	35. "MTU 1492"	+/–
	Сообщение от ego on 26-Сен-17, 18:44
	Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону они не смогли проконсультировать
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	36. "MTU 1492"	+/–
	Сообщение от zanswer CCNA RS and S on 26-Сен-17, 18:50
	> Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону > они не смогли проконсультировать Замечательно, учитывая, что у вас Linux узел, он сможет увидеть всю картину своими глазами в любых ракурсах, без необходимости устанавливать дополнительное программное обеспечение.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	39. "MTU 1492"	+/–
	Сообщение от ego on 28-Сен-17, 20:24
	не помогло. Спец тоже не шарит в этом. Причем на windows 7 всё прекрасно работает и роутинг отличный без ошибок с с примерами тех же сайтов. А у меня всё даже хуже. Сегодняшний переход на нового провайдера ничего не изменил. Всё осталось по прежнему. За одним исключением. openner.ru теперь на новом провайдере тоже не грузится. Теперь из-под VPN только писать. Может в сетевом конфиге что-то не так?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	38. "MTU 1492"	–1 +/–
	Сообщение от Дмитрий (??) on 27-Сен-17, 17:28
	> Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону > они не смогли проконсультировать выставите себе уже нормальный MSS, у вас MTU меньше стандартного для ethernet на 8 байт, iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452 iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	40. "MTU 1492"	+/–
	Сообщение от ego on 28-Сен-17, 20:27
	>> Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону >> они не смогли проконсультировать > выставите себе уже нормальный MSS, у вас MTU меньше стандартного для ethernet > на 8 байт, > iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452 > iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452 простите не увидел вашего сообщения. А можно это сделать скриптом при загрузке?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	41. "MTU 1492"	+/–
	Сообщение от ACCA (ok) on 30-Сен-17, 06:51
	> выставите себе уже нормальный MSS, у вас MTU меньше стандартного для ethernet Мало - не много. Ничего страшного не должно происходить. А происходит НЁХ из-за кривого transparent proxy у провайдера/ов. Рабочая гипотеза - в винде 7 стоит автораспознавание прокси в сети, потому она нанюхалась провайдера и использует его прокси в явном виде. В минте эта шняга выключена, да и работает по-другому, потому можно/нужно описать прокси руками. Без ссылки на прокси у провайдера дикие потери пакетов из-за того, что пытаются сделать transparent, а не получается. С VPN они пока не суются, потому и работает.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	42. "MTU 1492"	+/–
	Сообщение от ego on 01-Окт-17, 08:29
	> Мало - не много. Ничего страшного не должно происходить. А происходит НЁХ > из-за кривого transparent proxy у провайдера/ов. > Рабочая гипотеза - в винде 7 стоит автораспознавание прокси в сети, потому > она нанюхалась провайдера и использует его прокси в явном виде. В > минте эта шняга выключена, да и работает по-другому, потому можно/нужно описать > прокси руками. > Без ссылки на прокси у провайдера дикие потери пакетов из-за того, что > пытаются сделать transparent, а не получается. С VPN они пока не > суются, потому и работает. да я это заметил на 2х провайдерах. пришлось из кладовки маршрутизатор доставать. всё отлично стало. Спасибо. Можно закрыть тему
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема