» Kerio Connect (ex Kerio MailServer)

Други помогите. Есть маленькая сетка, на 5 компов, поставил керио коннект, сетка без домена. Смотрю иногда на скринах возникает картинка, где доступ к календарю предоставляют через свойства самого календаря в аутлуке, у меня же таких опций вовсе нет. Единственный способ подключить чужой календарь, это дать доступ через веб-морду к нему, потом в аутлуке в свойствах подключенной учетки мапим эту паблик фолдер (календарь). У юзера соответственно в аутлуке это все выглядит как доп.учетка, где отображается мусорка, и собственно календарь. Не могу понять, почему в свойствах календаря нет опций на расшаривание и опций подключить? Это работает только в случае с доменом? Суть в том, что такой вид подключения не устраивает руководство, основная сетка большая и там юзаем эксч, и календари подчиненных просто идут рядным списком, а тут целая котовасия из списка "левых" учеток подчиненных другой конторы.

Цитата:

[/q]
ghopled

Ну Коннект - это не Эксчендж. А AD для коннекта - это просто вариант авторизации пользователя, не более того.

Добавлено:
[q]

ghopled

Или добавляй календарь через webcal "только для чтения будет" или в общих папках делай календарь, тогда хоть смотреться будет покрасивше.

Я понимаю, что не эксчейндж), я не понимаю, откуда в свойствах календаря в аутлуке у людей в опции присутствуют вкладки доступа к нему, как в обычной сетевой папке, когда мы даем доступ к ней. У меня вообще нет этих вкладок, и нигде не могу найти ответа. на головном сайте все как в рот воды набрали.

maxrsrus
с отключённой сеткой всё летает
по ходу всё из-за обращений юзеров, которые по коффу синкаются

[q][/q]
royansson
Не думаю. У меня 250 человек так работают и ничего не тормозит.
Я бы вырубил на маршрутизатор 25 порт и снова бы проверил.
И ещё, выключили логирование хостов входящих сообщения, на всякий случай.

maxrsrus
логирование и так не было включено
отключил 25 порт на шлюзе и в службах Керио, оставил 465
Админка с локалхоста ожила, веб-морда даже из интрасети - нет
Отключил на шлюзе 465 - ничего не изменилось
UPD:
отключил и SMTPS на Kerio Connect
на удивление открылась почта через web с телефона по 3G. С большим скрипом, но открылась

Используются последние версии Connect и Control.
Почта работает на физической машине под Windows 2008 R2, на которой под VMWare работает Control.
Проблема собственно заключается в пробросе портов почты извне: если в правиле для трансляции включить источник NAT, то всё работает замечательно, но для почтового сервера все подключающиеся извне имеют IP адрес шлюза Control, а если же не включать источник NAT, то наблюдается проблема с получением по SMTP писем от других серверов (gmail, yandex), хотя от некоторых письма приходят.
Последний вариант трансляции без источника NAT предпочтительнее, т.к. почтовый сервер видит реальные адреса внешних клиентов и серверов.
Когда всё работало под Windows на одной машине, то проблем не наблюдалось. В чём может быть проблема и что можно сделать?

YuraseK
Цитата:

В чём может быть проблема и что можно сделать?

Об этом наверняка расскажут там: Клуб телепатов
А здесь принято приводить логи проблемных сессий.

народ, есть такая странность в работе outlook 2010 + KOC. Во входящих потерялось письмо, пришедшее пару дней назад. Знаем что оно точно было и не удаляли. Просматриваем папку - нету. Забиваем часть письма в поиск аутлука, ищем и вуаля - оно появляется откуда-то! И после этого уже не пропадает.

Еще было: создаю, заполняю и сохраняю контакт в адресной аутлука. Иду в контакты, его там нет! Там контактов то было всего штук 5, не заметить я его не мог. И опять - вбиваю его в поиск и вот он появляется.

