Ru-Board.club
← Вернуться в раздел «В помощь системному администратору»

» Kerio Control (ex Kerio WinRoute Firewall)

Автор: RDA
Дата сообщения: 21.05.2015 11:59
Народ, подскажите
При соединении VPN на активном хосте выдает "Ошибка SSL 120" (SSL error 120)
Соединения не происходит. Возможно ли, что это связано с несовместимостью VPN разных версий Kerio?
На одном конце 6.6.0 на другом - 8.5.3
6.6.0 между собой нормально соединяются
Автор: ShadowDweller
Дата сообщения: 21.05.2015 13:37
Доброго дня. Прошу помощи (или подсказки, если проблема тривиальна на ваш взгляд).

Суть следующая: введённый в домен Kerio Control выполняет роль DHCP-раздатчика, но PTR-записи в DNS не создаются. Зона обратного просмотра наличествует, но записи там появляются только в том случае, если пробить "Обновить соответствующую PTR-запись" в зоне прямого просмотра. Это проблема DNS-сервера или настроек DNS в КК? Куда копать?
Автор: MAGNet
Дата сообщения: 21.05.2015 13:40
ShadowDweller

Цитата:
PTR-записи в DNS не создаются

настройки dns-сервера.
Автор: ShadowDweller
Дата сообщения: 21.05.2015 14:04
То есть в настройках зоны для обоих просмотров нужно разрешить любые динамические обновления, так?
Прошу прощения за тупые вопросы - в сетевых делах откровенный новичок, пусть и с куском знаний.
Автор: kotlyaranat
Дата сообщения: 22.05.2015 04:12
Народ есть у кого опыт установки kerio на виртуалку vmware workstation? как настроить интерфейсы в vmware? имеется два wan c статикой на обоих
Автор: olegauzver
Дата сообщения: 22.05.2015 05:20
Доброго дня всем. 2 дня назад появилась проблемка. Керио контрол (Kerio Control:
8.4.1 build 2731) вдруг начал блокировать сайт svyaznoy.ru (не реклама сайта). в логахпро блокирование нет ничего... до 20 числа к нему все нормально ходили. в логах есть доступ различных компов к нему без проблем. 21 числа доступ к сайту при включенном керио исчез, выключаешь. доступ есть. Все остальные необходимые ресурсы работают. Сломал весь моск. В логах керио в числе заблокированных не числиться ни по адресу, ни по имени. в браузере ошибка ERR_EMPTY_RESPONSE (Невозможно загрузить веб-страницу, так как не поступили данные от сервера.).
P.S. Пинги и трасерт ходят...
Автор: DrDroid
Дата сообщения: 22.05.2015 11:12
Добрый день, у меня в настройках стоит галочка "всегда требовать аутентификацию при доступе пользователей к вебстраницам", но мне для некоторых ip надо сделать чтоб не требовало аутентификацию, как это сделать?
Автор: olegauzver
Дата сообщения: 22.05.2015 13:00
Создать правило. Источник нужные айпи, назначение интернет интерфейс, службы любые или нужные, действие разрешить, при необходимости лог,трансляция нат.
Автор: ShadowDweller
Дата сообщения: 22.05.2015 13:08
Так и не получил ответ на свой вопрос. Очень прошу помощи! Бардак же в DNS творится.
Автор: wwladimir
Дата сообщения: 22.05.2015 15:59
DrDroid
Вариантов может быть несколько.Самым простым, мне кажется, такой-
щелкните по пользователю (или сначала создайте специально), на вкладке "адреса" поле называется "автоматический вход в систему" Дальше намекать?
Автор: MAGNet
Дата сообщения: 23.05.2015 05:03
ShadowDweller
извини за задержку.
да, нужно включить разрешения на все динамические обновления.
если не получится, то будем думать дальше.
Автор: ShadowDweller
Дата сообщения: 23.05.2015 21:51
Включил все ДО для всех зон. Вроде что-то зашуршало, плюс dcdiag /test:dns предсказуемо начал орать, что не смог удалить тестовую запись из зоны имярек.дот.ком. Ну да хоть мусор в домене разгрёб под шумок. Попробую добавить КК в группу DNSUpdateProxy и вернуть только безопасные ДО для зон.

