URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 87071
[ Назад ]
Исходное сообщение
"падает соединение, аж противно :)"
Отправлено Vladas , 28-Окт-09 13:57 
Кратенько предистория: жила-была старенькая машинка, которой судьбой было предназначено гнуть спину под линуксом в роли шлюза. С этой целью подкинули ей вторую сетевушку и повесили на нее маленькую локалку (компов эдак с десяток). Инет провайдер выдает по vpn. Изначально установлена была винда и все работало, но от судьбы не уйдешь - второй осью стал CentOS! Под ним тоже все работало, но как только человечек, которому в день приходит много писем (утром приходит порядка 40-90 штук), жмакает "принять почту", канал падает. Видя такое безобразие, попробовал менять MTU. Естественно ничего не помогло, поэтому пришлось грузить опять винду и шлюзить и роутить под ней, т.к. такой бок в ней не наблюдался.
Прошло некоторое время и карма бедной машинки дала о себе снова знать - место CentOS занял Debian. ВЫ НЕ ПОВЕРИТЕ!.. под дебианом та же ситуёвина - человечек жмакает "принять почту" и инет отваливается... Под обоими линухами в логах писало примерно следующее:
localhost pptp[12935]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 66893 (expecting 66658, lost or reordered)
localhost pptp[12935]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 66894 (expecting 66658, lost or reordered)
и т.д.
Спасите! Помогите! Не хочу обратно винду грузить! да и спортивный интерес уже появился :)
Содержание
Сообщения в этом обсуждении
"падает соединение, аж противно :)"
Отправлено PavelR , 28-Окт-09 14:54 

>Видя такое безобразие, попробовал менять MTU.

Его не надо менять. Надо юзать TCPMSSFIX

"падает соединение, аж противно :)"
Отправлено Vladas , 30-Окт-09 11:44 
>Его не надо менять. Надо юзать TCPMSSFIX

спасибо, в iptables прописал, пока вроде не повторялось

"падает соединение, аж противно :)"
Отправлено Vladas , 11-Ноя-09 16:08 
>спасибо, в iptables прописал, пока вроде не повторялось

к сожалению таки не помогло :(
ставил tcpmss и на 40 меньше, чем МТУ (МТУ=1500), и 1300, и даже 1200
при приеме почтовых сообщений валится туннель
в логах ppp-connect-errors откопал еще вот что:
anon warn[open_inetsock:pptp_callmgr.c:329]: connect: Connection timed out
anon fatal[callmgr_main:pptp_callmgr.c:127]: Could not open control connection to <vpn>
anon fatal[open_callmgr:pptp.c:479]: Call manager exited with error 256

а в логах messages пишет:
Nov 10 04:13:40 localhost pppd[2848]: pppd 2.4.4 started by root, uid 0
Nov 10 04:13:40 localhost pppd[2848]: Using interface ppp0
Nov 10 04:13:40 localhost pppd[2848]: Connect: ppp0 <--> /dev/pts/1
Nov 10 04:13:41 localhost pppd[2848]: CHAP authentication succeeded
Nov 10 04:13:41 localhost pppd[2848]: replacing old default route to eth0 [<gateway>]
Nov 10 04:13:41 localhost pppd[2848]: local  IP address <local_ip>
Nov 10 04:13:41 localhost pppd[2848]: remote IP address <remote_ip>
Nov 10 05:56:42 localhost pppd[2848]: No response to 4 echo-requests
Nov 10 05:56:42 localhost pppd[2848]: Serial link appears to be disconnected.
Nov 10 05:56:42 localhost pppd[2848]: Connect time 103.1 minutes.
Nov 10 05:56:42 localhost pppd[2848]: Sent 34944003 bytes, received 688044959 bytes.
Nov 10 05:56:42 localhost pppd[2848]: restoring old default route to eth0 [<gateway>]
Nov 10 05:56:48 localhost pppd[2848]: Connection terminated.
Nov 10 05:56:48 localhost pppd[2848]: Modem hangup

это при MTU=1500 и TCPMSS=1200 на ррр0
могу выложить еще логов, но не знаю в каких еще посмотреть :)

"падает соединение, аж противно :)"
Отправлено isy , 11-Ноя-09 23:33 
У меня была похожая ситуация но linux ни на клиенте а на сервере VPN.
уменьши параметр MTU и MRU до 1000 может даже меньше и посмотри что получится.

"падает соединение, аж противно :)"
Отправлено Vladas , 13-Ноя-09 16:47 
>уменьши параметр MTU и MRU до 1000 может даже меньше и посмотри
>что получится.

не помогло
при mtu ниже 600 работать невозможно
пробовал еще ставить txqueuelen 1000 (по умолчанию для pppX устанавливается в 3)
так же дописал в iptables правило с --clamp-mss-to-pmtu
как подвисало соединение, так и подвисает при приеме почты и что обидно - только из-за одного почтового клиента
что же есть у винды такого, что под ней соединение не рвется?..

"падает соединение, аж противно :)"
Отправлено pavel_simple , 13-Ноя-09 16:50 
>[оверквотинг удален]
>
>не помогло
>при mtu ниже 600 работать невозможно
>пробовал еще ставить txqueuelen 1000 (по умолчанию для pppX устанавливается в 3)
>
>так же дописал в iptables правило с --clamp-mss-to-pmtu
>как подвисало соединение, так и подвисает при приеме почты и что обидно
>- только из-за одного почтового клиента
>что же есть у винды такого, что под ней соединение не рвется?..
>

не трогайте уже mtu если вы используете TCPMSS

полностью сточку с TCPMSS приведите.

