[kapydan]

Всем доброго времени суток. 

 

Возникла задача - настроить lan-to-lan между роутером cisco и mikrotik CCR1016-12G. Погуглив и почитав микротик вики, обнаружил что микрот l2l не поддерживает, только обычные gre, ipip, eoip etc. Озвучил эту точку зрения инженеру со стороны контрагента (который этот вариант и предложил) - он доказывает, что у них есть такие решения, когда между циской и микротиком построен l2l, но пример конфига для последнего, к сожалению, предоставить не может.

 

В связи с этим решил уточнить у форумчан - поддерживает ли микротик l2l, как cisco asa/isr или juniper srx. Или я ошибаюсь, или инженер со стороны контрагента...

[jffulcrum]

Тут надо понять, что со стороны Cisco подразумевается под L2L (и что это за Cisco вообще). Если то, о чем я думаю, то есть обычная ASA и классический site-to-site IPSec, то построить IPSec туннель между Cisco и Mikrotik можно. Если же подразумевается новая приблуда L2TPv3, то да, Mikrotik пока не при делах, даже в ROS7

[SUrov_IBM]

Kapydan, здравствуйте.

 

В 25.12.2021 в 23:04, kapydan сказал:

Или я ошибаюсь, или инженер со стороны контрагента...

Форумчанин Jffulcrum абсолютно правильно сказал, нужно понимать и уточнить в лоб, какой тип VPN контрагент предлагает использовать. Терминологии развелось много, иногда говорят одно, а думают совершенно иное!

 

Чаше всего, для соединения двух корпоративных сетей через публичный Интернет и обеспечения зашиты (шифрования) трафика, используют IPSec Site-To-Site VPN.

Это L3 VPN, поддерживаемый CISCO и MIKROTIK. Условно, схему можно реализовать двумя способами:

 

1. Чистый IPSec Site-To-Site, в некоторых случаях, такая схема приводит к сложностям с маршрутизацией на конечных маршрутизаторах внутри корпоративной сети.

2. IPSec совместно с туннелем (например GRE), что позволяет настроить маршрутизацию классическим способом.

 

 

 

Но если речь зашла о необходимости пробросить через публичный Интернет L2 (L2 over L3) трафик (непонятно зачем, но предположим нужно), то в данном случае между CISCO и MIKROTIK всё очень грустно.

L2 over L3 на CISCO – это L2TPv3 (не путать с L2TP, тот что на ОС WINDOWS и SOHO роутерах).

L2 over L3 на MIKROTIK – это EoIP или OpenVPN.

Единственное L2 over L3 решение, что приходит на ум, между CISCO и MIKROTIK – это EoMPLS. Но врать не буду, я не работал с EoMPLS и это только предположение.

 

Всё зависит от того, что Вы собираетесь "гонять" на сторону контрагента через публичный Интернет, если только маршрутизируемый L3 трафик (соединить Вашу офисную сеть и сеть контрагента), естественно Вам IPSec Site-To-Site VPN будет достаточно. Вот если Вы хотите несколько VLAN пробросить на сторону контрагента через публичный Интернет, то придётся задуматься о L2 over L3, но лучше без крайней необходимости не задумываться, честное слово и просто маршрутизировать по L3 то, что может маршрутизироваться. ;)

Edited December 26, 2021 by SUrov_IBM

[weedman]

C EoIP (между микротиками) имел дело несколько раз, но часто появлялись проблемы с MTU. В материале ниже описан MPLS\VPLS, автор статьи говорит что это стабильнее и лучше (могу подтвердить, что работает нормально).

Материал касается именно двух микротиков, но может что-то найдете для себя полезное тут

[kapydan]

В 26.12.2021 в 09:54, weedman сказал:

C EoIP (между микротиками) имел дело несколько раз, но часто появлялись проблемы с MTU.

eoip мы в данном случае использовать не сможем - т.к. с другого конца стоит циска, которая его не поддерживает.

 

В 26.12.2021 в 00:54, jffulcrum сказал:

и что это за Cisco вообще

какой-то из isr

 

В 26.12.2021 в 00:54, jffulcrum сказал:

Тут надо понять, что со стороны Cisco подразумевается под L2L

 

В 26.12.2021 в 03:17, SUrov_IBM сказал:

Форумчанин Jffulcrum абсолютно правильно сказал, нужно понимать и уточнить в лоб, какой тип VPN контрагент предлагает использовать. Терминологии развелось много, иногда говорят одно, а думают совершенно иное!

А вот это вопрос на миллион... Как я понял, l2l для соединения двух, или более, сайтов и предоставления доутспа из одного к ресурсам другого. Как из следующих примеров (один для двух asa, другой для двух роутеров).

https://packetlife.net/blog/2011/jul/11/lan-lan-vpn-asa-5505/

https://www.networkstraining.com/lan-to-lan-ipsec-vpn-between-two-cisco-routers/

 

 

 

[SUrov_IBM]

В 26.12.2021 в 12:56, kapydan сказал:

А вот это вопрос на миллион...

 

Скорей всего, у Вашего контрагента сетевые инженеры живут по стандарту корпоративного (Enterprise) мира и имели в виду:

В 26.12.2021 в 03:17, SUrov_IBM сказал:

1. Чистый IPSec Site-To-Site, в некоторых случаях, такая схема приводит к сложностям с маршрутизацией на конечных маршрутизаторах внутри корпоративной сети.

Данный вариант вполне реализуем между CISCO и MIKROTIK. Скорей всего, могут возникнуть нюансы при настройке, но многие только по такому стандарту и живут. Банки например и обслуживающие их конторы.

[fractal]

3 часа назад, SUrov_IBM сказал:

 

Скорей всего, у Вашего контрагента сетевые инженеры живут по стандарту корпоративного (Enterprise) мира и имели в виду:

Данный вариант вполне реализуем между CISCO и MIKROTIK. Скорей всего, могут возникнуть нюансы при настройке, но многие только по такому стандарту и живут. Банки например и обслуживающие их конторы.

+1 это site to site vpn, скорее всего посредством крипто мапа

[kapydan]

В 26.12.2021 в 14:24, SUrov_IBM сказал:

Данный вариант вполне реализуем между CISCO и MIKROTIK. Скорей всего, могут возникнуть нюансы при настройке, но многие только по такому стандарту и живут. Банки например и обслуживающие их конторы.

изначально рассматривал создание gre туннеля (точнее, в такой формулировке до меня довел задачу менеджер с нашей стороны), т.е. int tun 123 с ip адресом, и ipsec шифрованием на нем (а вот gre over ipsec или ipsec over gre - зависит от  решения удаленной стороны).

 

https://administrator.de/knowledge/cisco-mikrotik-vpn-standort-vernetzung-dynamischem-routing-398932.html

http://ciscomaster.ru/content/cisco-gre-ipsec-mikrotik

 

В 26.12.2021 в 17:58, fractal сказал:

+1 это site to site vpn, скорее всего посредством крипто мапа

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

[SUrov_IBM]

В 26.12.2021 в 18:41, kapydan сказал:

или ipsec over gre - зависит от  решения удаленной стороны

Единственное, для себя я решил (имея возможность, поскольку жёстко не привязан к корпоративному стандарту), при использовании IPSec Site-To-Site выбирать формат IPSec mode transport в связке с туннелированием GRE. Туннель GRE xxx.xx.x.x/30 строиться через публичный Интернет, проходящий через туннель GRE трафик оборачивается IPSec. При такой схеме, намного проще использовать классическую маршрутизацию, опираясь на линковочную сеть интерфейса.

 

Плюс ещё был неприятный момент, при использовании чистого  IPSec Site-To-Site (без туннелирования GRE), на MIKROTIK не заработал DHCP Helper, даже с указанным source адреса, пакеты от helper уходили в 0.0.0.0/0, хотя должны были передаваться на другой конец IPSec тоннеля. Но с DHCP Helper это явно будет не Ваш случай, да и скорей всего у меня руки не из того места были на тот момент. ;)

[kapydan]

http://twistedminds.ru/2012/08/s2s-ipsec-vpn-mikrotik-cisco/

 

имелось ввидк примерно вот такое решение

[fractal]

1 час назад, kapydan сказал:

http://twistedminds.ru/2012/08/s2s-ipsec-vpn-mikrotik-cisco/

 

имелось ввидк примерно вот такое решение

Ну как и говорили site to site vpn на криптомап, кстати, вскоре на новых ios его не будет 

[SUrov_IBM]

