в настройках DSL соединении через network manager выставил параметр MTU 1492, но все равно некоторые сайты не открывает. Что еще можно сделать?
> в настройках 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 для случаев, когда используются протоколы туннелирования.
выставил значением 1400 не помогает
> выставил значением 1400 не помогаетЗначит ваша проблема лежит вне поля Layer 3 MTU, к тому же, маршрутизаторы кроме опять же случая с установленным DF битом, будут выполнять фрагментацию.
и что же тогда делать в этом случае? Если провайдер рекомендует выставлять значение MTU на 1492
> и что же тогда делать в этом случае? Если провайдер рекомендует выставлять
> значение MTU на 1492Хорошо, давайте в таком случае приступим к поиску вашей неисправности.
Для начала опишите ваши конфигурацию, как именно подключен ваш узел к сети интернет, какая ОС у вас установлена на вашем узле, какое оконечное устройство вы используете для подключения к сети интернет провайдера.
Раз речь идёт о MTU 1492 байта, значит с большой долей вероятности мы говорим о PPPoE протоколе. Чем подробнее вы опишите вашу конфигурацию, тем понятнее будет, куда нам двигаться дальше.
OS - Linux Mint 18.2
сетевая карта Killer Ethernet E2400
network - Ethernet PPPoE
через кабель подключённый к компьютеру
Создал в network manager dsl соединение PPPoE выставил логин и пароль по договору. А также с сайта провайдера рекомендуемое значение MTU 1492 байта
> 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.
например сайты linux.org.ru speedtest.net
пинги идут хорошо до них, а трэйсроуты соединяются но дальше не грузятся
> например сайты linux.org.ru speedtest.net
> пинги идут хорошо до них, а трэйсроуты соединяются но дальше не грузятсяПокажите мне вывод команд, что я написал выше, я проанализирую их.
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 mskool@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 * * *
>[оверквотинг удален]
> 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 интерфейсе.
Но для начала покажите вывод команды, что я написал выше.
~$ 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
> ~$ 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
Пока команда выполняется, введите в командную строку вашего браузера адрес:
После того, как ваш браузер закончит попытки подключится к сайту, нажмите Ctrl+C в консоли, а полученный файл можете разместить на любом удобном вам хостинге или же можете направить мне на почту zanswer сетевой пёс gmail та самая точка com. :)
P/S/ Нет, входить на какие-либо сайты в это время не желательно, если вы при это закроете текущую сессию в браузере и откроете новое окно, то будет совсем хорошо.
при этом MTU=1492
> при этом MTU=1492try with user root
traceroute -I linux.org.ruusually udp is blocked
>> при этом MTU=1492
> try with user root
> traceroute -I linux.org.ru
> usually udp is blockedNot a bad idea, but in my opinion, packet dump would answer to all our questions.
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
>[оверквотинг удален]
> 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.
> в настройках DSL соединении через network manager выставил параметр MTU 1492, но
> все равно некоторые сайты не открывает. Что еще можно сделать?Не теряйте времени, звоните в службу технической поддержки вашего провайдера.
не помогли провайдеры
> в настройках DSL соединении через network manager выставил параметр MTU 1492, но
> все равно некоторые сайты не открывает. Что еще можно сделать?Вам нужен clamp-mss-to-pmtu (см. линк) https://www.opennet.dev/docs/RUS/LARTC/x2657.html
Я уже устанавливал значение MTU=63 байта и это всё равно не помогало и даже 6001 выставлял. Тот же вариант
> Я уже устанавливал значение MTU=63 байта и это всё равно не
> помогало и даже 6001 выставлял. Тот же вариантХм, ну клево, че. Только я про MTU ничего не говорил и по ссылке речь не об MTU. Удачи в настройках.
>> Я уже устанавливал значение MTU=63 байта и это всё равно не
>> помогало и даже 6001 выставлял. Тот же вариант
> Хм, ну клево, че. Только я про MTU ничего не говорил и
> по ссылке речь не об MTU. Удачи в настройках.Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому, если даже он выполнит указанные в статье команды, то они не коснутся TCP SYN сегментов которые будут направленны его узлом.
> Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально
> порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому,
> если даже он выполнит указанные в статье команды, то они не
> коснутся TCP SYN сегментов которые будут направленны его узлом.Вы все правильно говорите. Я немного поторопился - мое изначальное сообщение было направлением, куда копать. Совсем верный вариант должен выглядеть так - http://help.ubuntu.ru/wiki/mtu
>> Эм, может я забыл NetFilter Packet Flow, но мне казалось, что локально
>> порождаемые пакеты проходят только цепочки OUTPUT -> POSTROUTING, минуя FORWARD. Поэтому,
>> если даже он выполнит указанные в статье команды, то они не
>> коснутся TCP SYN сегментов которые будут направленны его узлом.
> Вы все правильно говорите. Я немного поторопился - мое изначальное сообщение было
> направлением, куда копать. Совсем верный вариант должен выглядеть так - http://help.ubuntu.ru/wiki/mtuОтличная ссылка, теперь автор ветки, сможет попробовать данный вариант, хотя я бы всё таки хотел увидеть дамп. :)
~$ 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 3053mskool@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
>[оверквотинг удален]
> 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.
>[оверквотинг удален]
> 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.dev/openforum/vsluhforumID6/2208.html#21
я вам отправил письмо на почтовый ящик в 16:21 МСК
> я вам отправил письмо на почтовый ящик в 16:21 МСКУже смотрю его, как только появятся комментарии, я напишу их следующим сообщением.
буду признателен
>> я вам отправил письмо на почтовый ящик в 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: 1HTTP/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.
Переведу вышенаписанное :)Проблемы с (прозрачным) DPI, установленным вашим ISP.
> Переведу вышенаписанное :)
> Проблемы с (прозрачным) DPI, установленным вашим ISP.Вполне себе вариант, учитывая, что потерь пакетов мы на прошлых этапах не обнаружили.
Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону они не смогли проконсультировать
> Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону
> они не смогли проконсультироватьЗамечательно, учитывая, что у вас Linux узел, он сможет увидеть всю картину своими глазами в любых ракурсах, без необходимости устанавливать дополнительное программное обеспечение.
не помогло. Спец тоже не шарит в этом. Причем на windows 7 всё прекрасно работает и роутинг отличный без ошибок с с примерами тех же сайтов. А у меня всё даже хуже. Сегодняшний переход на нового провайдера ничего не изменил. Всё осталось по прежнему. За одним исключением. openner.ru теперь на новом провайдере тоже не грузится. Теперь из-под VPN только писать. Может в сетевом конфиге что-то не так?
> Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону
> они не смогли проконсультироватьвыставите себе уже нормальный 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
>> Завтра придет спец. Я ему дамп предоставлю. если он разберется. По телефону
>> они не смогли проконсультировать
> выставите себе уже нормальный 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простите не увидел вашего сообщения. А можно это сделать скриптом при загрузке?
> выставите себе уже нормальный MSS, у вас MTU меньше стандартного для ethernetМало - не много. Ничего страшного не должно происходить. А происходит НЁХ из-за кривого transparent proxy у провайдера/ов.
Рабочая гипотеза - в винде 7 стоит автораспознавание прокси в сети, потому она нанюхалась провайдера и использует его прокси в явном виде. В минте эта шняга выключена, да и работает по-другому, потому можно/нужно описать прокси руками.
Без ссылки на прокси у провайдера дикие потери пакетов из-за того, что пытаются сделать transparent, а не получается. С VPN они пока не суются, потому и работает.
> Мало - не много. Ничего страшного не должно происходить. А происходит НЁХ
> из-за кривого transparent proxy у провайдера/ов.
> Рабочая гипотеза - в винде 7 стоит автораспознавание прокси в сети, потому
> она нанюхалась провайдера и использует его прокси в явном виде. В
> минте эта шняга выключена, да и работает по-другому, потому можно/нужно описать
> прокси руками.
> Без ссылки на прокси у провайдера дикие потери пакетов из-за того, что
> пытаются сделать transparent, а не получается. С VPN они пока не
> суются, потому и работает.да я это заметил на 2х провайдерах. пришлось из кладовки маршрутизатор доставать. всё отлично стало. Спасибо. Можно закрыть тему