URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 88851
[ Назад ]
Исходное сообщение
"не грузитса rutracker.org черз NAT "
Отправлено sSpeaker , 30-Апр-10 17:30 
FreeBSD 8.0. Два интерфейса sk0(lan) rl0(wan). mpd5 подымает соединение к провайдеру(ng0)
На ng0 и rl0 запущен NAT. Фаервол практически пуст:

00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00450 divert 8558 ip from any to 10.0.0.0/8 via rl0
00500 divert 8448 ip from any to any via ng0
65535 allow ip from any to any

Скрипт который всё запускает:

#!/bin/sh
/usr/local/etc/rc.d/mpd5 onestart
sleep 15
natd -f /usr/local/etc/natdvpn.conf -n ng0
natd -f /usr/local/etc/natdlan.conf -n rl0
/sbin/ipfw add 450 divert 8558 ip from any to 10.0.0.0/8 via rl0
/sbin/ipfw add 500 divert 8448 ip from any to any via ng0

natdvpn.conf:

port 8448
interface ng0
same_ports yes
unregistered_only yes
dynamic yes

На сервере(через elinks) rutracker грузиться нормально. На клиенте отображается только первая страница с надписью, а редирект не происходит. Также speedtest.net грузиться до половини. все остальные сайты работают. Чего посоветуете?

Содержание
Сообщения в этом обсуждении
"не грузитса rutracker.org черз NAT "
Отправлено Michael , 30-Апр-10 19:31 

>все остальные сайты работают. Чего посоветуете?

mtu

"не грузитса rutracker.org черз NAT "
Отправлено pupseg , 30-Апр-10 21:13 
>[оверквотинг удален]
>
>port 8448
>interface ng0
>same_ports yes
>unregistered_only yes
>dynamic yes
>
>На сервере(через elinks) rutracker грузиться нормально. На клиенте отображается только первая страница
>с надписью, а редирект не происходит. Также speedtest.net грузиться до половини.
>все остальные сайты работают. Чего посоветуете?

может быть MTU ?

"не грузитса rutracker.org черз NAT "
Отправлено sSpeaker , 30-Апр-10 23:33 
>может быть MTU ?

На виндовой машине поставил 1400. На фряхе, на всех интерфейсах, также по 1400.
Если кабель впихнуть в клиента и поднять на нём впн, то всё работает. Походу проблема с натом.

"не грузитса rutracker.org черз NAT "
Отправлено sSpeaker , 02-Май-10 13:00 
ещё варианты будут?


"не грузитса rutracker.org черз NAT "
Отправлено PavelR , 02-Май-10 13:05 
>ещё варианты будут?

Откройте для себя tcpdump, понимание пакетной передачи данных и протоколов TCP/IP.

"не грузитса rutracker.org черз NAT "
Отправлено sSpeaker , 03-Май-10 12:59 
Разобрался. В мпд нужно было "set iface enable tcpmssfix" прописать!
"не грузитса rutracker.org черз NAT "
Отправлено Xaionaro , 15-Май-10 15:31 
>Разобрался. В мпд нужно было "set iface enable tcpmssfix" прописать!

Очень частая проблема... ненавижу таких ISP. А если заглянуть в man iptables, то там вообще такие ISP названы "criminally braindead ISPs".

"не грузитса rutracker.org черз NAT "
Отправлено PavelR , 17-Май-10 07:10 
>>Разобрался. В мпд нужно было "set iface enable tcpmssfix" прописать!
>
>Очень частая проблема... ненавижу таких ISP. А если заглянуть в man iptables,
>то там вообще такие ISP названы "criminally braindead ISPs".

Что еще вы так глубоко ненавидите ?

Попробуйте понять приниципы пакетной передачи данных и принципы инкапсуляции, передачи данных внутри туннелей, которые применяются в PPTP-VPN, потом объясните, каким образом на туннельном интерфейсе, работающем поверх ethernet можно поставить MTU 1500 и как оно будет передавать большие пакеты в этом случае.

Когда разберетесь с этим вопросом и поймете каким образом невозможность сего действия приводит к проблемам с MTU/MSS и в каких случаях это происходит, вот тогда и ненавидьте наздоровье.

Это я к тому, что ISP тут совершенно не при чём, ну разве только что он сам не озаботился _для всех_ включить TCPMSSFIX, чего он делать и не обязан.

"не грузитса rutracker.org черз NAT "
Отправлено rr , 17-Май-10 10:22 
>[оверквотинг удален]
>интерфейсе, работающем поверх ethernet можно поставить MTU 1500 и как оно
>будет передавать большие пакеты в этом случае.
>
>Когда разберетесь с этим вопросом и поймете каким образом невозможность сего действия
>приводит к проблемам с MTU/MSS и в каких случаях это происходит,
>вот тогда и ненавидьте наздоровье.
>
>Это я к тому, что ISP тут совершенно не при чём, ну
>разве только что он сам не озаботился _для всех_ включить TCPMSSFIX,
>чего он делать и не обязан.

Расскажите пожалуйста

"не грузитса rutracker.org черз NAT "
Отправлено PavelR , 17-Май-10 12:06 
>[оверквотинг удален]
>>
>>Когда разберетесь с этим вопросом и поймете каким образом невозможность сего действия
>>приводит к проблемам с MTU/MSS и в каких случаях это происходит,
>>вот тогда и ненавидьте наздоровье.
>>
>>Это я к тому, что ISP тут совершенно не при чём, ну
>>разве только что он сам не озаботился _для всех_ включить TCPMSSFIX,
>>чего он делать и не обязан.
>
>Расскажите пожалуйста

Считаем, что между VPN-сервером и VPN-клиентом ethernet-среда, MTU 1500.
Когда подымаются VPN-соединения, каждый IP-пакет, который должен передаться по этому соединению, передается внутри IP-пакета между VPN-сервером и VPN-клиентом.

Каждый пакет VPN-канала вкладывается в IP пакет между VPN-сервером и VPN-клиентом,
соответственно максимальный размер пакета = MTU 1500 - 40 = 1460, что и будет значением MTU для VPN-интерфейса.

Компы локальной сети подключаются к серверу через тот же самый Ethernet, MTU у них 1500.
Они устанавливают соединение наружу, указывают при этом MSS (максимальный размер IP пакета c данными TCP соединения) исходя из этого значения.

MSS, отправленный клиентом, достигает сервера, к которому производится подключение, и определяет максимальный размер данных, который готов принять клиент.
MSS отправляется и сервером, к которому подключается клиент, соответственно определяет максимальный размер данных, который готов принять сервер.

Максимизировать размер данных внутри пакета требуется для достижения максимально эффективной передачи данных.

При попытке передать данные, маршрутизатор получит пакет максимального размера, отправит его в VPN-интерфейс (завернет в туннель), что добавит к нему IP заголовки, и результирующий пакет уже не сможет быть переданным через внешний физический интерфейс маршрутизатора поскольку MTU 1500 а пакет будет 1540 байт.

Чтобы такого не происходило, производится вмешательство в процедуру установления TCP-соединения и значение MSS ограничивается "более реальным" значением.

При этом всем, если внутри TCP-соединения передаются небольшие порции данных (например короткие команды и маленький результат их выполнения в ssh, интернет-мессенжеры) - проблемы MTU/MSS можно и не заметить.


//Несколько сумбурно и некоторые термины технически неверны, цель мессаги - передать суть.

"не грузитса rutracker.org черз NAT "
Отправлено Xaionaro , 18-Май-10 20:25 
>[оверквотинг удален]
>интерфейсе, работающем поверх ethernet можно поставить MTU 1500 и как оно
>будет передавать большие пакеты в этом случае.
>
>Когда разберетесь с этим вопросом и поймете каким образом невозможность сего действия
>приводит к проблемам с MTU/MSS и в каких случаях это происходит,
>вот тогда и ненавидьте наздоровье.
>
>Это я к тому, что ISP тут совершенно не при чём, ну
>разве только что он сам не озаботился _для всех_ включить TCPMSSFIX,
>чего он делать и не обязан.