Fractal, здравствуйте.

 

В 29.12.2021 в 19:09, fractal сказал:

site to site vpn на криптомап, кстати, вскоре на новых ios его не будет

А как они планируют реализовывать IPSec Site to Site в новых IOS? Или данная роль, планируется полностью отдать ASA?

 

Просто, я давно не отслеживал новшества в CISCO и было бы интересно почитать, если поделитесь ссылкой. Хоть новое что-то узнаю. ;)

[kapydan]

В 29.12.2021 в 19:27, SUrov_IBM сказал:

А как они планируют реализовывать IPSec Site to Site в новых IOS? Или данная роль, планируется полностью отдать ASA

asa уже устарела - ей на замену пришли firepowerы.

 

В 29.12.2021 в 19:09, fractal сказал:

Ну как и говорили site to site vpn на криптомап, кстати, вскоре на новых ios его не будет 

только статья 10ти летней давности - не уверен, что стоящий микротик будет поддерживать такое (стоит 6.48.3, а статья для 5.19). 

[jffulcrum]

Все поддерживается. Рекомендуется, конечно, делать туннель в дополнение к IPSec, особенно если будет OSPF, но можно и без туннеля (кстати, Cisco в ISR G3 поддерживает IPIP, такой же, как и Mikrotik, лучше использовать его, а не GRE). Основные подводные камни:

- (классика) часики на устройствах - NTP

- несовпадение наборов шифров - вдумчиво смотреть proposals, помнить, что для IKEv1 в первой фазе не уйти от SHA1 и 3DES/AES-128

- Вот ето в LT линейке ROS не поддерживается, только в Stable с 6.48. 

[kapydan]

В 29.12.2021 в 21:51, jffulcrum сказал:

Рекомендуется, конечно, делать туннель в дополнение к IPSec, особенно если будет OSPF, но можно и без туннеля (кстати, Cisco в ISR G3 поддерживает IPIP, такой же, как и Mikrotik, лучше использовать его, а не GRE).

ISR G3 - имеется ввиду isr 4000? Вообще железки мне понравились, но стоимость их сильно огорчает (+сюда же лицензии и поддержку). Как сказал контрагент, никакого туннельного интерфейса делать не будем, только l2l как на асах (даже скинули конфиг l2l со своей циски)...

[jffulcrum]

В 29.12.2021 в 22:56, kapydan сказал:

ISR G3 - имеется ввиду isr 4000?

Да

 

[SUrov_IBM]

В 29.12.2021 в 21:51, jffulcrum сказал:

Рекомендуется, конечно, делать туннель в дополнение к IPSec

Ох, если бы Ваши рекомендации, да некоторым инженерам в уши донести.

 

Как показала практика, если с одной из сторон IPSec Site to Site вырисовывается CISCO ASA, инженеру, настраивающему это чудо, в жизни не объяснишь, зачем делать какой-то туннель в дополнение к IPSec. Во-первых, оказывается это чудо (ASA) не умеет GRE, во-вторых его расположение сбоку - усложнение схемы, а в-третьих всё и так прекрасно работает. Потом правда, если требуется настроить маршрутизацию между несколькими Site to Site VPN, на отдельно взятой ASA, начинаются какие-то "пляски с бубном"! ;)

 

В 29.12.2021 в 21:51, jffulcrum сказал:

Cisco в ISR G3 поддерживает IPIP, такой же, как и Mikrotik, лучше использовать его, а не GRE

Если не ошибаюсь, IP-IP tunnel поддерживается CISCO с незапамятных времён или имеется в виду, что его использование совместно с IPSec имеет какие-то подводные камни? Мне самому IP-IP tunnel всегда больше нравился, поскольку GRE мог быть "зарезан по дороге", но совместно с IPSec я его (IP-IP) не использовал.  Просто любопытно, чем вызвана Ваша рекомендация использовать IP-IP tunnel вместо GRE? Тем, что он "успешнее преодолеет" публичные сети или экономией четырёх байтов на GRE заголовке для MTU?

[SUrov_IBM]

В 29.12.2021 в 22:56, kapydan сказал:

Как сказал контрагент, никакого туннельного интерфейса делать не будем, только l2l как на асах

