+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Удалённый доступ к WAN через IPSEC-туннель

Удалённый доступ к WAN через IPSEC-туннель, RouterOS

mbethers

Guest

01.10.2020 05:16:00

Есть довольно много постов на эту тему, но я так и не смог найти решение. У меня есть рабочий IPSEC-туннель. Связь между LAN1 и LAN2 работает успешно. Я пытаюсь сделать так, чтобы трафик из LAN1 шел через этот туннель и выходил через WAN2. Одно из предложений, которое показалось логичным — добавить дефолтный маршрут 0.0.0.0/0 с шлюзом LAN2, но он отображается как недоступный. Ещё момент: LAN1 находится за другим роутером, которым я не управляю, но туннель всё же поднял. Буду признателен за любые советы или если у кого хватит смелости доработать эту вики: https://wiki.mikrotik.com/wiki/Routing_through_remote_network_over_IPsec Спасибо. Вот где я сейчас: это обычная базовая конфигурация IPSEC.

/ip ipsec profile set [ find default=yes ] nat-traversal=no add dh-group=modp2048 dpd-interval=disable-dpd enc-algorithm=aes-256 name= profile1
/ip ipsec peer add exchange-mode=aggressive name=LAN1 passive=yes profile=profile1 send-initial-contact=no
/ip ipsec proposal add enc-algorithms=3des name=proposal1 pfs-group=none
/ip ipsec identity add peer=LAN1 secret=secret
/ip ipsec policy set 0 disabled=yes dst-address=172.25.17.0/24 src-address=192.168.89.0/24
add dst-address=172.25.17.0/24 peer=LAN1 proposal=proposal1 sa-dst-address=1.1.1.1 sa-src-address=0.0.0.0 src-address=192.168.89.0/24 tunnel=yes

/ip ipsec profile set [ find default=yes ] nat-traversal=no add dh-group=modp2048 dpd-interval=disable-dpd enc-algorithm=aes-256 name= profile1
/ip ipsec peer add exchange-mode=aggressive name=LAN2 passive=yes profile=profile1 send-initial-contact=no
/ip ipsec proposal add enc-algorithms=3des name=proposal1 pfs-group=none
/ip ipsec identity add peer=LAN2 secret=secret
/ip ipsec policy set 0 disabled=yes dst-address=192.168.89.0/24 src-address=172.25.17.0/24
add dst-address=192.168.89.0/24 peer=LAN2 proposal=proposal1 sa-dst-address=2.2.2.2 sa-src-address=0.0.0.0 src-address=172.25.17.0/24 tunnel=yes

brg3466

Guest

22.11.2020 04:30:00

@Sindy, я попробовал твое предложение направлять весь трафик LAN1 через WAN2 (с сохранением метода сопоставления трафика). Работает! Но, глядя на ссылку https://wiki.mikrotik.com/wiki/Routing_through_remote_network_over_IPsec, кажется, что применяется это к одному конкретному устройству (10.10.10.23) в LAN1 (10.10.10.0/24), которое выводит свой трафик через WAN2, а остальная часть IP по-прежнему идет через WAN1. Если это так, есть ли способ сделать именно так (без помощи другого PtP туннеля)? Сейчас я использую L2TP/IPsec для этого, но просто интересно, можно ли обойтись без другого PtP туннеля.

brg3466 Guest	#3 0 23.11.2020 04:41:00 Есть идеи, как этого добиться?

sindy

Guest

23.11.2020 16:05:00

Из вашего предыдущего поста было не совсем понятно, является ли факт, что маршрут по умолчанию через удалённый сайт (WAN2) применяется только для одного IP в вашей LAN-подсети, тем, чего вы действительно хотите, или же это просто описание из вики, на которую вы ссылаетесь, а вам нужно нечто другое.

Смотрю на схему и предполагаю, что вы хотите, чтобы туннель работал только между LAN сайта 1 и LAN сайта 2 для большинства устройств, но это одно устройство в LAN сайта 1 должно использовать туннель также для выхода в интернет через WAN сайта 2. Если так, то для этого отдельного устройства нужна своя политика, например:
src-address=10.20.30.40 dst-address=0.0.0.0/0 …
src-address=10.20.30.0/24 dst-address=10.11.12.0/24 …

Политики работают так же, как правила файрвола или маршрутизации — сверху вниз, пока не будет найдено первое совпадение. В данном случае порядок не важен, потому что не имеет значения, будут ли пакеты с 10.20.30.40, направленные к 10.11.23.0/24, отправлены через один или другой SA.

brg3466

Guest

24.11.2020 01:36:00

Привет, Синди, спасибо за твой ответ! Я попытался добавить эту политику для конкретного IP в подсети, но, похоже, не сработало. Моя конфигурация такая:
Роутер G: wanip-10.10.10.66, подсеть 192.168.3.0/24
Роутер N: wanip-192.168.99.149, подсеть 192.168.4.0/24, ПК в подсети: 192.168.4.254

После настройки IPsec туннеля между Роутером G и Роутером N, он успешно поднялся и работает. Но если я добавляю дополнительную политику, то она не работает. Может, я что-то пропустил в настройках?

