![]() |
|
![]() |
#1 | ||||
Телепат-тугодум
|
![]()
Начиная с восьмой версии (пока в виде бета) Control начинает поддерживать IPsec и именно это решение я сейчас пытаюсь безуспешно допилить в связке Mikrotik в филиале и в центре Control. Общее впечатление от RouterOS - ШОК от быстродействия, ШОК от тонкости настроек и как следствием полным пиздецом в понимании составления правил и маршрутов. Шаблоны, к которым я так привык в Kerio - разорваны напополам. Но это - всего лишь вопрос времени. К моему стыду прошло пять дней вдумчивого изучения манов по RouterOS и Ipsec но пока кроме коннекта мобильного клиента я ничего не достиг, я все жду, пока чехи выложат ман по настройке именно микротика у себя, говорят что эти устройства в Чехии популярны. Методом тыка пока у меня не пролезает.
__________________
керио |
||||
![]() |
![]() ![]() |
![]() |
#2 | |||
|
![]() |
|||
![]() |
![]() ![]() |
![]() |
#3 | ||||
Телепат-тугодум
|
![]()
Устройство на RouterOS является шлюзом для филиала. Для успокоения совести я пытался эмулировать шлюз филиала как раз на Draytek 2920 и тоже безуспешно.
В любом случае устройство на RouterOS может быть как шлюзом так и сервером внутри филиала, это не суть важно. В любом случае оно работает однозначно визуально быстрее Control. Извините, но таковы реалии. У меня в бюджете на это год переход на железные решения, планировал Juniper в филиалах использовать и уйти на хер от Control в центре, поставив кошку или Juniper, а вот теперь с выходом восьмой версии призадумался. Жаль что пока не могу кокнретно сказать, что модель Site-site на железка-control рабочая, а у меня 28 защита бюджета, буду пытаться юлить. Т.к. стоимость решения в пользу Керио на порядок.
__________________
керио Последний раз редактировалось EnMan; 21.01.2013 в 06:45. |
||||
![]() |
![]() ![]() |
![]() |
#4 | ||||
ExKerio RU staff
|
![]() |
||||
![]() |
![]() ![]() |
![]() |
#5 | ||||
Пейсатель професеонал
|
![]()
Да уж, с DNS у драйтеков есть какой-то затык. Иногда они тупо перестают пропускать DNS-пакеты, помогает только перезагрузка драйтека. Причем, драйтек при этом даже DNS форвардером не является.
И защиты от лупов нет. И IpSec сделан тоже как-то хитро. Хотя, тут еще неизвестно кого надо винить. С линксисом мне его подружить не получилось (правда, это было давно). С циской подружился только 2930 с последней прошивкой (2910 и 2920 меня обломили). А так, наши потребности пока покрывают, слава богу.
__________________
Всё хорошее когда-нибудь кончается... |
||||
![]() |
![]() ![]() |
![]() |
#6 | ||||
Телепат-тугодум
|
![]()
__________________
керио Последний раз редактировалось EnMan; 21.01.2013 в 06:45. |
||||
![]() |
![]() ![]() |
![]() |
#7 | ||||
ExKerio RU staff
|
![]() |
||||
![]() |
![]() ![]() |
![]() |
#8 | ||||
Телепат-тугодум
|
![]()
Ну, давай, не томи, рассказывай
![]()
__________________
керио |
||||
![]() |
![]() ![]() |
![]() |
#9 | |||
|
![]()
Да, ждемс рассказ.
Я сегодня пробовал создать тунель IPSec между Kerio8 и программными роутерами pfSense 2.0.2, а так же Zentyal. В обоих случаях результат аналогичный, Kerio ни в какую не хочет реагировать на входящее соединение с другой стороны. Хотя в активных соединениях явно отображается что существует входящие соединение по UDP 500. Использовать Kerio в качестве инициатора соединения (клиента), пока не пробовал. |
|||
![]() |
![]() ![]() |
![]() |
#10 | ||||
Пейсатель професеонал
|
![]()
Если уж так хочется задействовать программные средства, почему бы не использовать встроенные в windows возможности?
__________________
Всё хорошее когда-нибудь кончается... |
||||
![]() |
![]() ![]() |
![]() |
#11 | ||||
ExKerio RU staff
|
![]()
EnMan,
думаю ты сам понимаешь что ничего сверхъестественного не сделал, если у тебя в итоге всё получилось, кинь куда-нить мои скрины без IP чтобы сюда выложить. santaros, смотри внимательней, и у меня и у ув. EnMan на контрол ничего не приходило вообще если контрол был пассивной точкой, если же у тебя что-то приходит, то рекомендую debug включить опции протоколирования для ipsec. 2 All, свою историю с картинками буду выкладывать только после того, как туннель забегает во всех возможных режимах, иначе недоделка получается и только людям мешать думать будет. Добавлено через 10 часов 39 минут И так, что же могу сказать, соединение таки установлено в обоих направлениях. Заветное состояние initiator на туннеле получено ![]() Последний раз редактировалось tihon_one; 22.01.2013 в 21:38. Причина: Добавлено сообщение |
||||
![]() |
![]() ![]() |
![]() |
#12 | ||||
ExKerio RU staff
|
![]()
2 all,
всем кому надо выложил скрины настроек, будет время, обязательно подготовлю статью, и выложу ссылку сюда. Настройки KControl 8 [Для просмотра данной ссылки нужно зарегистрироваться] [Для просмотра данной ссылки нужно зарегистрироваться] Настройки Mikrotik (5.x) приведены только те которые менялись(использовалась виртуальная машина RouterOS последней, на данный момент времени) [Для просмотра данной ссылки нужно зарегистрироваться] [Для просмотра данной ссылки нужно зарегистрироваться] [Для просмотра данной ссылки нужно зарегистрироваться] [Для просмотра данной ссылки нужно зарегистрироваться] [Для просмотра данной ссылки нужно зарегистрироваться] |
||||
![]() |
![]() ![]() |
![]() |
#13 | ||||
Телепат-тугодум
|
![]()
По мотивам предыдущего поста.
1. В RouterOS нельзя в настройках IPSec принудительно инициировать VPN туннель. Mikrotik инициирует его только в случае обнаружения трафика в удаленную подсеть, которую вы описали в "IPSec Policies" 2. Mikrotik инициирует подключение VPN в случае обнаружения трафика в удаленную подсеть - с вашего WAN адреса, если у вас серый статический IP за NAT провайдера, то в качестве сурса в "IPSec Policies" нужно укзаывать именно серый адрес провайдера. Укажете белый - Mikrotik не станет устанавливать соединение, т.к. он про него вообще ничего не знает. Из этого следут п.3. 3. Если вы инициируете (равно как и ожидаете) подключение со стороны Kerio Control то в RemoteID вы должны указать серый адрес пассивного конца туннеля или вы получите залупу конскую на воротник, ее еще иногда называют "Несовпадение ИД". Указание IP адреса в ID ресурса имеет существенный недостаток, если существует резервирование WAN на Mikrotik, то в случае перехода на резерв сменится IP и тоннель ляжет. Для этого в настройке "IPSec Peer" в Mikrotik есть поле "My ID User FQDN", но указав там произвольное имя и продублировав его в настройке KControl, туннель не поднимается и это очень существенная проблема. Вооружившись этим знанием мы уже можем поднять туннель Control-Mikrotik и обратно тоже. Вуаля. Проверили пинг до локального адреса Микротик из локальной сети за Kerio Control. Пинг есть. Счастье есть? Бинго? А не тут то было. В обратную сторону из локальной сети за Mikrotik в сеть за Kerio Control пинга не будет. Mikrotik это вам не рассово правильный Kerio Control и маршрутов он при поднятии тоннеля сам не создает. Его нужно создать. Только вот незадача - если со стороны Kerio Control VPN - это, ебать, цельный сетевой интерфейс, то в Mikrotik у нас нету какбэ, куда маршрутить вообще нипаньятна. Поэтому нам нужно правило NAT в RouterOS расположенное раньше всех правил маскарадинга:
Пинги пошли во все стороны. Теперь Бинго. Те же правила и настройки Control и Mikrotik актуальны для тоннеля в другую сторону. Мой затык изначально был связан именно с серым адресом за провайдерским натом.
__________________
керио Последний раз редактировалось EnMan; 27.06.2013 в 16:38. |
||||
![]() |
![]() ![]() |
![]() |
#14 | ||||
ExKerio RU staff
|
![]()
EnMan,
спасибо за подробности, почти со всеми особенностями столкнулся кстати 80)) Надеюсь ты не против если эти данные попадут, несколько переработанные, в статью. |
||||
![]() |
![]() ![]() |
![]() |
#15 | ||||
Телепат-тугодум
|
![]()
Да, конечно. На данный момент остается только один открытый вопрос, это резервирование тоннеля, для того чтобы Mikrotik инициировал соединение с доступного интернет-интерфейса нужно в политиках IPSec в своем внешнем адресе вбить "нули" (хотя есть в настройке IPSec Peers параметр сгенерировать политики, но у меня не завелось). Вопрос с ID ресурса остается открытым, не канает произвольное имя. Есть подозрения, что там должно быть именно DNS имя и оно должно резолвиться со стороны KControl.
__________________
керио Последний раз редактировалось EnMan; 27.01.2013 в 06:49. |
||||
![]() |
![]() ![]() |
![]() |
#16 | |||
Навичёг
|
![]()
Настроил почти по картинкам tihon_one
При включении пассивного режима со стороны Kerio, тоннель не работает - сразу переходит в Down и не подымается. Если на керио включить активный режим, то соединяется, но обрывается каждые 10-15 секунд, потом соединяется вновь. Пинги из подсети керио в посеть микротика идут, а наоборот - нет. Последний раз редактировалось Mugg; 17.06.2013 в 19:54. |
|||
![]() |
![]() ![]() |
![]() |
#17 | |||
|
![]()
Яхууууу спасибо гуру EnMan за неоценимую помощь - теперь у меня тоже заработал тунель.
![]() |
|||
![]() |
![]() ![]() |
![]() |
#18 | ||||
Телепат-тугодум
|
![]()
Mugg, поднимите правило фаервола из сети за Mikrotik в сеть за Control выше всех. Иначе ваш пакет придет на Control с уже измененным источником и он не сможет его расшифровать, т.к. он не будет совпадать с адресом указанном в политиках IPsec. Свой пост с описанием я поправил.
olej, пажалста. В общем заставить работать связку Mikrotik <=> Control можно. Начиная с версии Control, которая поддерживает указание нескольких адресов в назначении установки туннеля - для меня лично отпала необходимость инициировать туннель именно со стороны Mikrotik. Более того, логично будет делать именно наоборот, потому что настроить failover VPN на Mikrotik - это пиздец какая нетривиальная задача. На данный момент я могу с уверенностью заявить что все работает и когда инициатор подключения Control и когда инициатор Mikrotik. К моему огромному сожалению у меня пока не получается настроить маршрутизацию в другие VPN сети о которых знает Control со стороны локальной сети за Mikrotik. За два дня сломана туева хуча копий, но тщетно. В случае когда Mikrotik инициирует соединение я могу получить доступ в любую подсеть, обращением к которой я инициирую туннель. Если туннель поднимать со стороны Control (и автоматически генерировать политики IPsec) - то получается получить доступ только к той подсети, субтуннель к которой был добавлен последний (это судя по дебагу на стороне Control). Отсутствие хоть каких то, блять, внятных логов на Mikrotik убивает желание с ним возиться напрочь. Отчаявшись, поднял IPsec туннель между двумя Control и без труда получил доступ к удаленным подсетям за ними. И это печально на самом деле. Была надежда, что косячит сам Control. А тут получается что они просто не хотят работать в такой связке. Ну или я пока не научился их подружить. Добавлено через 20 минут tihon_one, да - помню, да - логи будут. Просто стойокое ощущение, что я сейчас это методом тыка... вот вот.. вот оно вот и опять - хуй. Все будет. Чесслово.
__________________
керио Последний раз редактировалось EnMan; 27.06.2013 в 16:38. Причина: Добавлено сообщение |
||||
![]() |
![]() ![]() |
![]() |
#19 | |||
|
![]() 2. В Policy MikroTik-а Src.Adress 192.168.112.0/24, а в Dst.Adress 192.168.101.0/24 Если это ошибки, то не мог бы поправить, а то и так голова кругом идёт, ничего не срастается... ![]() Керио на статическом IP 77.66.182.ххх, удалённо МикроТик через Йоту. Вот лог с KControl: Код:
[28/Jun/2013 15:21:42] {charon} charon: 03[NET] received packet: from 188.162.166.59[44122] to 77.66.182.ххх[500] [28/Jun/2013 15:21:42] {charon} charon: 03[ENC] parsed ID_PROT request 0 [ SA V V ] [28/Jun/2013 15:21:42] {charon} charon: 03[IKE] received Cisco Unity vendor ID [28/Jun/2013 15:21:42] {charon} charon: 03[IKE] received DPD vendor ID [28/Jun/2013 15:21:42] {charon} charon: 03[IKE] 188.162.166.59 is initiating a Main Mode IKE_SA [28/Jun/2013 15:21:42] {charon} charon: 03[IKE] 188.162.166.59 is initiating a Main Mode IKE_SA [28/Jun/2013 15:21:42] {charon} charon: 03[ENC] generating ID_PROT response 0 [ SA V V V ] [28/Jun/2013 15:21:42] {charon} charon: 03[NET] sending packet: from 77.66.182.ххх[500] to 188.162.166.59[44122] [28/Jun/2013 15:21:42] {charon} charon: 02[NET] received packet: from 188.162.166.59[44122] to 77.66.182.ххх[500] [28/Jun/2013 15:21:42] {charon} charon: 02[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ] [28/Jun/2013 15:21:42] {charon} charon: 02[IKE] trying shared key for '%any'[(null)] - '%any'[(null)] [28/Jun/2013 15:21:42] {charon} charon: 02[ENC] generating ID_PROT response 0 [ KE No ] [28/Jun/2013 15:21:42] {charon} charon: 02[NET] sending packet: from 77.66.182.ххх[500] to 188.162.166.59[44122] [28/Jun/2013 15:21:42] {charon} charon: 06[NET] received packet: from 188.162.166.59[44122] to 77.66.182.ххх[500] [28/Jun/2013 15:21:42] {charon} charon: 06[ENC] parsed ID_PROT request 0 [ ID HASH ] [28/Jun/2013 15:21:42] {charon} charon: 06[CFG] looking for pre-shared key peer configs matching 77.66.182.ххх...188.162.166.59[10.0.0.10] [28/Jun/2013 15:21:42] {charon} charon: 06[CFG] Including peer config "tunnel_1_1_1_1" [28/Jun/2013 15:21:42] {charon} charon: 06[CFG] Including peer config "vpnserver_1" [28/Jun/2013 15:21:42] {charon} charon: 06[CFG] selected peer config "tunnel_1_1_1_1" [28/Jun/2013 15:21:42] {charon} charon: 06[IKE] IKE_SA tunnel_1_1_1_1[1003] established between 77.66.182.ххх[control.tnt-krasnodar.local]...188.162.166.59[10.0.0.10] [28/Jun/2013 15:21:42] {charon} charon: 06[IKE] IKE_SA tunnel_1_1_1_1[1003] established between 77.66.182.ххх[control.tnt-krasnodar.local]...188.162.166.59[10.0.0.10] [28/Jun/2013 15:21:42] {charon} charon: 06[IKE] scheduling reauthentication in 9946s [28/Jun/2013 15:21:42] {charon} charon: 06[IKE] maximum IKE_SA lifetime 10486s [28/Jun/2013 15:21:42] {charon} charon: 06[ENC] generating ID_PROT response 0 [ ID HASH ] [28/Jun/2013 15:21:42] {charon} charon: 06[NET] sending packet: from 77.66.182.ххх[500] to 188.162.166.59[44122] [28/Jun/2013 15:22:08] {IPsec} TunnelsList|thread: Going to sleep for 60s. [28/Jun/2013 15:22:12] {charon} charon: 04[IKE] sending DPD request [28/Jun/2013 15:22:12] {charon} charon: 04[ENC] generating INFORMATIONAL_V1 request 2852126451 [ HASH N(DPD) ] [28/Jun/2013 15:22:12] {charon} charon: 04[NET] sending packet: from 77.66.182.ххх[500] to 188.162.166.59[44122] [28/Jun/2013 15:22:12] {charon} charon: 03[NET] received packet: from 188.162.166.59[44122] to 77.66.182.ххх[500] [28/Jun/2013 15:22:12] {charon} charon: 03[ENC] parsed INFORMATIONAL_V1 request 4204932299 [ HASH N(DPD_ACK) ] [28/Jun/2013 15:22:42] {charon} charon: 06[IKE] sending DPD request [28/Jun/2013 15:22:42] {charon} charon: 06[ENC] generating INFORMATIONAL_V1 request 3178965331 [ HASH N(DPD) ] [28/Jun/2013 15:22:42] {charon} charon: 06[NET] sending packet: from 77.66.182.ххх[500] to 188.162.166.59[44122] [28/Jun/2013 15:22:42] {charon} charon: 07[NET] received packet: from 188.162.166.59[44122] to 77.66.182.ххх[500] [28/Jun/2013 15:22:42] {charon} charon: 07[ENC] parsed INFORMATIONAL_V1 request 3104324922 [ HASH N(DPD_ACK) ] [28/Jun/2013 15:23:08] {IPsec} TunnelsList|thread: Going to sleep for 60s. [28/Jun/2013 15:23:12] {charon} charon: 05[IKE] sending DPD request [28/Jun/2013 15:23:12] {charon} charon: 05[ENC] generating INFORMATIONAL_V1 request 2642699084 [ HASH N(DPD) ] [28/Jun/2013 15:23:12] {charon} charon: 05[NET] sending packet: from 77.66.182.ххх[500] to 188.162.166.59[44122] [28/Jun/2013 15:23:12] {charon} charon: 09[NET] received packet: from 188.162.166.59[44122] to 77.66.182.ххх[500] [28/Jun/2013 15:23:12] {charon} charon: 09[ENC] parsed INFORMATIONAL_V1 request 3172287152 [ HASH N(DPD_ACK) ] [28/Jun/2013 15:23:42] {charon} charon: 04[IKE] sending DPD request [28/Jun/2013 15:23:42] {charon} charon: 04[ENC] generating INFORMATIONAL_V1 request 589362853 [ HASH N(DPD) ] [28/Jun/2013 15:23:42] {charon} charon: 04[NET] sending packet: from 77.66.182.ххх[500] to 188.162.166.59[44122] [28/Jun/2013 15:23:42] {charon} charon: 03[NET] received packet: from 188.162.166.59[44122] to 77.66.182.ххх[500] [28/Jun/2013 15:23:42] {charon} charon: 03[ENC] parsed INFORMATIONAL_V1 request 3703311464 [ HASH N(DPD) ] [28/Jun/2013 15:23:42] {charon} charon: 03[ENC] generating INFORMATIONAL_V1 request 3002593359 [ HASH N(DPD_ACK) ] [28/Jun/2013 15:23:42] {charon} charon: 03[NET] sending packet: from 77.66.182.ххх[500] to 188.162.166.59[44122] [28/Jun/2013 15:23:42] {charon} charon: 02[NET] received packet: from 188.162.166.59[44122] to 77.66.182.ххх[500] [28/Jun/2013 15:23:42] {charon} charon: 02[ENC] parsed INFORMATIONAL_V1 request 3262573479 [ HASH N(DPD_ACK) ] [28/Jun/2013 15:24:08] {IPsec} TunnelsList|thread: Going to sleep for 60s. [28/Jun/2013 15:24:12] {charon} charon: 06[IKE] sending DPD request [28/Jun/2013 15:24:12] {charon} charon: 06[ENC] generating INFORMATIONAL_V1 request 1422726455 [ HASH N(DPD) ] [28/Jun/2013 15:24:12] {charon} charon: 06[NET] sending packet: from 77.66.182.ххх[500] to 188.162.166.59[44122] [28/Jun/2013 15:24:12] {charon} charon: 07[NET] received packet: from 188.162.166.59[44122] to 77.66.182.ххх[500] [28/Jun/2013 15:24:12] {charon} charon: 07[ENC] parsed INFORMATIONAL_V1 request 3182446839 [ HASH N(DPD_ACK) ] [28/Jun/2013 15:24:42] {charon} charon: 05[IKE] sending DPD request [28/Jun/2013 15:24:42] {charon} charon: 05[ENC] generating INFORMATIONAL_V1 request 2848233844 [ HASH N(DPD) ] [28/Jun/2013 15:24:42] {charon} charon: 05[NET] sending packet: from 77.66.182.ххх[500] to 188.162.166.59[44122] [28/Jun/2013 15:24:42] {charon} charon: 09[NET] received packet: from 188.162.166.59[44122] to 77.66.182.ххх[500] [28/Jun/2013 15:24:42] {charon} charon: 09[ENC] parsed INFORMATIONAL_V1 request 2360168009 [ HASH N(DPD_ACK) ] [28/Jun/2013 15:25:08] {IPsec} TunnelsList|thread: Going to sleep for 60s. Последний раз редактировалось VladOst; 28.06.2013 в 15:41. |
|||
![]() |
![]() ![]() |
![]() |
#20 | ||||
Телепат-тугодум
|
![]() Все верно. Если не срастается - приложите скриншоты настроек политики Ipsec из Mikrotik. Настройки туннеля в Kerio Control и объясните какие ваши адреса чему соответствуют.
__________________
керио Последний раз редактировалось EnMan; 28.06.2013 в 15:44. |
||||
![]() |
![]() ![]() |
© Kerio-rus.ru |
![]() ![]() |