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

Маршрутизировать весь трафик для одного LAN IP с сайта А (через туннель Wireguard) на сайт Б.

Маршрутизировать весь трафик для одного LAN IP с сайта А (через туннель Wireguard) на сайт Б., RouterOS

BrianRS

Guest

26.01.2023 14:09:00

Всем привет, пытался следовать инструкции по ссылке http://forum.mikrotik.com/t/routing-specific-ip-only-via-the-vpn-routing-mark-doesnt-work/156492/33, чтобы это заработало, но без успеха. Однако @anav посоветовал открыть новую тему. Стоит упомянуть, что туннель Wireguard установлен между двумя роутерами MikroTik. В приложении вы найдёте мою конфигурацию, а также повторю вывод /ip/route/print detail:

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

****@MikroTik] > /ip/route/print detail
Flags: D - динамический; X - отключен, I - неактивный, A - активный; c - привязка, s - статический, r - rip, b - bgp, o - ospf, d - dhcp, v - vpn, m - модем, y - копия; H - аппаратное ускорение;
+ - ecmp

0 s ;;; Default ISP2
dst-address=0.0.0.0/0 routing-table=main pref-src="" gateway=8.8.8.8 immediate-gw=10.144.18.137%eth2 - WAN2 - LTE check-gateway=ping distance=2 scope=30
target-scope=11 suppress-hw-offload=no

1 As ;;; Default ISP1
dst-address=0.0.0.0/0 routing-table=main pref-src="" gateway=1.1.1.1 immediate-gw=51.148.77.137%PPPoE - ZEN check-gateway=ping distance=1 scope=30 target-scope=11
suppress-hw-offload=no

2 As ;;; Monitor ISP1
dst-address=1.1.1.1/32 routing-table=main pref-src="" gateway=51.148.77.137 immediate-gw=51.148.77.137%PPPoE - ZEN distance=1 scope=10 target-scope=10
suppress-hw-offload=no

3 As ;;; Monitor ISP2
dst-address=8.8.8.8/32 routing-table=main pref-src="" gateway=10.144.18.137 immediate-gw=10.144.18.137%eth2 - WAN2 - LTE distance=1 scope=10 target-scope=10
suppress-hw-offload=no

DAc dst-address=10.144.18.128/28 routing-table=main gateway=eth2 - WAN2 - LTE immediate-gw=eth2 - WAN2 - LTE distance=0 scope=10 suppress-hw-offload=no
local-address=10.144.18.136%eth2 - WAN2 - LTE

DAc dst-address=51.148.77.137/32 routing-table=main gateway=PPPoE - ZEN immediate-gw=PPPoE - ZEN distance=0 scope=10 suppress-hw-offload=no
local-address=x.x.x.x%PPPoE - ZEN

DAc dst-address=172.16.10.0/23 routing-table=main gateway=BRIDGE immediate-gw=BRIDGE distance=0 scope=10 suppress-hw-offload=no local-address=172.16.11.1%BRIDGE

4 As dst-address=192.168.11.0/24 routing-table=main pref-src="" gateway=WG-MikroTik-GB immediate-gw=WG-MikroTik-GB distance=1 scope=30 target-scope=10
suppress-hw-offload=no

DAc dst-address=192.168.88.0/24 routing-table=main gateway=WG-MikroTik-GB immediate-gw=WG-MikroTik-GB distance=0 scope=10 suppress-hw-offload=no
local-address=192.168.88.2%WG-MikroTik-GB

DAc dst-address=192.168.188.0/30 routing-table=main gateway=MGMT-VLAN immediate-gw=MGMT-VLAN distance=0 scope=10 suppress-hw-offload=no
local-address=192.168.188.2%MGMT-VLAN

5 s ;;; Failover ISP2
dst-address=0.0.0.0/0 routing-table=to_ISP1 pref-src="" gateway=8.8.8.8 immediate-gw=10.144.18.137%eth2 - WAN2 - LTE check-gateway=ping distance=2 scope=30
target-scope=11 suppress-hw-offload=no

