Как указать профиль доступа для клиентов VPN?

[Antonio]

Здравствуйте.

Имеется Гига 1011, на ней работает 2 интернет провайдера - один с белым ip, а второй - с серым ip. Для упрощения буду называть их белым и серым каналом.

Часть клиентов использует белый канал, часть - серый. Для этого создан профиль доступа "серый" в котором указан серый канал, а в основном (дефолтном) профиле включен - белый канал. Для правильной работы КeenDNS нужно чтобы в основном профиле использовался именно белый канал. Т.е. поменять местами профили или каналы в профилях нельзя.

На гиге включен VPN сервер (SSTP) с включенной настройкой NAT, чтобы клиенты могли выходить в интернет и создан клиент для работы с VPN (vpnklient). Требуется, чтобы vpnklient выходил в интернет строго через серый канал ("серый" профиль доступа).

Логично было бы увидеть подключенного клиента VPN в списке незарегистрированных устройств и перетащить его в "серый" профиль, но vpnklient в этом списке не появляется. При этом выход vpnklient в интернет происходит через белый канал (дефолтный профиль доступа).

Настроек профиля доступа для пользователя "vpnklient" не существует, поэтому через настройки пользователя заставить его использовать серый канал нельзя.

Решил сделать через сегмент сети. Создал сегмент сети с названием ВПН, назначил этот сегмент для использования клиентами VPN в настройках SSTP, в настройках сегмента сети указал использовать для выхода незарегистрированных устройств в интернет "серый" профиль доступа. Плашка с названием "Незарегистрированные устройства сегмента "ВПН"" появилась в сером профиле доступа, всё должно работать нормально и vpnklient должен при такой настройке получать доступ в интернет через серый канал, но он всё равно использует белый.

Только если серый канал использовать в дефолтном профиле получается заставить клиента VPN ходить в интернет через серый канал, но при этом возникают проблемы с KeenDNS и VPN канал начинает работать только через облако со снижением скорости и пр. проблемами серого ip. Такой футбол нам не нужен)

Что я делаю не так, почему vpnklient для выхода в интернет пользуется только дефолтным профилем, игнорируя настройки сегмента? Как заставить клиента VPN использовать "серый" профиль доступа в интернет вместо дефолтного?

Изменено 15 июня, 2022 пользователем Antonio

[vasek00]

Из своего опыта при наличие двух каналов то лучше использовать не основной а два доп.профиля или

1. Основной остается для сервисов роутера

2. Для клиентов "белый" активен белый канал

3. Для клиентов "серый" активен серый канал

Клиент на сером профиле, далее подключается к SSTP серверу роутера и что в итоге видим

Серый
~ # ip ro show table 44
default dev nwg4  scope link 
...
172.16.130.29 dev sstp0  scope link 
192.168.130.0/24 dev br0  scope link 
...
~ # 

где наш клиент имеет 172.16.130.29, и для данного профиля "серого" имеем default маршрут на "серый" канал nwg4.

Примечание :

данный стат маршрут будет добавлен везде и в основной таблице и в других таблицах профилей

Основной
~ # ip ro
default dev ppp0  scope link 
...
172.16.130.29 dev sstp0  proto kernel  scope link  src 192.168.130.101 
192.168.130.0/24 dev br0  proto kernel  scope link  src 192.168.130.101 
...
~ # 

Белый
~ # ip ro show table 42
default dev nwg0  scope link 
...
172.16.130.29 dev sstp0  scope link 
192.168.130.0/24 dev br0  scope link 
192.168.130.101 dev nwg0  scope link 
...
~ # 

Но так как клиент находится в "сером" профиле то все его пакетики промаркированы "серой" меткой и идут на "серую" таблицу маршрутизации.

 

Смысл наличия SSTP для локальных клиентов ?

Изменено 15 июня, 2022 пользователем vasek00

[Antonio]

Вы что-то не так поняли. VPN-клиент не на сером профиле, он вообще не локальный, а удалённый.

Вот на телефоне, например, стоит SSTP клиент и подключен через мобильного оператора, к SSTP серверу на роутере. Телефон коннектится к роутеру по логину и паролю, чтобы дальше выйти во внешний мир через серого провайдера, а выходит всегда через дефолтного, указанного в основном профиле. Хоть какие профили не настраивай - строго через дефолтный профиль доступа работает и ни в подключенных устройствах, ни в мониторе трафика не виден. Задача - сделать так, чтобы выход в интернет для этого клиента был не через основной (дефолтный) профиль. Сделать дополнительный профиль доступа или сегмент сети для этого клиента не проблема.

Изменено 15 июня, 2022 пользователем Antonio

[stefbarinov]

Попробуйте оставить основной профиль пустым, а для белого и серого создать два отдельных 

[Antonio]

14 часа назад, stefbarinov сказал:

Попробуйте оставить основной профиль пустым, а для белого и серого создать два отдельных 

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

[Antonio]

Создавать новые белый и серый профили тоже пробовал и переносил в разделе "Привязка устройств" все устройства и сегменты в новые профили, оставляя дефолтный основной профиль пустым (без устройств) - не помогает - все клиенты VPN всё равно получают интернет через этот основной профиль

[vasek00]

19 часов назад, Antonio сказал:

Вы что-то не так поняли. VPN-клиент не на сером профиле, он вообще не локальный, а удалённый.

Сервис SSTP это локальный сервис роутера который использует основной, данный клиент не какого отношения к зарег.клиентам уже не имеет.

Скрытый текст

