4.2 Beta 1 Не работают профили политик доступа?

[cheburashkaDDNS]

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

[FLK]

Ну, если все работает как вы хотели, значит все правильно)

 

Изменено 10 августа, 2024 пользователем FLK

[cheburashkaDDNS]

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

[vasek00]

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

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

Думаю у вас есть стат маршруты, которые вы вводили в WEB роутера.

 

Для начала по конф файлу :

1. "ip policy Policy" - описание политики, "description" - имя по WEB, "permit global" - разрешен канал выхода (интеренет), "no permit global" - не используется

2. "ip hotspot" - блок клиента, при установленном на сегменте "Без доступа в интернет" в этом блоке будет запись "policy Home deny" -> настройка по зарег.клиенту имеет приоритет по отношению к ней.

2.1 по клиенту который размещен в данной политике.

    host хх:хх:хх:хх:хх:хх permit
    host хх:хх:хх:хх:хх:хх policy Policy0

2.2 на основание данных настроек к данной политике привязана таблица маршрутизации в которой default (маршрут по умолчанию) будет на указанный "permit global".

3. Вводим стат.маршрут через WEB и ОНИ попадают во все таблицы маршрутизации которые есть в роутере (в политики то же).

 

Как в реале. Стат маршруты введенные в WEB - 64.233.160.0/19, 74.125.0.0/16 для интерфейса WG. Помещаем клиента в политику где только провайдер.

~ # ip rule
0:      from all lookup local 
...
454:    from 10.ПРОВ-шлюз.12 lookup 78 ***** таблица политики в которой клиент
...
~ # ip ro show table 78
default via 10.ПРОВ.1 dev eth2.9  src 10.ПРОВ-шлюз.12 
...
10.16.хх.0/24 dev nwg5 proto kernel  scope link 
64.233.160.0/19 dev nwg0  proto static  scope link **** стат маршрут из WEB
74.125.0.0/16 dev nwg0  proto static  scope link **** стат маршрут из WEB
....
~ # ip ro ************ для основного профиля
default dev ppp0  scope link 
10.ПРОВ.0/24 dev eth2.9  proto kernel  scope link  src 10.ПРОВ-шлюз.12 
10.16.хх.0/24 dev nwg5  proto kernel  scope link  src 10.16.хх.1 
64.233.160.0/19 dev nwg0  proto static  scope link 
74.125.0.0/16 dev nwg0  proto static  scope link 
...

Клиент который в этой политики в итоге при traceroute на данную сеть 64.233 пойдет не по default, а по стат.маршруту который был введен в WEB роутера и ЛОГИЧНО не должен был сюда попасть.

 

Не которые пожелания были

 

Изменено 15 августа, 2024 пользователем vasek00