Ниже кусок лога попытки взаимодействия почтового сервера google с моим почтовым сервером.
Сервера гугла - 209.0.0.0 / 255.0.0.0
Внешний IP адрес моего почтового сервера - 194.158.199.134
Внутренний IP адрес моего почтового сервера - 192.168.1.1
Код: [05/Feb/2015 11:55:32] from Internet, proto:TCP, len:60, 209.85.212.174:40975 -> 194.158.199.134:25, flags:[ SYN ], seq:1950703304 ack:0, win:42900, tcplen:0
[05/Feb/2015 11:55:32] to Local, proto:TCP, len:60, 209.85.212.174:40975 -> 192.168.1.1:25, flags:[ SYN ], seq:1950703304/4294967295 ack:0, win:42900, tcplen:0
[05/Feb/2015 11:55:32] from Local, proto:TCP, len:56, 192.168.1.1:25 -> 209.85.212.174:40975, flags:[ SYN ACK ], seq:3231379526 ack:1950703305, win:8192, tcplen:0
[05/Feb/2015 11:55:32] to Internet, proto:TCP, len:56, 194.158.199.134:25 -> 209.85.212.174:40975, flags:[ SYN ACK ], seq:3231379526/4294967295 ack:1950703305, win:8192, tcplen:0
[05/Feb/2015 11:55:32] from Internet, proto:TCP, len:52, 209.85.212.174:40975 -> 194.158.199.134:25, flags:[ ACK ], seq:1950703305 ack:3231379527, win:42900, tcplen:0
[05/Feb/2015 11:55:32] to Local, proto:TCP, len:52, 209.85.212.174:40975 -> 192.168.1.1:25, flags:[ ACK ], seq:1950703305/0 ack:3231379527, win:42900, tcplen:0
[05/Feb/2015 11:55:57] from Local, proto:TCP, len:87, 192.168.1.1:25 -> 209.85.192.182:34764, flags:[ ACK PSH ], seq:3494730561 ack:3464041070, win:65228, tcplen:35
[05/Feb/2015 11:56:02] Last message repeated 4 times
[05/Feb/2015 11:56:02] from Local, proto:TCP, len:87, 192.168.1.1:25 -> 209.85.192.182:34764, flags:[ ACK PSH ], seq:3494730561 ack:3464041070, win:65228, tcplen:35
[05/Feb/2015 11:56:08] from Local, proto:TCP, len:87, 192.168.1.1:25 -> 209.85.192.182:34764, flags:[ ACK PSH ], seq:3494730561 ack:3464041070, win:65228, tcplen:35
[05/Feb/2015 11:56:09] from Local, proto:TCP, len:87, 192.168.1.1:25 -> 209.85.192.182:34764, flags:[ ACK PSH ], seq:3494730561 ack:3464041070, win:65228, tcplen:35
[05/Feb/2015 11:56:17] from Local, proto:TCP, len:87, 192.168.1.1:25 -> 209.85.192.182:34764, flags:[ ACK PSH ], seq:3494730561 ack:3464041070, win:65228, tcplen:35
[05/Feb/2015 11:56:33] from Local, proto:TCP, len:40, 192.168.1.1:25 -> 209.85.192.182:34764, flags:[ RST ACK ], seq:3494730596 ack:3464041070, win:0, tcplen:0
[05/Feb/2015 11:56:59] from Local, proto:TCP, len:87, 192.168.1.1:25 -> 209.85.212.174:40975, flags:[ ACK PSH ], seq:3231379527 ack:1950703305, win:65228, tcplen:35
[05/Feb/2015 11:57:02] Last message repeated 4 times
[05/Feb/2015 11:57:02] from Local, proto:TCP, len:87, 192.168.1.1:25 -> 209.85.212.174:40975, flags:[ ACK PSH ], seq:3231379527 ack:1950703305, win:65228, tcplen:35
[05/Feb/2015 11:57:08] Last message repeated 3 times
[05/Feb/2015 11:57:11] from Local, proto:TCP, len:87, 192.168.1.1:25 -> 209.85.212.174:40975, flags:[ ACK PSH ], seq:3231379527 ack:1950703305, win:65228, tcplen:35
[05/Feb/2015 11:57:20] from Local, proto:TCP, len:40, 192.168.1.1:25 -> 209.85.212.174:40975, flags:[ RST ACK ], seq:3231379562 ack:1950703305, win:0, tcplen:0

YuraseK
Цитата:

Ниже кусок лога попытки взаимодействия почтового сервера google с моим почтовым сервером

Ты пишешь логи с помощью WireShark?!!! Ты бы еще осциллограмму эзернета поместил
за период 05/Feb/2015 11:55:32 - 05/Feb/2015 11:57:20! Про логи почтового сервера когда-нибудь слышал?

