MultiWAN и проблема с IPsec

Обсуждение оборудования и его настройки
Ответить
Globalist
Сообщения: 6
Зарегистрирован: 11 апр 2023, 18:39

Коллеги, добрый день.

Нужен совет, у меня есть CCR1016-12G в который приходят 2 ISP.
1-й ISP основной, на нем висят разлинчые пробросы во внутренню сеть и с этого адреса до облачного цода у меня строится туннель IPsec, в цоде у нас сервера почты, 1с и прочая дрянь.
2-й ISP резервный, на нем ничего нету, нужен на случай отказа основного.
Я решил настроить схему для двух провайдеров MultiWAN, чтобы оба работали и можно было удаленно подключаться на оборудку через любой из доступных ISP на микроте.
С данным конфигом у меня все работает отлично как и задумывалось, но есть проблема с доступностью ресурсов, которые находятся в ЦОДЕ и с которыми у меня строится связанность посредством ipsec через 1-го провайдера, (почта, 1с, шары и так далее).
Как только данный конфиг применяется, появляются проблемы с доступностью ресурсов на стороне цода начинают отваливаться почта, перестает грузиться, шары не открываться, при этом интернет работает отлично и оба провайдера на микротике доступны.
Есть подозрение, что проблема в маршрутах, прошу подсказать, как это можно решить, возможно нужно явным образом указать микроту, что подсеть цода и связанность с ним доступна исключительно черзе 1-го провайдера (основного). Пока что-то не пойму в какую сторону смотреть.

Сам конфиг:
 
ISP1 ether5 100.100.100.98
ISP2 ether4 200.200.200.18

/routing table
add disabled=no fib name=rtab-1
add disabled=no fib name=rtab-2


/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=ether5 new-connection-mark=con-isp1 passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=ether4 new-connection-mark=con-isp2 passthrough=yes
add action=mark-routing chain=prerouting connection-mark=con-isp1 in-interface-list=!WAN new-routing-mark=rtab-1 passthrough=yes
add action=mark-routing chain=prerouting connection-mark=con-isp2 in-interface-list=!WAN new-routing-mark=rtab-2 passthrough=yes
add action=mark-routing chain=output connection-mark=con-isp1 new-routing-mark=rtab-1 passthrough=yes
add action=mark-routing chain=output connection-mark=con-isp2 new-routing-mark=rtab-2 passthrough=yes


/ip route
add disabled=yes distance=1 dst-address=10.0.0.0/8 gateway=bridge1 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10
add disabled=no distance=251 dst-address=0.0.0.0/0 gateway=100.100.100.97 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10
add disabled=no distance=252 dst-address=0.0.0.0/0 gateway=200.200.200.17 pref-src="" routing-table=rtab-2 scope=30 suppress-hw-offload=no target-scope=10
add disabled=yes distance=1 dst-address=0.0.0.0/0 gateway=100.100.100.97 pref-src="" routing-table=rtab-1 scope=30 suppress-hw-offload=no target-scope=10
add disabled=yes distance=1 dst-address=0.0.0.0/0 gateway=200.200.200.17 pref-src="" routing-table=rtab-2 scope=30 suppress-hw-offload=no target-scope=10
add disabled=yes distance=1 dst-address=4.2.2.1/32 gateway=100.100.100.97 pref-src="" routing-table=main scope=11 suppress-hw-offload=no target-scope=10
add disabled=yes distance=1 dst-address=4.2.2.2/32 gateway=200.200.200.17 pref-src="" routing-table=main scope=11 suppress-hw-offload=no target-scope=10
add check-gateway=ping disabled=yes distance=10 dst-address=0.0.0.0/0 gateway=4.2.2.1 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=11
add check-gateway=ping disabled=yes distance=20 dst-address=0.0.0.0/0 gateway=4.2.2.2 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=11


ip ipsec/export
/ip ipsec peer
add address=90.90.90.142/32 exchange-mode=ike2 name=CLOUD_ISP
/ip ipsec policy group
add name=group1
/ip ipsec profile
set [ find default=yes ] dh-group=modp4096 enc-algorithm=aes-256 hash-algorithm=sha256
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp4096
/ip ipsec identity
add peer=CLOUD_ISP
/ip ipsec policy
add dst-address=10.0.0.0/24 level=unique peer=CLOUD_ISP src-address=10.1.15.0/24 tunnel=yes
add dst-address=10.0.0.0/24 level=unique peer=CLOUD_ISP src-address=10.1.16.0/24 tunnel=yes


/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=WAN


/interface list
add name=WAN
add name=LAN
/interface list member
add interface=ether4 list=WAN
add interface=ether5 list=WAN
add interface=bridge1 list=LAN


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

Вообще самый простой вариант - заменить чистый IPSec туннель парой GRE обернутых IPSec'ом (через каждого из провайдеров).
Для них маршрутизация будет работать обычным (и легко предсказуемым) образом.

Единственное, надо ещё добавить пару /routing rule со смыслом, что для каждого внешнего IP - испольльзовать только его таблицу:

Код: Выделить всё

/routing rule
add src-address=100.100.100.98/32 lookup-only-in-table table=rtab-1
add src-address=200.200.200.18/32 lookup-only-in-table table=rtab-2


Telegram: @thexvo
Globalist
Сообщения: 6
Зарегистрирован: 11 апр 2023, 18:39

Признаться про GRE тоже подумывал, попробую поэкспериментировать на некотором оборудовании.
А есть ли возможность подсказать в текущем сценарии что можно поправить/добавить, уж очень хочется понять причину


xvo
Сообщения: 4204
Зарегистрирован: 25 фев 2018, 22:41
Откуда: Москва

Globalist писал(а): 12 апр 2023, 08:52 А есть ли возможность подсказать в текущем сценарии что можно поправить/добавить, уж очень хочется понять причину
Попробуйте добавить указанные выше routing rules.
А для ipsec пира добавить local address.

По идее это должно прибить туннель к своему провайдеру.
Потом можно таким же образом будет создать туннель через второго провайдера: ещё одного пира и пару политик.

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


Telegram: @thexvo
Globalist
Сообщения: 6
Зарегистрирован: 11 апр 2023, 18:39

xvo писал(а): 12 апр 2023, 11:42
Globalist писал(а): 12 апр 2023, 08:52 А есть ли возможность подсказать в текущем сценарии что можно поправить/добавить, уж очень хочется понять причину
Попробуйте добавить указанные выше routing rules.
А для ipsec пира добавить local address.

По идее это должно прибить туннель к своему провайдеру.
Потом можно таким же образом будет создать туннель через второго провайдера: ещё одного пира и пару политик.

Но вот насколько гладко оно будет перестраиваться на второй туннель, при падении первого - не могу сказать, не пробовал.
С GRE в этом смысле все проще - можно хоть оба параллельно использовать.
Добро, мысль главную понял. Спасибо за содействие, опробую такой сценарий!


Ответить