Не удивительно, что контрагент настоял на "чистом" IPSec Site to Site VPN, ведь с его стороны вырисовывается CISCO ASA, у инженеров этого чуда, в их идеологии по другому быть и не может. Какой-то туннель в дополнение к IPSec может быть с боку, но это лишнее и считается неправильным. ;)

 

Мой друг и коллега, у нас на работе, как-то раз настроил чистый IPSec Site to Site между ASA и MIKROTIK (оба маршрутизатора были под нашим управлением, поэтому можно было выбрать, что по душе, не привязываясь к стандартам). Со стороны MIKROTIK, не взлетел DHCP Helper для сети филиала, долго он возился, потом плюнул и сказал - "прими уже, куда ни будь tunnel от MIKROTIK". Отложив мои офисные документоведческие бумажки в сторону, я и принял как посчитал нужным - IPSec mode transport в связке с туннелированием GRE. А, ASA так и осталась кластером для Anyconnect, чтобы сотрудников к офисной сети подключать. ;)

 

Надеюсь, что с Вашей стороны не будет какой-то хитрой маршрутизации, при использовании "чистого" IPSec Site to Site VPN, чтобы обойтись "малой кровью".

 

Ой, хотя Вы говорили:

 

В 26.12.2021 в 18:41, kapydan сказал:

из неясных моментов, вроде бы на разных сайтах есть пересекающиеся подсети - и для них надо будет делать нат...

Это и так не самая лёгкая задача, а тут ещё "чистый" IPSec Site to Site VPN вырисовывается, без классической маршрутизации. Что ж, в таком случае, искренне пожелаю Вам удачи в решении этой не лёгкой задачи!

[gard]

Насчет ната в пересекающиеся подсети - есть netmap, может быть пригодится.

[kapydan]

В 30.12.2021 в 02:03, SUrov_IBM сказал:

Как показала практика, если с одной из сторон IPSec Site to Site вырисовывается CISCO ASA, инженеру, настраивающему это чудо, в жизни не объяснишь, зачем делать какой-то туннель в дополнение к IPSec.

В данном случае, у контрагента стоит роутер, а не asa. 

 

В 30.12.2021 в 02:03, SUrov_IBM сказал:

Потом правда, если требуется настроить маршрутизацию между несколькими Site to Site VPN, на отдельно взятой ASA, начинаются какие-то "пляски с бубном"! ;)

Раньше для этой цели был dynamic lan-to-lan, аналог dmvpn - но только для asa.

 

В 30.12.2021 в 02:03, SUrov_IBM сказал:

Мне самому IP-IP tunnel всегда больше нравился, поскольку GRE мог быть "зарезан по дороге", но совместно с IPSec я его (IP-IP) не использовал.

Если не ошибаюсь, то ip-ip туннель имеет ограничения на мультикаст и is-is протокол маршрутизации.

 

В 30.12.2021 в 02:56, SUrov_IBM сказал:

Надеюсь, что с Вашей стороны не будет какой-то хитрой маршрутизации, при использовании "чистого" IPSec Site to Site VPN, чтобы обойтись "малой кровью".

Тут, как бы сказать корректнее, между мной и инженерами контрагента есть еще несколько менеджеров... В данном случае, мы выступаем подрядчиком, один менеджер с нашей стороны, второй менеджер - со стороны заказчика, и третий менеджер - со стороны контрагента...

[jffulcrum]

В 30.12.2021 в 02:03, SUrov_IBM сказал:

Просто любопытно, чем вызвана Ваша рекомендация использовать IP-IP tunnel вместо GRE? Тем, что он "успешнее преодолеет" публичные сети или экономией четырёх байтов на GRE заголовке для MTU?

Ну, при использовании IPSec публичные сети препятствием для GRE не являются, ибо он будет внутри шифрования, а не снаружи.

[SUrov_IBM]

В 30.12.2021 в 11:35, kapydan сказал:

Если не ошибаюсь, то ip-ip туннель имеет ограничения на мультикаст и is-is протокол маршрутизации.

Просто "мысли в слух", пока имеется возможность, отложив в сторону офисные документоведческие бумажки, немного порассуждать с умными людьми. ;)

 

Поправьте меня пожалуйста, если не прав:

 