6 As ;;; Routing ISP1
dst-address=0.0.0.0/0 routing-table=to_ISP1 pref-src="" gateway=1.1.1.1 immediate-gw=51.148.77.137%PPPoE - ZEN check-gateway=ping distance=1 scope=30
target-scope=11 suppress-hw-offload=no

7 s ;;; Failover ISP1
dst-address=0.0.0.0/0 routing-table=to_ISP2 pref-src="" gateway=1.1.1.1 immediate-gw=51.148.77.137%PPPoE - ZEN check-gateway=ping distance=2 scope=30
target-scope=11 suppress-hw-offload=no

R1.rsc (17.7 KB)

BrianRS

Guest

22.02.2023 16:45:00

Привет снова и извиняюсь за задержку с ответом, я был в отъезде... Ты можешь настроить так, чтобы конкретный пользователь использовал WAN другого роутера только через WireGuard. Можешь, пожалуйста, привести пример, как это сделать? Проблема возникает по необходимости. Это вариант с выбором «да» или «нет». Один из вариантов — разрешить пользователю переключаться на обычный локальный WAN, если туннель WireGuard не работает. То есть: туннель поднят — пользователь использует WAN удалённого роутера, туннель опущен — пользователь использует локальный WAN. Тогда да, давай так сделаем.

Как я уже говорил, нет опции, чтобы пользователь сам выбирал, через какой WAN выходить с ПК. Я такого не просил. Нужно, чтобы это управлялось через интерфейс Winbox. Поэтому я предложил настроить WireGuard на отдельной Wi-Fi сети, к которой доступ и пароль только у этого пользователя. Если он хочет интернет через WireGuard — пусть подключается по Wi-Fi.

Но клиент в данном случае подключается по проводному интерфейсу, так что этот вариант не подходит. Альтернативно, пользователю можно дать управляемый коммутатор на рабочем столе, чтобы он менял физические порты и таким образом выбирал, через какой WAN выходить — локальный или WireGuard. Но опять же, никаких действий со стороны пользователя не должно быть, всё должно управляться и активироваться через Winbox авторизованным «пользователем».

И наконец, если ты хочешь делать это со своего рабочего места как админ — способов много. Настраиваешь туннель на его IP, отключаешь — и маршрутизатор направляет пользователя на локальный WAN. Включаешь во время нужного трафика, выключаешь в другое время.

Да, именно это и нужно. Можешь, пожалуйста, привести пример конфигурации для такой настройки?

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

Также нужно уточнить: если пользователю запрещён доступ к интернету через WireGuard, должен ли он вообще оставаться без интернета или получать доступ через локальный WAN?

Пользователь определённо должен иметь доступ в интернет через WAN обоих роутеров (через туннель или если туннель не работает).

Большое спасибо, Брайан.

anav

Guest

22.02.2023 17:05:00

Похоже, мы постепенно сужаем сценарий использования, ха-ха… Ты можешь настроить так, чтобы конкретный пользователь выходил в WAN другого роутера через WG. Не мог бы ты привести пример, как это сделать? (1) Вместо того чтобы форсировать весь подсеть через WG, можно сделать то же самое для отдельного IP-адреса, проще простого.

+++++++++++++++++++++++++++

Проблема в режиме по запросу. Это вопрос выбора — да или нет. Один из вариантов — позволить пользователю переключаться на обычный локальный WAN, если туннель WireGuard недоступен. То есть:
- туннель поднят >> пользователь использует WAN удалённого роутера,
- туннель упал >> пользователь использует локальный WAN роутера.
Если так, тогда давайте сделаем именно так.

(2) Это естественный способ, как может работать правило маршрутизации. Ты заставляешь пользователя из (1) выходить через туннель WireGuard с помощью такого правила:

/routing rule src-address=IPofUSER action=lookup table=useWG

action=lookup означает, что если таблица useWG перестанет быть доступной, роутер посмотрит основную таблицу маршрутов и найдёт другой путь! ГОТОВО!!!

action=lookup-only-in-table означает, что если WG упал, роутер НЕ будет искать альтернативный маршрут в других местах. Поэтому использование таблицы, дополнительного IP-маршрутизатора и правила маршрутизации, я думаю, покрывает твою задачу.

++++++++++++++++++++++++++++++++++++++++++