AFAIK, TCPMSSFIX требуется только _в тех_ случаях, когда _зачем-то_ блокированы соотвествующие ICMP-пакеты.

А по поводу вашего поста чуть ниже:
1.) Ничего нового я не узнал.
2.) А куда делись следующие вещи: фрагментация на роутерах и PMTU?

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

P.S.: И не надо со мной как с ребёнком. Что такое MSS и зачем оно надо я и без вас знаю.

"не грузитса rutracker.org черз NAT "
Отправлено PavelR , 19-Май-10 09:31 
>AFAIK, TCPMSSFIX требуется только _в тех_ случаях, когда _зачем-то_ блокированы соотвествующие ICMP-пакеты.

Мы живем в реальном, а не идеальном мире.

>2.) А куда делись следующие вещи: фрагментация на роутерах и PMTU?

Роутеры не занимаются фрагментацией, они от этого устают сильно.
Именно для этого MSS и придуман, чтобы роутеры фрагментацией/пересборкой пакетов не занимались.

>Что такое MSS и зачем оно надо я и без вас знаю.

Знание "всего и вся" - это пройдет.

"не грузитса rutracker.org черз NAT "
Отправлено Xaionaro , 19-Май-10 18:55 
>>AFAIK, TCPMSSFIX требуется только _в тех_ случаях, когда _зачем-то_ блокированы соотвествующие ICMP-пакеты.
>
>Мы живем в реальном, а не идеальном мире.

Вот я собственно и интересуюсь, зачем это блокировать? Т.е. даже на соседнего клиента того же ISP нормально за-ssh-иться нельзя. БредЪ.


>>2.) А куда делись следующие вещи: фрагментация на роутерах и PMTU?
>
>Роутеры не занимаются фрагментацией, они от этого устают сильно.

Ну зачем так категорично? Какие-то занимаются, а какие-то нет. А кто как оправдывает почему их роутер этим не занимается - вопрос к администраторам данных роутеров. Например там, где работал я, проблем с перенагрузкой роутеров никогда небыло. А если они есть, то это проблема ISP, а не клиента.

>Именно для этого MSS и придуман, чтобы роутеры фрагментацией/пересборкой пакетов не занимались.

А ещё был придуман PMTU. И если нужные ICMP-пакеты не блокированы то на пути _нормальных_ (с моей точки зрения) ISP никаких проблем с соединением быть не должно.


>>Что такое MSS и зачем оно надо я и без вас знаю.
>
>Знание "всего и вся" - это пройдет.

Ещё раз, но более явно вас прошу. Давайте без этой мании величия. Мне действительно хочется понять вашу позицию, но выслушивать вот эти "знание придёт" я не желаю.

"не грузитса rustrek.ru черз NAT "
Отправлено sword2010 , 02-Июл-10 17:27 
>[оверквотинг удален]
>соединением быть не должно.
>
>
>>>Что такое MSS и зачем оно надо я и без вас знаю.
>>
>>Знание "всего и вся" - это пройдет.
>
>Ещё раз, но более явно вас прошу. Давайте без этой мании величия.
>Мне действительно хочется понять вашу позицию, но выслушивать вот эти "знание
>придёт" я не желаю.

"не грузитса rutracker.org черз NAT "
Отправлено SDenis , 03-Июл-10 14:51 
>[оверквотинг удален]
>интерфейсе, работающем поверх ethernet можно поставить MTU 1500 и как оно
>будет передавать большие пакеты в этом случае.
>
>Когда разберетесь с этим вопросом и поймете каким образом невозможность сего действия
>приводит к проблемам с MTU/MSS и в каких случаях это происходит,
>вот тогда и ненавидьте наздоровье.
>
>Это я к тому, что ISP тут совершенно не при чём, ну
>разве только что он сам не озаботился _для всех_ включить TCPMSSFIX,
>чего он делать и не обязан.

А вам не кажется, что использование нестандартных (отличающиеся от принятых по умолчанию в популярных на сегодняшний день ОС) значений MTU/MCP  в контексте предоставления услуг
доступа к сети является признаком крайней "шаражности" конторы, которая гордо зовет себя "ISP" ?