vlary
На этот момент нету логов в почтовике. Представленный мною лог взят из Kerio Control.
Могу в debug логе почтовика включить необходимые опции, но вопрос какие помогут в установлении истины, да и к тому же чтобы фильтровать данные только от гугла, а не всё подряд?
P.S. Я сделал дамп в Kerio Control процесса обмена с гуглом. Всё взаимодействие с ними прекращается на моменте, когда мой сервер отправляет приветствие о готовности с кодом 220. Пакет приветствия отправляется 7 раз, меняется только поле Indentification и CRC сумма заголовка, после чего посылается TCP RST.

royansson
А с какого момента такое началось? Что делал перед этим, может события какие были?

Добавлено:
[q][/q]
YuraseK

Насколько я понял, когда у тебя и коннект и контрол стояли на одной машине, то в контроле nat не надо было включать. Теперь когда это фактически 2 разные машины, ты обязан включить nat. В чем у тебя загвостка?

Добавлено:
royansson

Попробуй на веб морду поставь 81 порт и зайди, что получится.

maxrsrus
Да, когда всё было на одной машине, то NAT и MAP использовать не надо было для почты.
Сейчас надо обязательно использовать MAP, но без NAT не всегда работает корректно, а с NAT в почтовике все подключающиеся извне имеют IP адрес шлюза, что вполне логично.

YuraseK
Цитата:

а с NAT в почтовике все подключающиеся извне имеют IP адрес шлюза, что вполне логично.

Это вовсе даже не логично. Такое характерно для прокси, а нормальный НАТ
не меняет SRC IP в пакетах через проброшенные порты, он меняет DST IP

[more] maxrsrus
Все события, которые могу из логов выудить - это попытки подобрать комбинации логин / пароль, спам атаки постоянные (несколько раз в минуту) и сообщения о том, что индексные файлы в некоторых папках повреждены
В понедельник где-то в середине дня по логам много запросов PROPFIND и Search Request от пользователей на коффе.
Посмотрел debug.log за 02.02 - Куча запросов от нашего главного, который с мака по калдаву коннектится - 10-12 запросов в секунду.
Ругался, что сервис IM не может запустить и стопал его
выдал, правда, ещё такое вот:
[more]
03/Feb/2015 11:49:30] Message store DB is not available. fld=~golubev@mir6d.ru/&BB8EQAQ1BDQEOwQwBDMEMAQ1BDwESwQ1- &BDoEPgQ9BEIEMAQ6BEIESw-
[03/Feb/2015 11:49:30] Message store DB is not available. fld=~golubev@mir6d.ru/Contacts
[03/Feb/2015 11:49:30] Message store DB is not available. fld=#public@mir6d.ru/Contacts
[03/Feb/2015 11:49:30] Message store DB is not available. fld=#public@mir6d.ru/Contacts/&BBEEPgRPBEAEOgQ4BD0-
[03/Feb/2015 11:49:30] Message store DB is not available. fld=#public@mir6d.ru/Resources
[/more]
и такое:
[01/Feb/2015 03:45:53] $instant_messaging - Get private key of certificate server
[/more]

Я в VMWare сделал виртуальный интерфейс, через который можно взаимодействовать между физической машиной и виртуальной. До этого всё работало через бридж физического интерфейса. В случае использования виртуального интерфейса проблема выглядит похожим образом, но обрывается на более ранней стадии.
Логика взаимодействия, судя по записанным пакетам такая:
G > Я (ext), 00:00:00:00:00:00 > 02:00:00:00:00:00
G > Я (int), 00:00:00:00:00:00 > 06:00:00:00:00:00
G > Я (int), 00:00:00:00:00:00 > 00:00:00:00:00:00
G > Я (int), 00:00:00:00:00:00 > 04:00:00:00:00:00
Так повторяется 7 раз, потом гугл пытается подключиться вновь.
Что пытается сделать Kerio Control остаётся только догадываться, но внутренний IP адрес почтового сервера отбивается корректно, если в консоли Kerio Control выполнить arp -a.

[q][/q]
YuraseK

Ржу. Так в чем вопрос? Ты не хочешь NAT использовать или чего?

maxrsrus
Да, не хочу. Вроде как рекомендуется использовать просто MAP.

[q][/q]
YuraseK

А можешь мне подсказать, а как у тебя пользователи в интернет выходят? У тебя в контроле в поле трансляция для них что стоит?



Добавлено:
YuraseK

