Почему-то вдруг стали очень сильно тормозить _часть_ сетевых протоколов: http -- через пень-колоду, но работает; ftp -- ни малейших проблем, 200-250k только так; imap и pop тоже, вроде, нормально. Беда с smtp: письма с атачами по несколько сот кил отправляются по пять-семь минут, иногда отправка вообще не может закончиться. И беда с rdesktop'ом: скорость тоже практически равна нулю. Подключаюсь rdesktop'ом к рабочему серверу; на работе админ клянётся, что проблема точно не у него. Насчёт smtp пытался выяснять с сервисной поддержкой провайдера (отправляю через их smtp-сервер) -- говорят, что тормоза обусловлены какой-то программой с моей стороны. Сколько им ни повторял, что настройки iptables, браузера и почтовика не менялись минимум несколько месяцев, а тормоза появились только сегодня ночью -- без толку: повторяют, что проблема с моей стороны. iptables настраивал по статье "iptables за 10 минут" (т.к. сам в этом ничего не понимаю), настройки вот:
Что бы разобраться что происходит с протоколами, нужно как минимум вести логи. Проверить весь маршрут по которому идут пакеты до выхода из-здания (свичи, хабы, роутеры, кабельная система), канешна же проверить весь установленный софт, иожет действительно что-то мешает. А про smtp, хочу сказать что диктатором отправки почты является smtp-сервер (в вашем случае провайдер), то что вы что-то напортачили мало вероятно. От вас только требуется соединение с провайдером, правильно настроеный фаервол, и настройки от провайдера для соединения с их smtp-сервером.
Отсюда, пожалуйста, поподробнее; я же говорю: я ничего не понимаю в сетевых делах.
(mczim @ Mar 23 2006, в 05:59) писал(а):Проверить весь маршрут по которому идут пакеты до выхода из-здания (свичи, хабы, роутеры, кабельная система), канешна же проверить весь установленный софт, иожет действительно что-то мешает.
Вот в том-то и вопрос, что если бы причина была где-то здесь, то может ли так быть, что тому же ftp оно бы совершенно не мешало?
(mczim @ Mar 23 2006, в 05:59) писал(а):А про smtp, хочу сказать что диктатором отправки почты является smtp-сервер (в вашем случае провайдер), то что вы что-то напортачили мало вероятно. От вас только требуется соединение с провайдером, правильно настроеный фаервол, и настройки от провайдера для соединения с их smtp-сервером.
Отсюда, пожалуйста, поподробнее; я же говорю: я ничего не понимаю в сетевых делах.
(mczim @ Mar 23 2006, в 05:59) писал(а):Проверить весь маршрут по которому идут пакеты до выхода из-здания (свичи, хабы, роутеры, кабельная система), канешна же проверить весь установленный софт, иожет действительно что-то мешает.
Вот в том-то и вопрос, что если бы причина была где-то здесь, то может ли так быть, что тому же ftp оно бы совершенно не мешало?
(mczim @ Mar 23 2006, в 05:59) писал(а):А про smtp, хочу сказать что диктатором отправки почты является smtp-сервер (в вашем случае провайдер), то что вы что-то напортачили мало вероятно. От вас только требуется соединение с провайдером, правильно настроеный фаервол, и настройки от провайдера для соединения с их smtp-сервером.
Вот в том-то и вопрос, что если бы причина была где-то здесь, то может ли так быть, что тому же ftp оно бы совершенно не мешало?
Да может, на собственном опыте проверено. Например клиент не может установить VPN соединение, проверяю ping'ом, сервер отвечает!!!!!!!! Хм...странно, перезагружаю свич, VPN соединяется!
Сейчас проверил smtp к другому серверу -- та же фигня; более того, и при отправке почты через уеб-интерфейс то же самое...
Я немного не то имел ввиду (или не понял ответа).
Вопрос такой: существует ли сервер, при коннекте к которому по двум разным протоколам, один тормозит, а другой нет?
В каждом из нас спит гений... и с каждым днем все крепче...
А, да, это я не понял. Ну вот, например, на mail.posix.ru через smtp отправка тормозит по-страшному (можно сказать, вообще не работает), а получение через pop -- нормально. Попробовал сейчас закачать атач через веб-морду -- через пень-колоду, но в принципе тоже работает (иногда до 5-7к падает скорость). На работу опять же rdesktop так же тормозит (опять читай "не работает"), а по VPN'у к прокси подключаюсь без проблем, и проксируется всё нормально.
А, да, это я не понял. Ну вот, например, на mail.posix.ru через smtp отправка тормозит по-страшному (можно сказать, вообще не работает), а получение через pop -- нормально. Попробовал сейчас закачать атач через веб-морду -- через пень-колоду, но в принципе тоже работает (иногда до 5-7к падает скорость). На работу опять же rdesktop так же тормозит (опять читай "не работает"), а по VPN'у к прокси подключаюсь без проблем, и проксируется всё нормально.
Да, вот это действительно странно...
Тогда можно попробовать telnet-ом покачать почту от и к mail.posix.ru.
Если нужно - могу сказать как.
Если в ручную все будет ОК, значит подглючивает мыльный клиент - если тормоза - то скорее всего сам сервер.
Есть правда еще вариант, что у Вас стоит selinux. Стоит?
В каждом из нас спит гений... и с каждым днем все крепче...
Прогнал я, что через веб-морду всё нормально. То слишком маленький атач оказался; сейчас надо было отослать побольше -- после 50к скорость отправки стала меньше 1к. И закачка по http после этого почему-то тоже притормозилась.. хотя это уже может и совпадение.
> telnet smtp.mail.ru 25
Trying 194.67.23.111...
Connected to smtp.mail.ru.
Escape character is '^]'.
220 mail.ru ESMTP Fri, 24 Mar 2006 18:56:54 +0300
HELO <name>
250 mx2.mail.ru Hello flook [195.214.233.10]
MAIL FROM: <name>@mail.ru
250 OK
RCPT TO: email@where.to
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
Message
.
250 OK id=1FMofG-000K3O-00
QUIT
221 mx2.mail.ru closing connection
Connection closed by foreign host.
А вот насчет selinux я бы уточнил. Нужно точно убедиться что его нет.
В каждом из нас спит гений... и с каждым днем все крепче...
Скажем так: из всех пакетов, в описании которых присутствует упоминание SELinux, установлен только libselinux1. Причём есть подозрение, что он был установлен задолго до того, как началась эта история.
Я вот не знаю, поможет ли это в твоей проблеме, но решил все-таки написать!
Короче так!
Есть сеть, клиенты по NAT получали, отсылали почту с вложениями любого объема (сколько ящики принимали).
Но в один день мне пришлось заменить на серваке на внешнем интерфейсе сетевуху 10 мегабит на сотку. В результате перестала отправляться поста с вложениями более 64 кб. Причем обратно шло все нормально! Такая же проблема была со всем, что мы пытались отправить в сеть по любому протоколу.
Пришли провайдеры и начали копаться в серваке. Первым делом подсоединили виндовую тачку и пытались отправить с неё что-нибудь. Та же ерунда.
Тогда они сообразили, что их десятимегабитное устройство несовместимо с новой стамегабиткой и начали ковырять его чтобы прошить. Потом сослались на MTU в моей сетевухе, посоветовали поковырять её, а потом притащили 10-тимегабитку, вставили её в сервак и все заработало как прежде!
Вот я и думаю, может действительно проблема в "разнице размеров буферов сетевух", как они сказали?
Поможет ли в этом случае MTU? Я не знаю! надо пробовать!
(замечено и исправлялось в моей сети): при неправильном значении MTU могут быть проблемы с исходящим траффиком (или его может просто не быть); при совсем неправильном значении MTU даже входящего нормально живого траффика не было. Правда, у меня все соединения к серверу через vpn. Но не смотря на это может стоит проверить MTU?
Если подключение происходит через vpn, возможно, были какие-то изменения на сервере, о которых t.t не в курсе.
Через VPN у меня _только_ прокси. Причём наш админ (с работы) клянётся, что у него ничего не менялось; равно как и сервисная "поддержка" провайдера. Почему поддержка в кавычках -- потому что эти ребята по-моему понимают в этом всём даже меньше меня. По результатамм экспериментов есть подозрение, что канал тормозит в одну сторону, т.е. только по исходящему от меня трафику. Может такое быть? И если да, то опять же кто может быть виноват?
Через VPN у меня _только_ прокси. Причём наш админ (с работы) клянётся, что у него ничего не менялось; равно как и сервисная "поддержка" провайдера. Почему поддержка в кавычках -- потому что эти ребята по-моему понимают в этом всём даже меньше меня. По результатамм экспериментов есть подозрение, что канал тормозит в одну сторону, т.е. только по исходящему от меня трафику. Может такое быть? И если да, то опять же кто может быть виноват?
Проблема только исходящего трафика может быть.
покажи свои параметры mtu и mru из /etc/ppp/options.pptp. А лучше весь.
И давай смотреть, что получится. Вообще, немного смущает пустота твоей папки /etc/ppp. И скажи, какой командой запускаешь pptp-соединение?
После запуска посмотри на всякий случай хоть в тех же процессах, какой конфиг-файл пытается использовать pppd.
Да конфиги по идее не могут влиять -- там же ничего не менялось.
Сейчас поговорил с поддержкой провайдера -- говорят проверяйте кабеля. Посмотрел -- вроде нигде ничего не перекручено, всё нормально держится, и т.п. Может быть из-за кабелей проблема в одну сторону? А то они сами проверять не хотят -- это, грят, услуга платная.
Да конфиги по идее не могут влиять -- там же ничего не менялось.
Сейчас поговорил с поддержкой провайдера -- говорят проверяйте кабеля. Посмотрел -- вроде нигде ничего не перекручено, всё нормально держится, и т.п. Может быть из-за кабелей проблема в одну сторону? А то они сами проверять не хотят -- это, грят, услуга платная.
1. Из-за кабелей проблема "в одну сторону" вполне может быть ("звенит" контакт на передающей линии). Но влиять она будет на все протоколы. Вообще - проблемы в кабельной системе будут одинаково влиять на все протоколы.
2. Вариант с MTU - весьма вероятен. Имеет смысл посмотреть на их текущие значения и попытаться их уменьшить.
3. Провайдер реально может и не знать о проблемах (я имею в виду его типовых сотрудников). Пример - есть у провайдера два маршрутизатора с динамической маршрутизацией. В какой-то момент времени они (маршрутизаторы) решили, что твой трафик пойдет по другому маршруту. А там стоит железка с меньшим MTU. Дежуранты этого, естественно, не видят.
У меня была та же проблема, когда я захотел из другого офиса брать нет по туннелю! Ни почта, ни www не работали. Нормально функционировала только аська! А все уперлось в то, что MTU виртуального устройства было 1476!
Проблема решена. После анализа выяснилось, что тормозит действительно исходящий трафик по всем протоколам. Это было связано с пережатым телевизионным кабелем от разветвителя к модему.