"падает соединение, аж противно :)"
Отправлено Vladas , 13-Ноя-09 16:57 
>не трогайте уже mtu если вы используете TCPMSS
>
>полностью сточку с TCPMSS приведите.

вписал iptables -A FORWARD -i ppp0 -p TCP -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

вот вывод для интерфейса с параметрами по умолчанию:

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:<IP_1>  P-t-P:<IP_2>  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1992 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1998 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:606796 (592.5 KiB)  TX bytes:571574 (558.1 KiB)

"падает соединение, аж противно :)"
Отправлено pavel_simple , 13-Ноя-09 17:02 
>[оверквотинг удален]
>          UP POINTOPOINT
>RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>          RX packets:1992
>errors:0 dropped:0 overruns:0 frame:0
>          TX packets:1998
>errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:3
>
>          RX bytes:606796
>(592.5 KiB)  TX bytes:571574 (558.1 KiB)

ну когда-же люди _научаться_ читать маны????


а внём зелёным по чёрно написано
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

разницу видим?

а если не видим то по iptables-save можно ПОНЯТЬ что правила там нет -- потому как модуль
_исключительно_ для таблицы mangle

"падает соединение, аж противно :)"
Отправлено Vladas , 13-Ноя-09 17:22 
>
>а внём зелёным по чёрно написано
>iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS
>--clamp-mss-to-pmtu
>
>разницу видим?
>
>а если не видим то по iptables-save можно ПОНЯТЬ что правила там
>нет -- потому как модуль
>_исключительно_ для таблицы mangle

спасибо, что указали на ошибку, но проблемы это не решило :(

"падает соединение, аж противно :)"
Отправлено новичок , 13-Ноя-09 23:15 
>[оверквотинг удален]
>Nov 10 05:56:42 localhost pppd[2848]: Serial link appears to be disconnected.
>Nov 10 05:56:42 localhost pppd[2848]: Connect time 103.1 minutes.
>Nov 10 05:56:42 localhost pppd[2848]: Sent 34944003 bytes, received 688044959 bytes.
>Nov 10 05:56:42 localhost pppd[2848]: restoring old default route to eth0 [<gateway>]
>Nov 10 05:56:48 localhost pppd[2848]: Connection terminated.
>Nov 10 05:56:48 localhost pppd[2848]: Modem hangup
>
>это при MTU=1500 и TCPMSS=1200 на ррр0
>могу выложить еще логов, но не знаю в каких еще посмотреть :)
>

Если pptp, то у линуксовой реализации многие замечают проблемы под нагрузкой.
Попробуй поставить сетевуху от интела. С ними, вроде бы, получше.

"падает соединение, аж противно :)"
Отправлено strike1984 , 16-Ноя-09 08:11 
Такую же проблему решил на прошлой неделе.
Попробуй поменять сетевую карту.
http://www.opennet.me/openforum/vsluhforumID1/87193.html
"падает соединение, аж противно :)"
Отправлено Vladas , 16-Ноя-09 10:59 
>Такую же проблему решил на прошлой неделе.
>Попробуй поменять сетевую карту.
>http://www.opennet.me/openforum/vsluhforumID1/87193.html

это все понятно и легко реализуемо, но остается открытым вопрос: как винда умудряется нормально работать на тех же сетевухах, решая те же задачи?.. (просто интересно)

"падает соединение, аж противно :)"
Отправлено ALex_hha , 16-Ноя-09 12:20 
>>Такую же проблему решил на прошлой неделе.
>>Попробуй поменять сетевую карту.
>>http://www.opennet.me/openforum/vsluhforumID1/87193.html
>
>это все понятно и легко реализуемо, но остается открытым вопрос: как винда
>умудряется нормально работать на тех же сетевухах, решая те же задачи?..
>(просто интересно)

У линуха довольно таки кривая реализация pptp

"падает соединение, аж противно :)"
Отправлено Vladas , 16-Ноя-09 12:38 
>
>У линуха довольно таки кривая реализация pptp

а у freeBSD с pptp как обстоят дела?

"падает соединение, аж противно :)"
Отправлено Ziggy Stardust , 16-Ноя-09 13:05 
>а у freeBSD с pptp как обстоят дела?

Netgraf + MPD достаточно ровная реализация и pptp, и l2tp, и pppoe.

"падает соединение, аж противно :)"
Отправлено аноним , 17-Ноя-09 14:35 
>а у freeBSD с pptp как обстоят дела?

У FreeBSD с mpd замечательно.

"падает соединение, аж противно :)"
Отправлено новичок , 16-Ноя-09 19:32 
>>Такую же проблему решил на прошлой неделе.
>>Попробуй поменять сетевую карту.
>>http://www.opennet.me/openforum/vsluhforumID1/87193.html
>
>это все понятно и легко реализуемо, но остается открытым вопрос: как винда
>умудряется нормально работать на тех же сетевухах, решая те же задачи?..
>(просто интересно)

Наверное, это обратная сторона использования проприетарных протоколов.


"падает соединение, аж противно :)"
Отправлено Vladas , 17-Ноя-09 12:23 
оригинальностью не отличаюсь, поэтому в результате поисков пока поставил MTU 1400, использую правило с --clamp-mss-to-pmtu и добавил опцию -nobuffer
как-то кривовато, но работает
тем временем буду думать о переезде на BSD

"падает соединение, аж противно :)"
Отправлено аноним , 17-Ноя-09 14:35 
>тем временем буду думать о переезде на BSD

Это самое правильное решение.

"падает соединение, аж противно :)"
Отправлено Alex5 , 22-Мрт-10 16:49 
Была такая же ситуация при запущенном торрен клиенте и болльшом обьеме на скачивание, соединение рвалось через 1-2 минуты
Все решилось добавлением опций pptp --nobuffer --loglevel 0