MultiWAN policy routing в NDMS 2.12+.

[Le ecureuil]

Здесь идет все обсуждение MultiWAN в NDMS.

[Avaritia]

может кто подскажет, наверное это близко к обсуждаемой теме)

если к основному интернет соединению, добавляю ещё одно - резервное, например, wisp, можно ли как-то в стандартных средствах ограничить работу устройств через резервное соединение, чтобы пре переключении на резервное, работал только зарегистрированный desktop_pc2, а остальные устройтва нет? соответственны при основном, работали все устройства.

[r13]

45 минут назад, Avaritia сказал:

может кто подскажет, наверное это близко к обсуждаемой теме)

если к основному интернет соединению, добавляю ещё одно - резервное, например, wisp, можно ли как-то в стандартных средствах ограничить работу устройств через резервное соединение, чтобы пре переключении на резервное, работал только зарегистрированный desktop_pc2, а остальные устройтва нет? соответственны при основном, работали все устройства.

Сделать политику только с основным интерфесом и переключить всех клиентов кроме desktop_pc2 на эту политику

[Avaritia]

5 минут назад, r13 сказал:

Сделать политику только с основным интерфесом и переключить всех клиентов кроме desktop_pc2 на эту политику

а desktop_pc2 будет работать через основной интерфейс? самая идея в том, что например, домашняя сеть desktop_pc1, desktop_pc2, desktop_pc3 все они подключаются к основному интернет соединению pppoe1, когда то пропадает включается резеврное wisp, через которое может работать только desktop_pc2. само. автоматически.

[r13]

46 минут назад, Avaritia сказал:

а desktop_pc2 будет работать через основной интерфейс? самая идея в том, что например, домашняя сеть desktop_pc1, desktop_pc2, desktop_pc3 все они подключаются к основному интернет соединению pppoe1, когда то пропадает включается резеврное wisp, через которое может работать только desktop_pc2. само. автоматически.

Да, будет работать. Политиками вы определяете доступные для клиентов интерфейсы

[Avaritia]

И всё равно я вас не понимаю. Можно по шагам?

Т.е. в политиках доступа в интернет, я создал отдельное новое Резервное, где поставил галочку только на WISP.

Но в применении политики, я не могу добавить т.к. там могу двигать iPhone только или в Политику по умолчанию или в Резервное или в Без интернета, если передвигаю в резервное, то он сразу работает через WISP, а не через Основное. 

[r13]

Логика обратная

Поэтому в политике которая названа "Резервная" оставляем только PPPoE

Всех клиентов и сегменты которым запрещено использовать Wisp перетаскиваем в эту политику "Резервная"

[Avaritia]

Оригинально. Спасибо!

[firerat]

Подскажите пожалуйста, есть два прова (основной и резервный) подключенных к кинетику, второй пров является резервным для основного VLAN, и так же помещен в отдельную политику (Policy0), чтобы через него ходили в инет клиенты из другого VLAN. И есть интерфейс Wireguard, к которому подключаются удаленные VPN пользователи. Задача - клиенты заходящие через Wireguard должны nat-итися во второго прова.

Настроена политика Policy0

ip policy Policy0
    permit global GigabitEthernet0/Vlan7
    no permit global ISP

Для interface Wireguard1 сделал security-level private

Сделал ip nat Wireguard1

Но не могу сделать ip hotspot policy Wireguard1 Policy0, чтобы завернуть трафик из Wireguard1 во второго прова, в списке доступных интерфейсов его просто нет. В результате все клиенты wireguard идут через основного прова.

Подскажите как быть?

Изменено 5 февраля, 2024 пользователем firerat

[INFINUM]

форум мёртв? на свякий случай спрошу:

У меня арендован VPS с белым IP, который связан с моим роутером KN-1010 туннелем Wireguard. С внешнего IP VPS прокинут 443 порт через туннель до моего домашнего сервера, т.е. я публикую Web-сервер таким образом. Соответственно проблема заключается в том, что пакеты приходящие на домашний сервер из туннеля обратно отправляются через интерфейс WAN, а не через туннельный интерфейс (откуда они пришли) и TCP сессия не устанавливается. Оно и понятно, маршрут по умолчанию один через WAN интерфейс.
На Mikrotik эта проблема решается маркировкой входящих соединений с помощью mangle и отправка established соединений по тому маршруту, с которого они пришли (возможно я напутал что-то в терминах, но, надеюсь, вы меня поймёте). Но у меня Keenetic и у него нет mangle. Есть ли какие-либо варианты решения этой проблемы?

Изменено 6 февраля пользователем INFINUM

[aarnet]

12 минут назад, INFINUM сказал:

Есть ли какие-либо варианты решения этой проблемы?

не совсем понял - но разве маршрутизацией и политиками не решить эту проблему ?

[INFINUM]

