пятница, 18 ноября 2016 г.

GRE внутри IPSec между Mikrotik и Cisco

Медленно, но верно корпоративный сектор отказывается от маршрутизаторов Cisco в пользу устройств Mikrotik. В данном случае было решено ставить микроты в качестве шлюзов для филиалов.
Изначально вся сеть была построена на Cisco. Центральный маршрутизатор - Cisco 2800 серии, который собирается на себе кучу IPSec туннелей, по какой-то причине сделанных без VTI.
Так вот, лет через 10-15 филиальные цыски начали дохнуть. Ставить вместо них аналогичную железку дорого. Было принято решения закупать микроты RB951G-2HdD. После первой интеграции микрота в эту сеть мне хотелось сделать заметку о том, как подружить по GRE over IPsec (рассуждения на тему что же все таки over что можно почитать тут - http://linkmeup.ru/blog/50.html) микрот и sysko, но как-то не было времени. И вот подвернулась задачка, о которой хочу написать.
Был один узел в сети, у которого белый адрес остался жить на ADSL модеме в силу того, что там использовалось PPPoA, а не PPPoE. Был сделан NAT таким образом, что UDP 500 пролетал на внешний серый адрес роутера филиала. На хабе включен режим NAT-T. Работало это на карте шифрования, пакующей только юникаст трафик с одной сети в другую. В качестве пиров указаны внешние адреса. Упоминания о том, что внешним адресом филиального роутера является серый адрес нигде в конфиге не было.





Все бы хорошо, но филиальная sysco стала виснуть по три раза на день. Меняем на микрот.
До этого в филиалах уже ставились микроты. С общей картой шифрования на хабе у меня не получилось с пол пинка их подружить, поэтому на хабе была сделана следующая конструкция для подключений микротов:
crypto isakmp key Secret address 3.3.3.3
!
crypto ipsec transform-set SECURE-TS esp-aes 256 esp-md5-hmac 
!
crypto ipsec profile SECURE-P
 set transform-set SECURE-TS 
 set pfs group2
!
interface Tunnel1
 description to_Mikrotik
 ip address 192.168.200.1 255.255.255.252
 tunnel source 1.1.1.1
 tunnel destination 3.3.3.3
 tunnel protection ipsec profile SECURE-P
!
ip route 10.10.3.0 255.255.255.0 192.168.200.2
!
ip nat inside source list NAT-ACL interface FastEthernet1 overload
!
ip access-list extended NAT-ACL
 deny   ip 10.10.1.0 0.0.0.255 10.10.3.0 0.0.0.255
 permit ip 10.10.1.0 0.0.0.255 any
!
Шифрование осуществляется непосредственно на GRE туннеле т.е. шифруется протокол GRE src 1.1.1.1 dst 3.3.3.3.


На микротике настройки аналогичные.





В этот же раз схемы была немного другой т.к. спок стоит за NAT. Я сделал конфиг на микроте аналогичный конфигу цыски, но это не заработало как надо. С сети хаба виден был внутренний интерфейс микрота. С внутреннего интерфейса микрота видны были хосты внутренней сети хаба, но связи между хостами филиала и основного офиса не было. По непонятной мне причине микрот не шифровал трафик, который был описан в карте шифрования. Я не стал долго разбираться с этой проблемой и решил сделать туннель с VTI.
С конфигом туннеля на микроте вопросов нет. SRC=192.168.0.33, DST=1.1.1.1, но что на хабе? SRC=1.1.1.1, а DST? Если укажем внешний адрес 2.2.2.2, то туннель не поднимется т.к. микрот не владеет этим адресом и отбросит пакет, а сделать NAT мы не сможем т.к. сетевой экран филиала этот трафик будет проходить в зашифрованном виде.
Я сделал следующим образом:


crypto map combined 70 ipsec-isakmp 
 set peer 2.2.2.2
 set transform-set SECURE-TS 
 match address 106
!
interface FastEthernet1
 ip address 1.1.1.1 255.255.255.252
 crypto map combined
!
interface Tunnel11
 description to_Mikrotik5
 ip address 192.168.200.45 255.255.255.252
 tunnel source 1.1.1.1
 tunnel destination 192.168.1.33
!
ip route 192.168.1.33 255.255.255.255 1.1.1.2
!
access-list 106 permit gre host 1.1.1.1 host 192.168.1.33





В результате есть карта, которая шифрует трафик протокола GRE идущий с адреса 1.1.1.1 на адрес 192.168.0.33, выходящий через внешний интерфейс (есть маршрут). До того, как выйти с интерфейса хаба пакет с указанными выше SRC и DST шифруется, заворачивается в заголовок ESP с уже новыми SRC=1.1.1.1 DST=2.2.2.2 (peer из карты шифрования).
С этими же адресами пакет ESP проходит фаервол филиала, после чего микрот сбрасывает заголовок ESP и видит в качестве DST туннеля свой 192.168.0.33. Туннель в UP.



В действительности, все это также работает на устройствах всех вендоров и привязывать этот случай к микротику нет никакого смысла. Просто давно нужно было сделать заметку о туннелях цыски и микрота, а тут такой случай.

В итоге схема такая:



1 комментарий:

  1. Chuyenhangvevietnam là đơn vị cung cấp dịch vụ vận chuyển container lạnh Bắc Nam, dịch vụ vận chuyển container bắc nam, vận chuyển hàng hóa,... uy tín, chất lượng và giá rẻ tại TPHCM. Quý khách hàng có thể tìm hiểu những lưu ý khi sử dụng dịch vụ vận chuyển container lạnh qua bài viết này.

    Nếu có nhu cầu sử dụng dịch vụ vận chuyển container lạnh hoặc vận tải container bắc nam, quý khách hàng vui lòng liên hệ với chúng tôi qua hotline 1900 1247 để được tư vấn miễn phí về dịch vụ.

    ОтветитьУдалить