Наконец, если хочешь делать это с рабочего места в качестве администратора — способов много. Настраиваешь туннель к его IP, отключаешь его, и роутер направляет пользователя на локальный WAN. Включаешь на время трафика, выключаешь в нерабочее время. Да, именно это мне нужно, не мог бы ты привести пример конфигурации для такой настройки?

Отключаем маршрут к IP, чтобы обеспечить доступ, и тогда у пользователя не будет маршрута к туннелю… Тоже вариант, могу попробовать это или описанное выше и выбрать, что удобнее…

(3) Теперь в сценарии появился дополнительный элемент.

Сначала казалось, что мы решили твою задачу, настроив так, чтобы пользователь всегда был подключён через туннель WG и если он недоступен — переключался обратно на локальный WAN, всё автоматически, без участия пользователя и администратора!

Однако теперь видно, что ты хочешь иметь возможность в любой момент отключать пользователю доступ к туннелю WG… Контроль уровня ВЕЛИКОГО ВЛАСТЕЛИНА. Для этого нужно зайти в конфигурацию роутера, и проще всего — отключить дополнительный маршрут:

/routing rule add action=lookup disabled=yes src-address=IPofUSER table=useWG

Таким образом туннель остаётся доступен, просто для этого конкретного пользователя он не активен — он не будет выходить в интернет через туннель WG.

BrianRS

Guest

16.03.2023 17:28:00

привет, @anav, извини за очень поздний ответ, я был в отъезде и не было времени этим заняться... плюс у меня теперь второй провайдер/WAN для R1 (так что рекурсивная маршрутизация и балансировка нагрузки с mangle-правилами), и, возможно, именно из-за этого не работает «/routing rule src-address=172.16.11.32 action=lookup-only-in-table=WG». Думаю, ты, наверное, хочешь увидеть всю конфигурацию, правильно?

anav Guest	#5 0 16.03.2023 21:07:00 Обычно лучше решать проблемы, прежде чем наваливать новые дела, ха-ха.

BrianRS

Guest

21.03.2023 12:31:00

Да, @anav, в принципе, я тоже предпочитаю так подходить к решению проблем, однако у моего провайдера такой минимальный загрузочный канал, что я решил воспользоваться случаем и использовать этот комплект LHGG LTE6, чтобы иметь немного свободы действий. Так что теперь, хочешь, чтобы я обновил загруженную конфигурацию R1 и схему, может тогда двинемся дальше? Большое спасибо, B

anav Guest	#7 0 21.03.2023 12:42:00 Это уже было бы началом!

BrianRS Guest	#8 0 24.03.2023 11:13:00 Привет, @anav, на самом деле я выяснил, что могу сделать это с помощью одного простого правила mangle: add action=mark-routing chain=prerouting dst-address-list=!LAN new-routing-mark=WG passthrough=no src-address-list=FireTV. Но не уверен, использую ли я всю возможную производительность, потому что видео высокого разрешения всё равно периодически буферится. Это техническое ограничение из-за туннелирования или есть более эффективный способ? Чтобы понять ситуацию, ограничение по пропускной способности на стороне R2 (WAN) исключено, и при этом никакого буферизации нет, если обращаться к тому же источнику напрямую через WAN-интерфейс R1, а не через туннель, хотя у R1 есть ограничение скорости 25/5 Мбит/с на DSL WAN, которое, по-видимому, WG постоянно использует (не уверен, совпадение это или реальная настройка). Так что оно работает, но сейчас я не знаю, связано ли это с ограничениями или с неправильной настройкой производительности! Думаю, теперь ты понимаешь, зачем мне это было нужно, учитывая название списка источников. К тому же должен признаться, что меня реально впечатляет, как здорово работает рекурсивная маршрутизация вместе с балансировкой нагрузки через PCC, и особенно с помощью @Amm0. Мне удалось запустить скрипты, которые динамически обновляют таблицу маршрутов с используемыми шлюзами для обоих WAN при любых изменениях. Я уже обновил (после редактирования) файл конфигурации R1 и скоро обновлю схему, чтобы она соответствовала текущему состоянию! P.S. FW тоже получил немного ухода. Ещё раз спасибо за всю помощь!

Читают тему

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