PfSense для LTE Yota: удаленный сервер закрывает сокет
-
Решили мы побаловаться Йотой. Благо неделю подарили. До того pfsense 2.0.1 (раньше был 1.2.3, но в итоге обновился) работал как прокси squid+роутер, к нему подключена по ethernet точка доступа к wifi, Wan порт - VPN PPTP через этот wifi. И в целом нареканий особых не было.
Подключили модем Йота напрямую (попробовали через 4G роутер, но он с 4G глючит все же). На удивление, интерфейс ue0 после перезагрузки не теряется, как многие писали про фрю. Но в итоге разных тестов и проверок выяснилось, что есть какая-то помеха в tcp протоколе (скорее всего). Дело в том, что многие сервера через какое-то время разрывают соединение, если идет скачивание файла. Загрузил под конец для теста на знакомый FTP сервер образ DVD. Чтобы исключить роутинг, файрволлы и прокси вхожу через SSH на pfsense, запускают ftp-клиент и качаю прямо с pfsense. Так вот этот FTP-сервер ровно через 140сек после начала загрузки рвет сокет, хотя скорость закачивания стабильна и не падает (порядка 9-10Мбит/с). Повторяется стабильно. Аналогично сбрасывает (но через разное время, да и скорость закачки сильно скачет) сервер навитела, при попытке качать карты. И при всем этом с depositfiles качает без проблем до конца в это же самое время…
Есть ощущение, что в tcp как-то считаются окна/буфера или еще что-то неправильно. Особенность LTE это большая скорость загрузки и в 2-3 раза ниже скорость аплинка. И прям ощущение, что удаленный сервер не получает подтверждения чего-то и рвет в итоге сокет. Пробовал играться keep_alive параметрами, пробовал буферами tcp с tunables, не помогает. Не знаю, в какую сторону копать, учитывая, что в стеках я не сильно разбираюсь, лишь с точки зрения программиста, а в линуксоподобных системах совсем юзер. Подозреваю, что где-то есть тюнинг протокола, который мне поможет. Но в какую сторону копать... Если у кого есть идеи, буду признателен.
-
Попробуйте поменять MTU на внешнем интерфейсе в сторону уменьшения. Обычно кратно 4 (4, 8, 16).
-
Пробовал уменьшать, не помогало… Можно, конечно, совсем попробовать занизить...
Я еще думаю, может запретить автоподбор буферов tcp... Или уменьшить их размеры... Т.к. увеличение буфера результата не дало.
Я уже думаю попробовать анализировать время обрыва с помощью tcpdump host х.х.х.х, благо IP могу узнать, откуда качаю...
PS: обнаружился интересный момент. Если машину перезагрузить, то интерфейс ue0 не теряется. А если выключить и включить - то теряется.
Апдейт.
Пробовал поиграть и размерами, и MTU, и MSS. Не помогает. Причем с разными серверами по-разному глючит...
С FTP связь обрывается без видимых причин. Идет штатный обмен пакетами, потом на несколько последних отосланных ACK пакетов та сторона возвращает RST/ACK пакеты, пачкой подряд, повторяя поле SEQ значением из отправленного поля ACK. Соединение тут же разрывается. Как будто на стороне сервера происходит ошибка, но почему-то зависит только от времени, а не от места файла... И винда через йоту качает этот файл без проблем...С сайтом навитела какая-то мистика. Там активно теряются данные и используется SACK. pfSense начинает запрашивать определенный потерянный пакет, но в ответ почему-то потерянные пакеты перестают посылать. Есть ощущение, что окно заполняется (насчитал порядка 50 ответных пакетов с одинаковым ACK), после чего прием пакетов новых прекращается. Рвется сокет, на FYN получаем ответ. А потом через волшебные 140сек после окончания приема пакетов tcpdump'ом приходит тот самый пакет данных с нужным полем SEQ, которого так ждал сокет!
Знакомые админы теряются в догадках и грешат на драйвер CDC во Фре...
-
Знакомые админы теряются в догадках и грешат на драйвер CDC во Фре…
Если бы это было так - в англоязычном форуме была бы подобная информация.
Шейперы/Лимитеры настроены?Йота
http://forum.yotatester.ru/showthread.php?t=1962 -
Если бы это было так - в англоязычном форуме была бы подобная информация.
Шейперы/Лимитеры настроены?А они используют такие модемы активно? Я пробовал насчет LTE поискать форум, что-то и нет ничего. Максимум по фре нашел то, что CDC драйвер не поднимается после рестарта.
Шейперов и лимитеров нет. И шейпить трафик на ue0 pfSense не предлагает, нет в нем интерфейса WAN, если модем воткнуть. Да и чтобы не было зависимости, отключаю даже все правила файрволла, разрешаю все. И потому качаю с pfSense непосредственно, без NAT и роутинга на ней…
Почему грешу на связку с модемом тоже - этот же самый сервер спокойно работает с VPN по WiFi, никаких проблем со скачкой тех же файлов...
Йота
http://forum.yotatester.ru/showthread.php?t=1962Ну у меня время аренды адреса вообще 150сек. :) По крайней мере того, который модем выдает для Фри:
dhclient[2129]: bound to 10.0.0.10 – renewal in 150 seconds.Только увы, не влияет это дело на трафик... не во время обновления проблема происходит.
Во время обновления проблема у роутера 4G, который я купил для избежания порблемы пропадания интерфейса. Вот он реально во время обновления при большой нагрузке встает колом. :) -
Как вариант, посмотрите в сторону вот такой ситуации
Для предотвращения возможной отправки сегментов с порядковым номером, совпадающим с порядковым номером другого, старого сегмента, в TCP используется концепция максимального срока жизни сегмента (MSL, Maximum Segment Lifetime). MSI определяет время, которое должно пройти перед назначением любых порядковых номеров при запуске или восстановлении после сбоя (при котором информация о ранее использовавшихся порядковых номерах теряется). В спецификации TCP указано значение MSL, равное двум минутам. На скорости 100 Мбит/с порядковые номера расходуются за 5,4 минуты, что все равно больше двух минут, определяемых в спецификации TCP (RFC 793).
Ну и поменять значение на более низкое (по умолчанию 30000)
/etc/sysctl.conf
net.inet.tcp.msl=7500 -
Мммм… А чем поможет более низкое значение?
По поводу FTP разобрался, наверное. Но решение, пожалуй, временное. Я еще это проверю. Разрыв на самом деле идет со стороны pfSense. Пока качается файл по вновь созданному сокету, ftp-клиент решает без всяких keepalive закрыть сокет на 21 порт. Я спецом уменьшал keepalive, пробуя заставить коннекты быстрее пробовать посылать что-то в сокет, если проблема возникает. Соответственно вернув паузу в два часа FTP дает качать без обрыва. Карты навитела зависли один раз, но после перезапуска также скачались довольно много, не хватило времени дождаться окончания. Smiley Вот думаю теперь, где найти FTP на 2.5 часа чтобы закачка была...
Сижу изучаю, кто же должен отправлять пакеты keepalive и когда. Я считал, что если сокет молчит, то система по истечении таймаута отправит keepalive пакет для начала. А его в tcpdump нету. сразу RST... Либо их отправляет сервер, но в этом случае не воспринимая параметр keepalive со стороны клиента, так что ли, оставляя у себя 2-часовой таймаут... Хотя может кроме таймаутов еще какие-то настройки повлияли, трудно сказать. Или я таймауты задавал "некрасивые", кто-то их неверно понимает...
PS: поставил pfsense на vmware, к ней же подключил модем йоты. Попробовал качать - более-менее. Ничего не делал, уменьшил в 10 раз все три параметра keepalive - соединение рвется. Причем реально рвется потому, что клиент Ftp закрывает сокет на 21 порт, хотя закачка продолжает идти. В дампе никаких пакетов keepalive, просто обмен обычный, и через пару минут RST со стороны pfsense. Вот интересно все же, как работает этот механизм между двумя хостами...
Апдейт.
Сегодня без всякой йоты тестил. Реально, ftp клиент на pfSense тупо закрывает сокет по истечению паузы keepidle, не отправив ни одного пакета keepidle. Думал, что сервер должен отправлять. Поставил Ftpd. Так вот он тоже тупо отключает клиента пока идет закачка по истечению таймаута keepidle, не оправив ни единого пакета спросить, живо ли соединение! Просто между вируталкой и виндой, никаких потерь пакетов нет, tcpdump стоит на LAN интерфейсе pfSense. регистрирует лишь один пакет с 21-го порта с RST. Я совсем ничего не понимаю. В pfSense, что, отключен keepidle? Но это звучит как бред. Как такое поведение объяснить..? Для получения достаточно уменьшить net.inet.tcp.keepidle до 7200, например, чтобы долго не ждать.Апдейт 2
Сделал то же самое на Юбунту. Все работает! Ставим net.ipv4.tcp_keepidle_time=30 вместо 7200, 2-х часов. И что видим:
Если качаем клиентом, то никаких обрывов, никаких пакетов, все работает как надо.
Если Юбунту является FTP-сервером, то раз в 30 сек посылается пустой пакет TCP и соединение не рвется.Что сделать в pfSense, чтобы это работало также?
Апдейт 3
В старой версии pfSense 1.2.3 механизм keepalive также работает верно, ставим 30сек, как часы раз в 30сек обмен по одному пакету клиент-сервер. Придется проверять версии FreeBSD, в них косяк или в сборке pfSense. Временно проблему можно решить путем net.inet.tcp.always_keepalive=0. Тогда и пакетов нет, и таймер не запускается, разрыва нет. Если это косяк FreeBSD, то надо будет большой очень интервал ставить, дабы все время удаленная сторона отправляла keepidle в случае, когда сокет с этим механизмом. -
Да простят меня модераторы, что не дополнил прошлый ответ. Хочу поднять тему.
Установил FreeBSD 8.1. Выставил idletime 5000. Начал качать. И что, пакеты keepalive идут каждые 5 секунд. Что с этим сделали в pfSense? Где найти, как включить механизм обратно?
Есть подозрение на файрволл. Полное его отключение решает половину проблемы - пакеты идут, но таймер не сбрасывается, и соединение в итоге рвется. Несмотря на то, что в файрволле нет никаких правил. Даже добавление правила на WAN "разрешить все и всем" не решает проблему. Никак…
-
Попробуйте:
Firewall Advanced
Firewall Optimization Options
high-latency
used for high latency links, such as satellite links. Expires idle connections later than default -
Пробовал с разными, high-latency, консервативный, даже агрессивный… Я в полном замешательстве. Почему именно сборка pfSense 2.0.1 не работает с keepalive, а все остальные с ним работают правильно, FreeBSD, даже pfSense 1.2.3... Сейчас наделаю логов и попробую спросить в английской части форума. Здесь уже не к Йота тема относится, т.к. все то же самое на обычном проводе и даже по виртуальной сети между виртуалкой и виндой.
Понял, почему фильтрация пакетов отбрасывает keepalive. Каким-то непонятным образом путаются порты в pfSense. Вот кусок лога, первый пакет это последний пакет данных команды mget, через истечение таймаута keepidle (20 сек) должен быть послан пакет. Он посылается, но порты отправителя и получателя поменяли местами! Бред какой-то. Естественно, что на такой пакет возвращается RST, т.к. получатель кривой. В итоге все keepalive пакеты (с периодом отправки 5 сек) отбрасываются и сокет разрывается.```
11:49:28.417148 192.168.178.42.49283 > 192.168.178.20.21: Flags [.], cksum 0x6a0a (correct), seq 82, ack 88, win 520, options [nop,nop,TS val 47239 ecr 126402], length 011:49:48.412106 192.168.178.42.21 > 192.168.178.20.49283: Flags [.], cksum 0x496e (correct), seq 1173739157, ack 4115639386, win 520, length 0
11:49:48.412518 192.168.178.20.49283 > 192.168.178.42.21: Flags [R], cksum 0xc662 (correct), seq 4115639386, win 0, length 011:49:53.411460 192.168.178.42.21 > 192.168.178.20.49283: Flags [.], cksum 0x496e (correct), seq 0, ack 1, win 520, length 0
11:49:53.414050 192.168.178.20.49283 > 192.168.178.42.21: Flags [R], cksum 0xc662 (correct), seq 4115639386, win 0, length 0В pfSense 1.2.3 и что самое интересное во FreeBSD 8.1, на которой собран pfSense 2.0.1, все верно, вот лог с FreeBSD:
15:26:45.712863 192.168.178.44.26215 > 192.168.178.20.ftp: Flags [.], cksum 0xe5b8 (incorrect -> 0x7f7b), seq 90, ack 107, win 8326, options [nop,nop,TS val 29730 ecr 112737], length 0
15:27:05.615989 192.168.178.44.26215 > 192.168.178.20.ftp: Flags [.], cksum 0xe5ac (incorrect -> 0xe518), seq 89, ack 107, win 8326, length 0
15:27:05.616572 192.168.178.20.ftp > 192.168.178.44.26215: Flags [.], cksum 0x9fe1 (correct), seq 107, ack 90, win 65367, options [nop,nop,TS val 112937 ecr 29730], length 015:27:25.623195 192.168.178.44.26215 > 192.168.178.20.ftp: Flags [.], cksum 0xe5ac (incorrect -> 0xe518), seq 89, ack 107, win 8326, length 0
15:27:25.624459 192.168.178.20.ftp > 192.168.178.44.26215: Flags [.], cksum 0x9f19 (correct), seq 107, ack 90, win 65367, options [nop,nop,TS val 113137 ecr 29730], length 0Я капельку урезал строчки лога, убрав заголовок IP, читать проще. Можно еще заметить, что по умолчанию во FreeBSD стоит аппаратное управление чексуммой и пр., и сообщения о некорректной чексумме есть. В pfSense отключаю все аппаратные подсчеты, получается без ошибок.
-
Народ, а кто-нить может проверить на своем pfSense 2.0.1?
Достаточно просто из консоли временно выполнить
sysctl net.inet.tcp.keepidle=20000
sysctl net.inet.tcp.keepintvl=5000
sysctl net.inet.tcp.always_keepalive=1затем просто подключиться к какому-нить серверу ftp, сделать команду dir, подождать 1.5 минуты и снова сделать dir. Например:
ftp ftp.yandex.ru
login: anonymous
password: anonymous
dir
(пауза 1 мин 20 сек)
dirУ меня уже из-за порблем с keepalive прошло отключение:
421 Service not available, remote server has closed connection.Ну и затем выйти из клиента и вернуть все на место
sysctl net.inet.tcp.keepidle=7200000
sysctl net.inet.tcp.keepintvl=75000 -
Решили мы побаловаться Йотой. Благо неделю подарили. До того pfsense 2.0.1 (раньше был 1.2.3, но в итоге обновился) работал как прокси squid+роутер, к нему подключена по ethernet точка доступа к wifi, Wan порт - VPN PPTP через этот wifi. И в целом нареканий особых не было.
Подключили модем Йота напрямую (попробовали через 4G роутер, но он с 4G глючит все же). На удивление, интерфейс ue0 после перезагрузки не теряется, как многие писали про фрю. Но в итоге разных тестов и проверок выяснилось, что есть какая-то помеха в tcp протоколе (скорее всего). Дело в том, что многие сервера через какое-то время разрывают соединение, если идет скачивание файла. Загрузил под конец для теста на знакомый FTP сервер образ DVD. Чтобы исключить роутинг, файрволлы и прокси вхожу через SSH на pfsense, запускают ftp-клиент и качаю прямо с pfsense. Так вот этот FTP-сервер ровно через 140сек после начала загрузки рвет сокет, хотя скорость закачивания стабильна и не падает (порядка 9-10Мбит/с). Повторяется стабильно. Аналогично сбрасывает (но через разное время, да и скорость закачки сильно скачет) сервер навитела, при попытке качать карты. И при всем этом с depositfiles качает без проблем до конца в это же самое время…
Есть ощущение, что в tcp как-то считаются окна/буфера или еще что-то неправильно. Особенность LTE это большая скорость загрузки и в 2-3 раза ниже скорость аплинка. И прям ощущение, что удаленный сервер не получает подтверждения чего-то и рвет в итоге сокет. Пробовал играться keep_alive параметрами, пробовал буферами tcp с tunables, не помогает. Не знаю, в какую сторону копать, учитывая, что в стеках я не сильно разбираюсь, лишь с точки зрения программиста, а в линуксоподобных системах совсем юзер. Подозреваю, что где-то есть тюнинг протокола, который мне поможет. Но в какую сторону копать... Если у кого есть идеи, буду признателен.
Приветствую!
Не затруднит вас рассказать по подробнее про связку pf+Yota(она же ёпта).
Как на страивали, основной ли это внешний канал, как оно вообще работает(стабильнось), какие решения были использованы по усилинею сигнала модема. -
1qoot1, в общем как и просто FreeBSD модем живет только до выключения питания. При перезагрузке не теряет, а при выключении питания да. Работает вполне стабильно, каждые 150сек требуется одновлять по DHCP локальный адрес. 23Мбит с прокси squid вполне, так что уровень сигнала даже и поднимать не надо, модем такое берет под столом аж, на корпусе компа поверх картонной коробки лежит.
Единственно, чего не понимаю, скачать карты навитела не могу нормально, закачка останавливается. Все остальное пока качалось без проблем. А навителовский сайт останавливается очень часто, приходится перезапускать. При этом из виндов по этому же модему качает без остановок… Видимо, как повезет, т.к. однажды и с pfSense скачал за раз 600Мбайт карты.
-
1qoot1, в общем как и просто FreeBSD модем живет только до выключения питания. При перезагрузке не теряет, а при выключении питания да. Работает вполне стабильно, каждые 150сек требуется одновлять по DHCP локальный адрес. 23Мбит с прокси squid вполне, так что уровень сигнала даже и поднимать не надо, модем такое берет под столом аж, на корпусе компа поверх картонной коробки лежит.
Единственно, чего не понимаю, скачать карты навитела не могу нормально, закачка останавливается. Все остальное пока качалось без проблем. А навителовский сайт останавливается очень часто, приходится перезапускать. При этом из виндов по этому же модему качает без остановок… Видимо, как повезет, т.к. однажды и с pfSense скачал за раз 600Мбайт карты.
Сразу оговорюсь, Москва.
Хмм…. Просто стоит задача запустить магазин, из "инета" там оптимальна ёта, но есть ряд НО, качество сигнала там поганое =( за -110dbm переваливает (для нормальной работы необходимо минимум -80dbm), возможно ли попасть на локальный web сервер модема (10.0.0.1) для проверки качества сигнала и другой тех. инфы. за pfS?
К примеру, настроил поставил и забыл... С электричеством там проблем нет + БП, но опять же есть риск того что может выключиться железка... вопрос как быть после перезапуска pfS?
поднимется ли модем без посторонней помощи?Потянет ли модем 2ovpn туннеля + squid + snort + havp + zabbix + (возможно) asterisk?
По скольку не уверен (не тестировал) что сможет, по скольку использую как резервный канал для своего ноута...Если не затруднит, поясните по настройке wan i-face, что да как и куда тыкать))))
-
Из pfS конечно можно попасть на 10.0.0.1. Считайте модем Йоты роутером, который выдает локальный адрес 10.0.0.10 и гейт 10.0.0.1 по умолчанию. И настраивается точно также, как к роутеру.
Модему пофигу VPN и пр, всем шифрованием занимается pfS. С точки зрения потоков - 10 компов на нем сидели, качая что-то или нет, порядка 200-300 подключений в пуле pfS, проблем нет.
Что самое смешное, модем после перезагрузки не теряется, только после обесточивания! Возможно, связано с тем, что делает драйвер при инициализации. Я не пробовал, но приходит на ум мысль воткнуть модем в USB с питанием standby, когда при выключенном компе порт под питанием все равно. Тогда может и выдержит перезагрузки-отключения. Но если пропадет 220В и ИБП отключится, то не поднимется…
Где-то здесь я видел обсуждение, да и на форуме FreeBSD... Но решения нет.
Если это магазин, то думаю, что 1500-2500р лишних найдется, чтобы модем воткнуть в роутер типа dlink 620, перешитый в кинетик, либо купить сам кинетик. Они прекрасно работают с модемом Йота. И будут вам роутером, а pfS обслуживать VPN + прокси.
-
А после кнопки reset устройство теряется?
-
Не пробовал. После shutdown -r now нет.
-
Из pfS конечно можно попасть на 10.0.0.1. Считайте модем Йоты роутером, который выдает локальный адрес 10.0.0.10 и гейт 10.0.0.1 по умолчанию. И настраивается точно также, как к роутеру.
Модему пофигу VPN и пр, всем шифрованием занимается pfS. С точки зрения потоков - 10 компов на нем сидели, качая что-то или нет, порядка 200-300 подключений в пуле pfS, проблем нет.
Что самое смешное, модем после перезагрузки не теряется, только после обесточивания! Возможно, связано с тем, что делает драйвер при инициализации. Я не пробовал, но приходит на ум мысль воткнуть модем в USB с питанием standby, когда при выключенном компе порт под питанием все равно. Тогда может и выдержит перезагрузки-отключения. Но если пропадет 220В и ИБП отключится, то не поднимется…
Где-то здесь я видел обсуждение, да и на форуме FreeBSD... Но решения нет.
Если это магазин, то думаю, что 1500-2500р лишних найдется, чтобы модем воткнуть в роутер типа dlink 620, перешитый в кинетик, либо купить сам кинетик. Они прекрасно работают с модемом Йота. И будут вам роутером, а pfS обслуживать VPN + прокси.
Где-то здесь я видел обсуждение, да и на форуме FreeBSD… Но решения нет.
Печально =(
На счет длинка попробую… Некоторое время использовали "чудесные устройства от компании Drytek...", но по ряду причин отказались... (тупо выкинули бесполезную железку...) так вот, на данный момент модем работает в роутере dir 320 перепрошитый на мотив Yota, но все же качество поганое.... Собственно, вытекает следующий вопрос, есть ли какие нибудь мысли по усилению качества сигнала? Вариант воткнуть модем в активный usb хаб с usb удлинителем, не пойдет =( пробовали...
-
http://www.yotapiter.ru/catalog/antenns_yota/