Для меня, IS-IS всегда был чем-то "за горизонтом, на том краю света", поработать с ним не доводилось и насколько я понял, он применялся в очень крупных сетях, например операторов сотовой связи. Да согласен, IP-IP tunnel инкапсулирует только unicast IP трафик и если IS-IS работает исключительно на L2, то такой IP-IP для него не подойдёт. Правда, если схема подразумевает использование тоннеля и OSPF, пусть даже это будет GRE, для OSPF я использую point-to-point (unicast) режим, так мне привычней.

 

GRE позволяет инкапсулировать multicast трафик и насколько я понял, мог использоваться для инкапсуляции не маршрутизируюмых протоколов в тоннель, правда я слабо представляю, как не маршрутизируюмые протоколы направлялись на в тоннель маршрутизаторе.

Еще важным различием между GRE и IP-IP туннелированием является том, что GRE имеет возможность подтверждать получение пакетов, аналогично TCP, а IP-IP такого свойства не имеет, наследуя поведение не обработанного IP пакета (без сохранения состояния).

[SUrov_IBM]

В 30.12.2021 в 12:46, jffulcrum сказал:

Ну, при использовании IPSec публичные сети препятствием для GRE не являются, ибо он будет внутри шифрования, а не снаружи.

Если GRE или IP-IP туннель будет проходить через IPSec Site to Site VPN, например с устройства расположенного за ASA или формироваться с одного устройства, но в последовательности сначала IPSec Site to Site, затем туннелирование, то да. Но ведь, часто может быть и обратная ситуация (достаточно часто встречаемая схема), когда туннелирование GRE или IP-IP будет являться транспортом для IPSec, тогда туннель пойдёт по публичной сети первым.

[kapydan]

В 30.12.2021 в 13:52, SUrov_IBM сказал:

он применялся в очень крупных сетях, например операторов сотовой связи

Необязательно опсосов, просто в крупных провайдерах, и да - он l2 (именно поэтому в ipip туннель он не пройдет).

 

В 30.12.2021 в 13:52, SUrov_IBM сказал:

GRE позволяет инкапсулировать multicast трафик и насколько я понял, мог использоваться для инкапсуляции не маршрутизируюмых протоколов в тоннель, правда я слабо представляю, как не маршрутизируюмые протоколы направлялись на в тоннель маршрутизаторе.

Этот момент проще прочесть на английском сразу, хороших переводов нет. Routed protocol - маршрутизируемый протокол, routing protocol - протокол маршрутизации, искать что-то типа routed protocol vs routing protocol.

[kapydan]

В 30.12.2021 в 14:03, SUrov_IBM сказал:

например с устройства расположенного за ASA

в текущей схеме это именно роутер, на котором настроен именно l2l (в терминологии циски)

 

crypto ikev2 profile ikev2-profile-donkey
match identity remote address 11.12.13.14 255.255.255.255 адрес микротика на нашей стороне
keyring local ikev2-keyring-donkey
 
crypto ikev2 keyring ikev2-keyring-donkey
peer Zakaz4ik
  description *** Zakaz4ik IKEv2 Peer ***
  address 11.12.13.14 
  pre-shared-key Pass123
 
crypto ipsec transform-set ipsec-ts-donkey esp-aes 256 esp-sha-hmac
 mode tunnel
 
ip access-list extended encrypt-zakaz4ik
permit ip 10.24.0.0 0.0.255.255 10.25.13.0 0.0.0.3 10.24.0.0/26-внутренняя сеть контрагента, куда нужен доступ 10.25.13.0/252-стыковая сеть у контрагента
 
ip access-list extended ipsec-Zakaz4ik-in
permit icmp 10.25.13.0 0.0.0.3 host 10.24.0.200
permit ip 10.25.13.0 0.0.0.3 host 10.24.6.10
permit ip 10.25.13.0 0.0.0.3 host 10.24.6.11
permit ip 10.25.13.0 0.0.0.3 host 10.24.6.20
permit ip 10.25.13.0 0.0.0.3 host 10.24.6.21
deny   ip any any log
 
crypto map donkey-map 130 ipsec-isakmp
 description *** IPsec-IKEv2-Zakaz4ik (Mikrotik) ***
set peer 11.12.13.14
set ip access-group ipsec-Zakaz4ik-in in
set transform-set ipsec-ts-donkey
 set ikev2-profile ikev2-profile-donkey
match address encrypt-zakaz4ik