Медленно, но верно корпоративный сектор отказывается от маршрутизаторов 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.
В действительности, все это также работает на устройствах всех вендоров и привязывать этот случай к микротику нет никакого смысла. Просто давно нужно было сделать заметку о туннелях цыски и микрота, а тут такой случай.
В итоге схема такая:
Изначально вся сеть была построена на 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.
В действительности, все это также работает на устройствах всех вендоров и привязывать этот случай к микротику нет никакого смысла. Просто давно нужно было сделать заметку о туннелях цыски и микрота, а тут такой случай.
В итоге схема такая:
Комментариев нет:
Отправить комментарий