[brg3466@N] > ip ipsec export
# nov/23/2020 17:25:46 by RouterOS 6.47.4
# model = 951-2n
/ip ipsec peer
add address=10.10.10.66/32 exchange-mode=ike2 local-address=192.168.99.149 name=ike2-G
/ip ipsec identity
# Советую использовать более сильный pre-shared ключ или другой метод аутентификации
add peer=ike2-G secret=test
/ip ipsec policy
add dst-address=0.0.0.0/0 peer=ike2-G sa-dst-address=10.10.10.66 sa-src-address=192.168.99.149 src-address=192.168.4.254/32 tunnel=yes
add dst-address=192.168.3.0/24 peer=ike2-G sa-dst-address=10.10.10.66 sa-src-address=192.168.99.149 src-address=192.168.4.0/24 tunnel=yes

[brg3466@N] > ip ipsec policy pr
Флаги: T - шаблон, B - резерв, X - отключено, D - динамическое, I - неверное, A - активно, * - по умолчанию
# PEER ТУННЕЛЬ SRC-АДРЕС DST-АДРЕС ПРОТОКОЛ ДЕЙСТВИЕ УРОВЕНЬ PH2-СЧЁТЧИК
0 T * ::/0 ::/0 все
1 I ike2-G да 192.168.4.254/32 0.0.0.0/0 все шифровать требуется 0
2 A ike2-G да 192.168.4.0/24 192.168.3.0/24 все шифровать требуется 1

sindy

Guest

24.11.2020 09:40:00

Странно — я только что воспроизвел такую же конфигурацию, и обе политики появились без проблем:

[me@HyperV-CHR-1] > ip ipsec policy print detail
Flags: T - шаблон, X - отключено, D - динамическое, I - недействительно, A - активно, * - по умолчанию

…
7 A peer=chr-2-ike2 tunnel=yes src-address=192.168.83.25/32 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp sa-src-address=192.168.119.11 sa-dst-address=192.168.119.12 proposal=default ph2-count=1
8 A peer=chr-2-ike2 tunnel=yes src-address=192.168.83.0/24 src-port=any dst-address=192.168.93.0/24 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp sa-src-address=192.168.119.11 sa-dst-address=192.168.119.12 proposal=default ph2-count=1

Так что попробуй отключить и заново включить peer — иногда бывают неожиданные казусы, если политики добавляются после того, как фаза 1 уже запущена (но в моём случае я добавлял обе политики именно так, и никаких проблем не было). В моем случае взаимный порядок этих двух политик тоже значения не имеет.

Если отключение и повторное включение peer не поможет, попробуй версию 6.46.8 (последний долгосрочный релиз на момент написания, на котором у меня всё работает).

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

brg3466

Guest

25.11.2020 05:51:00

@Sindy, огромное спасибо, очень ценю твоё время! Отключение и повторное включение сработало. Наконец-то всё заработало!

Чтобы ПК мог выходить через WAN роутера G, нужно добавить правило NAT:
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.3.0/24
add action=accept chain=srcnat src-address=192.168.4.254
add action=masquerade chain=srcnat

Кстати, у меня остались два вопроса: когда я маршрутизирую весь трафик из 192.168.4.0/24 через WAN роутера G, рекомендуется добавить политику "action=none…" перед политикой "action=encrypt…". Но в случае с адресом 192.168.4.254 весь трафик идёт через туннель, хотя я не добавлял эту политику "action=none…", и 4.254 всё равно может подключаться к router-N через winbox (192.168.4.1). Почему доступ к router-N не теряется?

Перед твоим решением я пробовал другой способ, но он не сработал. Использовал mangle-правило для 192.168.4.254 и добавлял статический маршрут, но это не работало. Почему шлюз удалённого роутера G не срабатывает?

Ещё раз спасибо за помощь!

/ip firewall mangle
add action=mark-routing chain=prerouting new-routing-mark=router-G passthrough=yes src-address=192.168.4.254

/ip route
add distance=1 gateway=192.168.3.1 routing-mark=router-G

sindy

Guest

25.11.2020 08:12:00

Потому что это замечание актуально только в тех случаях, когда в действии action=encrypt в поле dst-address входит подсеть LAN, а в src-address — собственный адрес роутера в этой подсети LAN. Но в политике для связи между сайтом 1 (LAN) и сайтом 2 (LAN) поле dst-address не включает подсеть LAN сайта 1, а в политике для адреса 192.168.4.254 во весь интернет поле src-address не включает IP-адрес самого роутера. Поэтому ни одна из двух политик не перенаправляет пакеты, отправленные роутером на хост 192.168.4.254.

Возможно, вы неправильно понимаете, как работает маршрутизация? Когда выбирается маршрут с IP-адресом в качестве шлюза, это не значит, что в пакете меняется адрес назначения на адрес шлюза. Это лишь косвенно подсказывает роутеру, через какой интерфейс отправлять пакет и, если интерфейс точка-многоточка, на какой удалённый хост, доступный через этот интерфейс, передать пакет для доставки. Поскольку адрес назначения в пакете не меняется на 192.168.3.1, политика, ориентированная на 192.168.3.1, игнорирует этот пакет.

brg3466 Guest	#9 0 25.11.2020 22:00:00 @Sindy, спасибо за подробные объяснения! Теперь всё ясно. Приятно знать не только «как», но и «почему». Спасибо и хороших вам праздников!

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры