URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID6
Нить номер: 8443
[ Назад ]

Исходное сообщение
"Проблема с доступом по pop3"

Отправлено hav , 04-Авг-05 15:46 
Есть маршрутизатор Cisco 1721 + модуль WIC-1E в центральном офисе и Cisco 831 в другом (другой город).
Между ними организован туннель для связи двух сетей 192.168.0.0 в центральном офисе и 192.168.2.0 в филиале.
В центральном офисе во внутренней сети стоит почтовый сервер 192.168.0.15, на cisco настроен проброс 110 порта с внешнего IP на почтовый сервер.
Проблема следующая: Если пользователь из филиала пытается забрать почту по pop указывая адрес сервера как 192.168.0.15, т.е. через туннель, то Outlook выдаёт ошибку о невозможности забрать почту и почтовый сервер тоже, о том что превышено время ожидания, соединение разорвано клиентом и так далее. Если же попытаться забрать почту с внешнего адреса, то всё пролетает на ура.
Из-за чего так может быть? Сервер один и тот же, клиент тоже, линии связи теже самые, только в одном случае пакет идёт через туннель, а в другом через интернет...

Содержание

Сообщения в этом обсуждении
"Проблема с доступом по pop3"
Отправлено denn , 04-Авг-05 17:54 
>Есть маршрутизатор Cisco 1721 + модуль WIC-1E в центральном офисе и Cisco
>831 в другом (другой город).
>Между ними организован туннель для связи двух сетей 192.168.0.0 в центральном офисе
>и 192.168.2.0 в филиале.
>В центральном офисе во внутренней сети стоит почтовый сервер 192.168.0.15, на cisco
>настроен проброс 110 порта с внешнего IP на почтовый сервер.
>Проблема следующая: Если пользователь из филиала пытается забрать почту по pop указывая
>адрес сервера как 192.168.0.15, т.е. через туннель, то Outlook выдаёт ошибку
>о невозможности забрать почту и почтовый сервер тоже, о том что
>превышено время ожидания, соединение разорвано клиентом и так далее. Если же
>попытаться забрать почту с внешнего адреса, то всё пролетает на ура.
>
>Из-за чего так может быть? Сервер один и тот же, клиент тоже,
>линии связи теже самые, только в одном случае пакет идёт через
>туннель, а в другом через интернет...

смотри маршрутизацию..
привильно ли идет ответ от сервера?
tcpdump


"Проблема с доступом по pop3"
Отправлено hav , 04-Авг-05 18:40 
В том то всё и дело, что проблемы только с pop. SMTP - без проблем. ICA, RDP работает, домены синхронизируются...

>>Есть маршрутизатор Cisco 1721 + модуль WIC-1E в центральном офисе и Cisco
>>831 в другом (другой город).
>>Между ними организован туннель для связи двух сетей 192.168.0.0 в центральном офисе
>>и 192.168.2.0 в филиале.
>>В центральном офисе во внутренней сети стоит почтовый сервер 192.168.0.15, на cisco
>>настроен проброс 110 порта с внешнего IP на почтовый сервер.
>>Проблема следующая: Если пользователь из филиала пытается забрать почту по pop указывая
>>адрес сервера как 192.168.0.15, т.е. через туннель, то Outlook выдаёт ошибку
>>о невозможности забрать почту и почтовый сервер тоже, о том что
>>превышено время ожидания, соединение разорвано клиентом и так далее. Если же
>>попытаться забрать почту с внешнего адреса, то всё пролетает на ура.
>>
>>Из-за чего так может быть? Сервер один и тот же, клиент тоже,
>>линии связи теже самые, только в одном случае пакет идёт через
>>туннель, а в другом через интернет...
>
>смотри маршрутизацию..
>привильно ли идет ответ от сервера?
>tcpdump



"Проблема с доступом по pop3"
Отправлено Kan , 13-Авг-05 12:02 
>В том то всё и дело, что проблемы только с pop. SMTP

Добрый день1
У меня ситуация примерно таже только у меня не идет RDP  из удаленного филиала. То-же обрыв по таймауту, причем пинг на этот сервак идет нормально, попытка соединения с Терминал сервером происходит на нем вижу утановленно соединения с удаленного адреса.
Может покажещь как у тебя это в конфиге выглядит. Модет я где напутал.


"Проблема с доступом по pop3"
Отправлено hav , 19-Авг-05 16:09 
Решил проблему.
Правда трогал настройки не циски, а сервера.
Напомню схему, может кому поможет или интересно будет, а может кто подскажет как ещё можно было решить проблему.
          Офис            |         Филиал
сеть        |  шлюз       |  сеть          |  шлюз
192.168.0.0   x.x.x.x     |  192.168.4.0   |  y.y.y.y

Между ними настроен обычный ip тунель, без шифрования.
В офисе cisco 1760, в филиале cisco 831.

Проблема следующая:
1. Если из филиала выполнить запрос (делал telnet'ом) на 110 порт почтового сервера в офисе 192.168.0.2 (Windows 2003, MDaemon) и попытаться забрать письмо с вложением или просто большое письмо, то ничего не происходит. Очень долго висит сессия и в конце концов по всем таймаутам отваливается.
2. Если же сделать то же самое, но в качестве адреса почтового сервера указать x.x.x.x (на 1760 настроена переброска 110 порта на внутренний почтовик) то всё пролетает на ура.
3. Маленькие письм, типа subj: test, body: test летают в обоих случаях.

Решение.
Запустил Netmon на w3k и посмотрел, что происходит. Выяснилось следующее:
До определённого момента пакеты ни первого ни второго варинта практически не отличаются, кроме адресов. Видно как начинается пересылка текста письма, во втором варианте она проходит до конца, в первом передается пара-тройка частей, затем ОПЯТЬ начинается передача первого куска и так до бесконечности, пока таймауты не разорвут соединение.
Начал смотреть пакеты более пристально. В 1 варианте у пакетов обнаружил параметр TCP option со значением TCP: Option type = SACK
Далее пошел на сайт Microsoft, почитал http://www.microsoft.com/technet/prodtechnol/windowsserver20...
Где нашел, что: SACK is especially important for connections using large TCP window sizes.
После этого интерес мой к этому возрос :-) и пошёл дальше рыть сайт microsoft. Нашел статью: Description of Windows 2000 and Windows Server 2003 TCP Features - http://support.microsoft.com/?kbid=224829#XSLTH3123121123120.... Из неё было выяснено, что windows при установке использует TCP window size равный 16,384 байт, а затем начинает его по своим алгоритмам подбирать и изменять, что и было видно в NetMon'е. В общем, еще много чего интересного прочитал и решил, что проблема как раз в этом.
Поправил на сервере 192.168.0.2 параметр TCP windows size, сделал его равным 0x4000, заодно это оключило алгоритм подбора этого параметра и ПОЧТА ПОШЛА!!!
УРА.
Так что форум оказался немного :-) не тот...