Вообще я обратил внимание вот на что: при использовании собственного DHCP-сервера винды исправно обновляются и A-, и PTR-записи (ну ещё бы). А вот с Керио вечно какая-то свистопляска. Я правильно понимаю, считая, что засада кроется в переадресации DNS? Где вообще можно почитать насчёт того, WTF is that и стоит ли использовать переадресацию DNS от КК в условиях доменных сетей?
Автор: Tihon_one
Дата сообщения: 25.05.2015 10:00
ShadowDweller

Цитата:
стоит ли использовать переадресацию DNS от КК в условиях доменных сетей?


В условиях нормально развитой DNS подсистемы в собственной инфраструктуре, использование переадресации DNS в KControl, на мой взгляд, НЕ уместно. Данная возможность, переадресация DNS, предусмотрена в KControl лишь на случаи, когда KControl является единственным узлом обработки DNS запросов в ЛВС предприятия.
Автор: ShadowDweller
Дата сообщения: 25.05.2015 11:53
Значит, эту штуку можно вообще отключать в условиях AD?
Автор: Tihon_one
Дата сообщения: 25.05.2015 15:57
ShadowDweller
ну да, главное голову не отключить
Автор: wwladimir
Дата сообщения: 25.05.2015 16:12
ShadowDweller
В доменных службах существует понятие "авторизованный DHCP"

По настройке DNS KERIO есть КБ от лучших со от производителей продукта - Using the DNS module
Обратите внимание- "Kerio Control will forward DNS queries to the internal Domain Name Server if Kerio Control is joined to the domain"
Автор: ShadowDweller
Дата сообщения: 25.05.2015 20:08
То, что, будучи в составе AD, КК переправляет DNS-запросы в КД, я видел. Меня больше волнует то, как настраивать безопасность DNS-сервера и собственно зоны ОП, потому что А-записи появляются, а PTR'ы - нет. Может, в случае с КК они и не должны добавляться, и, соответственно, я зря баламучу воду?
Автор: Tihon_one
Дата сообщения: 26.05.2015 11:10
ShadowDweller

Цитата:
я зря баламучу воду?

верное замечание, не понимая, зачем, имея развитую инфраструктуру от MS, городить огород с DNS пересыльщиками и DHCP серверами сторонних производителей?
Автор: ShadowDweller
Дата сообщения: 26.05.2015 11:33
DHCP от КК на порядок проще в управлении. В MS DHCP слишком много лишних телодвижений нужно выполнять, чтобы банально сменить MAC-адрес для конкретной аренды. И ещё несколько нюансов. Вопрос удобства. А так хз даже... Просто от всего этого бардака у меня уже руки опускаются. Вроде сисадмин, а понимания происходящего ноль без палочки.
Автор: Tihon_one
Дата сообщения: 26.05.2015 12:10
Про понимание - нехватка опыта или теоритических знаний, т.е. вещь наживная, главное двигаться вперёд, а не на месте топтаться. По поводу простоты управления сервисами в KControl, да согласен, это как бы одно из преимуществ продукта, но у тебя запросы явно выше возможностей KControl.
Автор: zQuatroz
Дата сообщения: 26.05.2015 14:13

Цитата:
но PTR-записи в DNS не создаются