А лучше кинь принтскрин правило для твоего почтовика. Правило для входа на него и правило выхода его в инет.

maxrsrus
У меня прозрачный режим используется, поэтому, для пользователей включён конечно же NAT. Любой сайт не может ведь знать какой IP адрес у пользователя в моей локальной сети, а видит только мой внешний IP адрес. А вот в случае входящих подключений всё иначе: можно как с NAT так и без NAT. В настройках kerio control опция "Включить источник NAT" говорит сама за себя. Или я чего-то не понимаю: пакеты, которые будут перенаправлены на почтовый сервер с включённым NAT, будут содержать в качестве источника как IP адрес шлюза так IP адрес источника подключения?
Почему при включённом NAT и MAP почтовый сервер видит подключения от IP адреса интерфейса, через который с Kerio Control выполняется тот самый проброс.
Схема прохождения данных простая:
Интернет интерфейс (PPPoE) [Kerio Control] > Виртуальный интерфейс [Kerio Control] > Виртуальный интерфейс [Windows] > Kerio Connect
Kerio Control в VMware, VMware и Kerio Connect в Windows.
При пробросе подключений на другую физическую машину в локальной сети всё ОК.

[q][/q]
YuraseK
YuraseK - правда, не обижайся, но ты не в ту ветку вообще написал.
Кароче, действие MAP ты делаешь с внешнего интерфейса на свой почтарь с теми портами, которые нужны почтарю. (это чтобы на твой почтарь приходило). А для почтаря, делаешь действие NAT как минимум с теми же портами (это чтобы от него уходило).

Думаю тема закрыта.

maxrsrus
Проблема была с почтой, я был в сомнениях написать в ветку Control или Connect, и в этом моя ошибка.
У меня так и сделано, но работает не так как нужно.
Ладно, если никто не знает, то просто можно было проигнорировать мои сообщения.
Я обязательно разберусь с проблемой, на это просто уйдёт уйма времени.
Тем не менее спасибо за любую помощь.

YuraseK

Просил же, покажи принтскрин правил для почты (чтобы контрол исключить). Может у тебя в VMWare сетевухи не так настроены.

Добавлено:
YuraseK
И потом, если стоит Винда 2008, чё бы hyper-v не поднять, нафига разный софт друг на друга пихать.

maxrsrus
hyper-v не умеет использовать сетевые мосты.
В VMware все интерфейсы работают через бриджи к реальным интерфейсам, а Kerio Control после настроек перенесён в расшаренные виртуальные машины, чтобы работал автозапуск виртуальной машины при старте физической.
Странности в работе проброса подключений извне к Kerio Connect возможно как-то связаны с использованием сетевого моста (объединены локальный сетевой интерфейс и openvpn), т.к. судя по перехваченным пакетам они как-то умудряются затраиваться, т.е. получается некая программная петля.

YuraseK
Скорее всего ты намудрил с сетевухами в WMWare. Зря ты на Hyper наговариваешь. На нем все можно прекрасно сделать.

как добавить поддержку Drweb плагина в последнюю виндовую версию?

ssi
у них в инсталере должно всё уже быть.

Проблема, описанная мною выше, решена.
Всё как и всегда оказалось неочевидным на первый взгляд.
В моём случае используется балансировка каналов, а когда была версия Kerio Control под Windows, то наблюдалась проблема с некорректной работой переадресации DNS. В общем присутствовали проблемы с преобразованием доменных имён. Они были решены установкой в качестве DNS для всех интерфейсов в системе адреса 127.0.0.1. В новой версии под Linux эта настройка заработала не совсем корректно. В данном случае для интернет-ресурсов запросы типа A проходили замечательно, а вот PTR - нет. В Kerio Connect это повлияло на работу опции "Block if client's IP address has no reverse DNS entry (PTR)". В случае, если DNS запросы проходят успешно, то при отсутствии для IP адреса PTR записи в логах отбивается информация об этом. В моём же случае этого не происходило, т.е. был таймаут запроса, но Kerio Connect успевал только отправить приветствие, после чего всё взаимодействие блокировалось без каких-либо записей в логах, что несомненно глюк.
P.S. Никто не знает в Kerio Connect опция "Block if client's IP address has no reverse DNS entry (PTR)" контролирует соединения типа сервер-сервер или также клиент-сервер?

господа поделитесь адресами российских спам баз , для подключения к КС встроенные работают очень плохо - очень много сыпется спама