или

default dev ppp0  scope link

172.16.130.29 dev sstp0  proto kernel  scope link  src 192.168.1.1

Если только переворачивать профили (или менять местами каналы для основного и тасовать клиентов по профилям), т.е. в основном имеете по приоритетам серый потом белый, но тогда все лок.сервисы пойдут тогда по серому каналу и так же SSTP клиенты. Или только с помощью ПО самого клиента например VPN Client Pro

https://help.keenetic.com/hc/ru/articles/360001381259

поковыряться в настройках данного клиента, а точнее в его маршрутизации но именно через ПО клиента.

 

 

Изменено 16 июня, 2022 пользователем vasek00

[Antonio]

Понятно, что сервер VPN, поднятый на роутере - локальный, но в нём есть настройка сегмента сети (что логично), в котором он работает. И если это сегмент "Гостевая сеть", и для сегмента "Гостевая сеть" настроены определённые разрешения, то как-то не логично, что они не действуют на клиентов, которые подключены к гостевой сети через VPN. Не находите? Имхо это глюк какой-то. Получается, что гостям, подключенным по wifi и кабелем доступен только гостевой туалет, а гости, подключенные через VPN ходят в хозяйский туалет, хотя им чётко указали, что они гости )

Изменено 16 июня, 2022 пользователем Antonio

[vasek00]

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

Понятно, что сервер VPN, поднятый на роутере - локальный, но в нём есть настройка сегмента сети (что логично), в котором он работает. И если это сегмент "Гостевая сеть", и для сегмента "Гостевая сеть" настроены определённые разрешения, то как-то не логично, что они не действуют на клиентов, которые подключены к гостевой сети через VPN. Не находите? Имхо это глюк какой-то. Получается, что гостям, подключенным по wifi и кабелем доступен только гостевой туалет, а гости, подключенные через VPN ходят в хозяйский туалет, хотя им чётко указали, что они гости )

Вы о чем. Данный вид подключения это тот же P-t-P или Point to Point или точка-точка, создается туннель. Клиент получил IP с маской 32

sstp0     Link encap:Point-to-Point Protocol  
          inet addr:192.168.1.1  P-t-P:172.16.130.29  Mask:255.255.255.255

Далее в настройках этому клиенту разрешается доступ к лок.сети роутера и соответственно правила маршрутизации (были выше).

Имхо это глюк какой-то. Получается, что гостям, подключенным по wifi и кабелем доступен только гостевой туалет, а гости, подключенные через VPN ходят в хозяйский туалет, хотя им чётко указали, что они гости )

Так как любой новый сегмент это новый сетевой интерфейс в данном случае bridge в который добавляются доп. интерфейсы роутера wifi и LAN, и он имеет private, есть настройка "Доступ к приложениям домашней сети" и

Скрытый текст

Между интерфейсами private и из private в protected устанавливать соединение запрещено по умолчанию, но при необходимости, доступ можно разрешить. Данная настройка зависит от установки параметра isolate-private. Если вам нужно разрешить соединения между интерфейсами типа private или между private и protected (т.е. не изолировать доступ), для этого выполните команду no isolate-private

https://help.keenetic.com/hc/ru/articles/360001434079

1.LAN порт 5 в новом сегменте

interface GigabitEthernet0/4
    rename 5
    switchport mode access
    switchport access vlan 3
    up


interface Bridge1
    description "\xd0\xa1\xd0\xb5\xd0\xb3\xd0\xbc\xd0\xb5\xd0\xbd\xd1\x82 2"
    include GigabitEthernet0/Vlan3
    security-level private
    ip address 192.168.2.1 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers
    up

ip policy Policy2
    description Anti
    permit global Wireguard4
...

ip nat Bridge1

ip hotspot
...
    policy Bridge1 Policy2
...

Попробую с данной аналогией возможные разрешения

1. "гостевой" туалет

2. еще разрешен и "хозяйский" туалет

3. хотите что-то еще для гостей помимо туалета отдельную выход на море нет проблем "policy Bridge1 Policy2"

Я только не понял зачем гости которые еще не приехали хотят воспользоваться "через VPN ходят в хозяйский туалет, хотя им чётко указали, что они гости" 😀

 

 

[Antonio]

Ничего не понял вообще)

[Antonio]

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

[Vichigor]

Вероятнее всего это надо запрос на доработку делать. Раньше на версии 3.х (если не ошибаюсь до 3.5) можно было делать: ip hotspot policy Wireguard1 allow 

И потом через web интерфейс перетащить в нужный профиль доступа.

[Antonio]

Я уже понял, что нельзя(

Убивает, когда такая простая и логичная вещь, которая уже есть в настройках и должна работать, просто не работает. Можно создать профиль доступа в интернет, привязать его к новому сегменту сети, привязать vpn к сегменту (хоть логичнее было бы привязать профиль доступа к VPN напрямую), но всё это будет попросту игнорироваться маршрутизатором вместо того, чтобы работать.

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

Облако и каналы кинетика перегружаются, что требует увеличения затрат на инфраструктуру, клиенты получают очень медленное соединение с ограниченным выбором типов VPN (остаётся доступен только SSTP) и плюются на компанию, у клиентов возникают проблемы с удалённым администрированием маршрутизаторов и работой приложения кинетик для смартфонов... Столько проблем из-за одной неисправленной ошибки/недоработки. Почему бы разработчикам не сделать хорошо и себе, и людям? Это же логично.

Изменено 7 июля, 2022 пользователем Antonio