ptr-запись создаёт провайдер.
Автор: draf2007
Дата сообщения: 26.05.2015 14:16
Прошу помощи!!! Бьюсь уже неделю(((
Есть Kerio Control используется как DHCP, прозрачный прокси. В сети есть файлопомойка на win2008r2, на ней же поднят TFTPD_64. Хочу настроить PXE загрузку OC. TFTP доступен. При загрузке клиент получает Ip, маску подсети, ждет ответа от TFTP и выдает ошибку PXE-E32. В настройках DHCP у Kerio прописаны опции 066 (192.168.0.x) и 067 (\pxelinux.0). В правилах траффика TFTP разрешен в локальной сети. Кто сталкивался с такой проблемой? Гугл уже узнает меня в лицо))).
Автор: DrDroid
Дата сообщения: 26.05.2015 15:02
Вотпрос такой, у меня в логах ошибок много записей:
Reverse proxy detected loop in rule 'Webserver' for address дальше_следует_IP
что это за ошибка такая и почему она возникает? Реверсный прокси у меня проксирует трафик на вебсервер.
Автор: mazafakaz
Дата сообщения: 26.05.2015 16:10
draf2007
а что за tftp сервер используете?
тоже сейчас пытаюсь тонкие клиенты по сети запускать.

===

и вопрос по поводу почты по vpn.
есть керио контрол версии 8.5.1 build 3235. на нем поднят vpn сервер. Локальный ip 192.168.2.1. почтовый домен mail1.ru
vpn установлен между ним и конечной точкой - контролом версии 7.4.2 build 5136. Локальный ip 192.168.3.1. почтовый домен mail2.ru
на двух концах установлен керио коннект версии 8.4.
при отправке почты с mail1.ru на mail2.ru почта идет по vpn. (смотрю логи почтового сервера 192.168.3.1 - sender-host получается 192.168.2.1)
при отправке с mail2.ru на mail1.ru sender-host равен внешнему ip mail2...
пробовал пинговать mail1.ru с сервера 192.168.3.1 - пингуется 192.168.2.1...
в какую сторону копать?
Автор: draf2007
Дата сообщения: 26.05.2015 16:29
mazafakaz
TFTPD32. Стандартный Windows TFTPD не прокатил так как сеть без домена.
Автор: mazafakaz
Дата сообщения: 26.05.2015 16:36
draf2007
\pxelinux.0 - слеш обязателен? директорию писать пробовали?
Автор: draf2007
Дата сообщения: 26.05.2015 16:46
mazafakaz
Что только уже не пробовал((((
и так \pxelinux.0 и так pxelinux.0 и полный путь указывал, пофиг, 0 реакции.
Хотя при проверке доступности TFTP из локалной сети работает и со слешем и без него. И по IP и по имени конектится и работает, т.е. трансфер файлов идет в обе стороны. И куда копать хз(((
Автор: ShadowDweller
Дата сообщения: 26.05.2015 17:18
draf2007, попробуй опцию 67 временно отключить. На локальный WDS отсылка идёт исключительно по 66й опции, 67 не требуется. Может, прокатит?

Цитата:
ptr-запись создаёт провайдер
шта, простите? Какое отношение провайдер имеет к моим доменным DNS?

У меня ещё одна проблема. Ладно DNS, пофиг с ним пока что. Засада вот в чём. Несколько доменных учёток привязаны по MAC-адресам к своим компьютерам в доменном же КК, но на один-два компьютера нет-нет да ломанётся вообще не своя учётка (скажем, ИМЯ1 эпизодически ломится на ПК2, хотя привязана к ПК1, и таких смутьянов несколько). Как их выбить оттуда - вообще не соображаю. Проблеме уже несколько недель, сильно мешает сбору статистики - путаются и смешиваются записи. Версия КК - 8.5.3.
Автор: draf2007
Дата сообщения: 26.05.2015 17:31
ShadowDweller
отключил 67 опцию, клиенты перестали получать собственные ip, ip шлюза, ну и маску подсети тоже(((
Автор: ShadowDweller
Дата сообщения: 26.05.2015 17:51
Мб это из-за того, что TFTP-сервер пытается стать основным DHCP-сервером, при этом ни малейшего понятия не имея о настоящем основном? У меня уже было такое, когда я пытался шаманить с PXE-установкой семёрки, а после таких же выкрутасов плюнул и поднял WDS (что в итоге оказалось практичнее). Хотя у тебя юз-кейс несколько другой, трудно сказать :-\

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117

Предыдущая тема: Права доступа NTFS


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.