3 минуты назад, aarnet сказал:

не совсем понял - но разве маршрутизацией и политиками не решить эту проблему ?

Как мне маршрутизация поможет?

[Le ecureuil]

Wireguard у вас имеет ip global? Клиент, к которому вы идете через WG в политике?

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

[INFINUM]

В 06.02.2025 в 14:53, Le ecureuil сказал:

Клиент, к которому вы идете через WG в политике?

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

вы о чём говорите??? При чём тут global ip WG? Какой резерв? Что за системная политика?

Изменено 7 февраля пользователем INFINUM

[Le ecureuil]

1 час назад, INFINUM сказал:

вы о чём говорите??? При чём тут global ip WG? Какой резерв? Что за системная политика?

Вы пришли в тему про Multiwan и политики доступа, так чего ж удивляетесь вопросам по сути?

[INFINUM]

27 минут назад, Le ecureuil сказал:

Вы пришли в тему про Multiwan и политики доступа, так чего ж удивляетесь вопросам по сути?

Мне кажется, Вы сути моего вопроса не поняли. Мне не нужно весь трафик через туннель направлять, при чём здесь политики?

Да, wg имеет глобальный признак, но находится в резерве, клиент в системной политике. Всё работает так, как должно работать, но не так, как вы думаете.

Роутер отправляет ВЕСЬ трафик на маршрут по умолчанию, который указывает на основной WAN интерфейс, независимо, от того, откуда пришёл запрос.

Я могу сделать маскарад для запросов со стороны туннеля, но тогда не будет работать блокировка по geoip.

Изменено 7 февраля пользователем INFINUM

[Le ecureuil]

Если у вас хост в локальной сети, на который проброшен порт из WG тоже находится в системной политике, то все должно работать само - проброс порта на соединение в резерве работает уже больше пяти лет.

[INFINUM]

8 часов назад, Le ecureuil сказал:

Если у вас хост в локальной сети, на который проброшен порт из WG тоже находится в системной политике, то все должно работать само - проброс порта на соединение в резерве работает уже больше пяти лет.

Проброс порта настроен на VPS. На роутере я проброс порта с IP, который ему не принадлежит, никак не настрою. Если бы я делал проброс с интерфейса роутера, тогда бы всё работало, но у меня белый IP находится за туннелем: Web client (Internet) -> global IP (VPS) -> tunnel IP (router) -> home server (local net). Техподдержка keenetic посоветовала snat сделать, наверное так и сделаю. Есть определенные неудобства в этом, но это самый простой вариант.

Изменено 11 февраля пользователем INFINUM

[INFINUM]

В 11.02.2025 в 13:11, Le ecureuil сказал:

Если у вас хост в локальной сети, на который проброшен порт из WG тоже находится в системной политике, то все должно работать само - проброс порта на соединение в резерве работает уже больше пяти лет.

Ну до меня дошло, что вы имеете ввиду. Изначально порт был проброшен непосредственно на VPS сразу до хоста в локальной сети и это самый правильный вариант, но кинетик не умеет такой трафик правильно маршрутизировать. Сейчас я сделал проброс на VPS до туннельного IP кинетика, а на кинетике уже пробросил порт с туннельного IP до хоста. Это "костыль", но по другому кинетик не умеет из коробки.

Есть ещё вариант с nftables в entware, но там всё очень сложно и это ещё больший костыль.

 

[Petr9]

При наличии более 1 WAN Интерфейса (например, 2 Ethernet провайдера) можно настроить маршрутизацию исходящего соединения через тот же WAN интерфейс, через который пришло входящее соединение?

[Le ecureuil]

21 час назад, Petr9 сказал:

При наличии более 1 WAN Интерфейса (например, 2 Ethernet провайдера) можно настроить маршрутизацию исходящего соединения через тот же WAN интерфейс, через который пришло входящее соединение?

Эти два соединения как коррелируют? Это разные TCP/UDP сессии?

[Petr9]

5 минут назад, Le ecureuil сказал:

Эти два соединения как коррелируют? Это разные TCP/UDP сессии?

Соединения никак не коррелируют, разные TCP/UDP сессии.

Нужно иметь возможность обращаться к одному LAN хосту или L2TP серверу через любой public IP (2 public IP от разных провайдеров). На RouterOS реализуется через mangle.

[Le ecureuil]

1 час назад, Petr9 сказал:

Соединения никак не коррелируют, разные TCP/UDP сессии.

Нужно иметь возможность обращаться к одному LAN хосту или L2TP серверу через любой public IP (2 public IP от разных провайдеров). На RouterOS реализуется через mangle.

Если запрос пришел снаружи, на один из резервных WAN по пробросу порта, то ответ уйдет туда же, а не в основной. Это уже с 2.13 работает.

Единственное ограничение - хост должен быть в системной политике.