slydiman

Воткнул в POE шлюз SSC-PS308G. Там 8 POE портов, 2 гигабитных uplink LANs и SFP. Есть 2 режима VLAN - port и tag. В режиме port, только POE портам можно выбрать VLAN group от 1 до 8. При этом 2 LAN порта никак не настраиваются. Из китайской документации: Очевидно очепятка. Всё бы хорошо, если бы можно было задействовать не только POE порты. Выбирать двум POE портам отдельную группу, в один порт втыкать камеру, а другой POE порт в роутер (в тот самый LAN4, через POE сплитер разумеется) - видимо единственное решение. В режиме tag можно POE портам прикрутить PVID от 2 до 4096. При этом двум LAN и SFP порту прикручено 1 и поменять нельзя. Из китайской документации: Видимо это всё мало полезно. Вывод - просто забыть про тегирование VLAN. Всем спасибо.

Давайте конкретику. IP камеры 192.168.4.2, ей его выдал роутер по DHCP. Далее без перезагрузок роутера или камеры я включаю VLAN ID 4 на порту, куда воткнута камера, трафик становится тегированный. Как получить доступ к камере хотя бы из домашней сети с 192.168.1.x? > Если камера не умеет тэгированный трафик, то тут только VLan на основе портов. Не умеет что конкретно? Тут и есть VLAN на основе портов. В вопросе #1 камера втыкается в порт роутера, которому прикручен VLAN ID 4. В вопросе #2 камера втыкается в порт шлюза, которому прикручен VLAN ID 4. Как получить доступ к камере из домашней сети, которая в роутере 192.168.1.x и которой не задан VLAN ID? В вопросе #2 нужно ещё как-то сегмент CAM в роутере прикрутить к VLAN ID 4, не тегируя при этом никакой физический порт роутера.

По делу пожалуйста. Я всё это и не только перечитал. И там нет ответов на мои вопросы. Разумеется. В 1 пункте написано что камера получает IP 192.168.4.2 и прекрасно выходит в интернет и к ней прописан доступ из домашней сети. Проблемы начинаются при включении VLAN ID 4 на порту, куда воткнута камера. Про шлюз разговаривать нужно после того, как на роутере к сегменту будет прикручен VLAN ID 4 без привязки к физическому порту LAN4. И это часть вопроса 2.

1. Домашняя сеть 192.168.1.1. Создал сегмент CAM с IP роутера 192.168.4.1. Этот сегмент привязан к порту LAN4 без тегирования. Подключил туда камеру, которой закреплен IP 192.168.4.2. Камера выходит в интернет (подключается к своему облачному серверу), к камере есть доступ из домашней сети (прописан маршрут). В файрвол ничего не добавлял. Теперь к порту LAN4 прикручиваю тегирование VLAN ID 4. Камера интернета больше не видит, доступа к камере из домашней сети больше нет. Вопрос - как получить доступ к камере из домашней сети и пусть камеру в интернет, когда камера тегируется VLAN ID 4? Никакие правила файрвола не помогли. 2. Есть управляемый шлюз. Один из портов на этом шлюзе будет прикручен к VLAN ID 4 и камера переедет туда. Шлюз подключается к роутеру в LAN2, который входит в домашнюю сеть. На том же шлюзе в других портах куча других устройств домашней сети. Вопрос как прикрутить камеру к сегменту? Очевидно LAN4 на роутере уже будет отвязан от сегмента CAM за ненадобностью. Как задать привязку сегмента CAM к VLAN ID 4? Будет ли через порт LAN2 приходить тегированный трафик VLAN ID 4? И как в 1 вопросе - как получить доступ к камере из домашней сети и пусть камеру в интернет, когда камера тегируется VLAN ID 4?

Физическое подключение до свича провайдера 1гбит. Провайдер соответственно тарифу ограничивает канал до 300мбит. Авторизация по MAC, MTU 1500, никаких других VPN типа L2TP и пр. OpenConnect сервер поднят на VPS с каналом 100мбит. tls-priorities как сказано выше LEGACY:+CHACHA20-POLY1305:... UDP выключен на сервере. Скорость мерялась speedtest.net до соседнего с VPS провайдера. Keenetic Hopper (KN-3810) давал 18-20мбит. Keenetic Hopper SE (KN-3812) даёт 43-49мбит (upload до 83мбит). Но если выключить OpenConnect клиент на роутере и поднять OpenConnect клиент на Windows машине через тот же роутер, то скорость всё равно выше 90мбит. То есть Hopper SE по сравнению с Hopper даёт прирост скорости в 2-3 раза. Похоже скорость могла бы быть в 4-5 раз выше, но роутер не тянет. В скорости под 120мбит через OpenConnect клиент на роутере с выключенным UDP я не верю. Хотя возможно OpenConnect клиент на Windows использует другое шифрование и оно иначе обрабатывается в черном ящике dpi у провайдеров. Тут слишком много факторов, которые могут влиять. Если сохранить настройки роутера, то у Hopper я вижу "crypto engine hardware", а у Hoper SE я вижу "crypto engine software". Это нормально/правильно?

Так не бывает. Заказал Hopper SE. Через неделю напишу как оно на самом деле в сравнении со старым Hopper при прочих равных.

Ещё бы уточнять на счёт вкл/выкл udp, ибо это даёт разницу в разы. Интересует в первую очередь без udp.

Вопрос был про производительность. Её кто-то мерял? Да, памяти побольше и побыстрее, 2 ядра ARM Cortex-A53 1300MHz вместо 2 ядер MIPS 1004Kc 900MHz. Основное отличие MT7981B - там 2.5Gbps, что нам никак не поможет. Сейчас Hopper (KN-3810) выдаёт 20Мбит, где теоретически может быть 700. Подозреваю что Hopper SE (KN-3812) выдаст к примеру 30МБит. Принципиально это ничего не меняет. Есть какие-то результаты реальных тестов?

При "-AES-256-GCM:-AES-128-GCM" на сервере не коннектится мобильная (Android) и яблочная версия Cisco AnyConnect. При этом Windows версия Cisco AnyConnect коннектится без проблем. "-CIPHER-ALL" не проверял, но стоит проверить.

Ну если UDP включен, то и обсуждать нечего, всё ясно. UDP - это палево и как долго это проработает - только вопрос времени.

Для чистоты эксперимента на сервере выставил такой же tls-priorities - максимум 20Мбит/с при тех же 60% загрузки CPU на KN-3810 (Keenetic Hopper). Осталось понять почему у кого-то выдаёт 100Мбит, а у кого-то 20Мбит/с. Но если поднять OpenConnect клиент на Windows до того же OpenConnect сервера через тот же канал, то скорость выше 90МБит/с. На всякий случай уточню - UDP конечно же выключено.

Подтверждаю. KN-3810 (Keenetic Hopper). Скорость OpenConnect клиента не более 10 Мбит/с в обе стороны. Если поднять OpenConnect клиент на Windows машине через тот же роутер до того же OpenConnect сервера, то скорость 94 Мбит/с. Измерял speedtest до того же сервера с разницей в минуту. Скорость OpenConnect клиента специально ограничена? Не похоже на ограничения производительности самого роутера. Про OpenConnect server пока речи нет.

Было что роутер Hopper (тот же Sprinter но с USB) терял провайдера или не получал IP. В настройках перевесил WAN на другой ethernet порт и переткнул туда кабель от провайдера. Всё стало стабильно работать. Причем другие устройства в этом же порту прекрасно работают на скорости 1 гбит/с. Очень схоже вот с этим вопросом.

На роутере поднят VPN сервер (не важно какой, допустим WireGuard). VPN клиенты выходят в интернет через этот роутер. Но имеется несколько WAN подключений и/или ещё VPN каналы, где уже сам роутер является клиентом В политиках доступа в интернет можно указать через что клиенты (устройства, подключенные к роутеру) выходят в интернет. Вопрос - как для VPN клиентов указать через что ходить в интернет? Эксперименты с маршрутизацией не увенчались успехом.

На роутере поднят VPN сервер (не важно какой, допустим WireGuard). VPN клиенты выходят в интернет через этот роутер. Но имеется несколько WAN подключений и/или ещё VPN каналы, где уже сам роутер является клиентом В политиках доступа в интернет можно указать через что клиенты (устройства, подключенные к роутеру) выходят в интернет. Вопрос - как для VPN клиентов указать через что ходить в интернет? Эксперименты с маршрутизацией не увенчались успехом.

Доступ снаружи к WEB интерфейсу роутера можно перевесить на другой порт. Нужно добавить порт форвардинг типа такого: Input - входящее подключение (со страницы Ethernen cable) Output - This Keenetic Ports TCP/8443 -> 443 Доступ снаружи будет примерно такой https://yourname.keenetic.link:8443/ Порт 443 может быть использован для сервера (другой форвардинг): Input - входящее подключение (со страницы Ethernen cable) Output - ваш сервер Ports TCP/443 -> 443 (или любой другой порт) Возможно по такому же принципу можно завернуть и ОС сервер.

Если прикинуть реальные сценарии использования, полагаю клиент гораздо нужнее.

В техподдержке мне намекнули про слухи о добавлении поддержки openconnect в прошивке версии 4.2, но это не точно.

Пересмотрел всю тему, не увидел. Если оно где-то в дебрях настройки ocserv или в соседней теме, то как человек нашедший эту тему это узнает? Всё что написал я можно взять и повторить. А "4 команды, о которых писал ранее" - это к экстрасенсу. Изначальная реплика была про ответственность, которую тут никто не несет за мои эксперименты. Вам тут какие-то воры померещились. Снёс давно Keenetic на Xiaomi и вернул X-Wrt. Забудьте.

К чему это? Тут кто-то за что-то несёт ответственность? Учитывая что Keenetic официально не поддерживает opkg вообще, за любые ковыряния с opkg никто ответственности не несет. Собственно поэтому я все эксперименты делаю на том, что не жалко.

Я не читаю соседние темы, я читаю эту. Ссылка или конкретные команды, "в интернете вагон" - это не о чём. Я понятия не имею какой интерфейс создаёт openconnect по умолчанию и переименование просто на всякий случай во избежание конфликтов. Разумеется в простых случаях можно не переименовывать. Где, какие? Как сложно общаться, когда "2 пишу, 3 в уме". Итог - да на Keenetic можно поднять openconnect, через одно место. На серьёзных роутерах с серьёзными конфигами это вообще не вариант. На простых роутерах проще использовать OpenWrt/X-Wrt ибо скорость та же (очень низкая), но есть хоть какой-то UI. Вопрос - как достучаться до представителей Keenetic и получить вразумительный ответ от них по поводу поддержки openconnect?

Именно так, только перед этим нужно установить iptables opkg install iptables Далее VPN на роутере поднимается следующей командой и всё работает (до поры): /opt/sbin/openconnect https://сервер:443 --interface=ssltun0 --no-dtls --non-inter --background --syslog --script /opt/lib/netifd/vpnc-script -u имя --passwd-on-stdin < /opt/etc/openconnect/password На всякий случай для тех, кто первый раз слышит про entware - все файлы лежат внутри /opt , поэтому такие пути, так задумано. Оставшиеся проблемы - как добавить в автозагрузку и как вырубить VPN при необходимости? Попробовал костыль в виде файла /etc/init.d/S90openconnect Внутри #!/bin/sh и команда, что дана выше. Дал файлу нужные разрешения chmod 777 /opt/etc/init.d/S90openconnect Эффекта нет. Кстати opkg mc на Keenetic не работает. Черно белая картинка и не работают стрелки на клавиатуре сводя на нет весь смысл. Собственно пока этого достаточно чтобы замерить скорость и сравнить с X-Wrt. Провайдер 500 мбит. ocserv поднят на VPS с каналом 100 мбит. Cysco AnyConnect под Windows до этого ocserv даёт скорость 70-75 мбит. openconnect на Keenetic и X-Wrt на Xiaomi MI-3G (MT7621) дают одинаковую скорость около 7 мбит (привет ADSL). Поднимать openconnect на чём-то серьёзнее типа Keenetic Hooper (KN-3810) я даже пытаться не буду, ибо без нативной поддержки в прошивке это совершенно не юзабельно. Печаль.

Ясно, всё делать самому. Начнём с малого Решение очевидно ровно такое же как для OpenWrt. Вот отсюда качаем https://letsencrypt.org/ru/certificates/ корневой сертификат ISRG Root X1 (файл isrg-root-x1-cross-signed.pem). Первая команда (может быть и не обязательно, только концы строк меняются с \r\n на просто \n): openssl x509 -outform PEM < isrg-root-x1-cross-signed.pem > letsencrypt_root.cert Вторая команда (вычисляем хэш): openssl x509 -hash -noout -in letsencrypt_root.cert У меня получился хэш "4042bcee". И наконец файл letsencrypt_root.cert переименовываем в 4042bcee и заливаем на роутер в /etc/ssl/certs/4042bcee После этого openconnect нормально валидирует сертификаты letsencrypt и не надо добавлять --servercert pin-sha256:...

Мягко говоря нет. Думаю, может я чего-то упускаю. На роутер Xiaomi MI-3G вместо X-Wrt поставил Keenetic 4.0.7 чтобы сравнить производительность openconnect клиента. Но не тут-то было. Давайте писать инструкции для нормальных людей, а не для линуксоидных гиков. И так чтобы это работало в реальной жизни на конкретных роутерах, а не на абстрактном НАСе с утверждением что на Keenetic всё будет также, но правда не совсем. Забудем пока про сервер и как в реальной жизни автоматически обновляется сертификат letsencrypt каждые 3 месяца. Простейшая задача - настроить на Keenetic VPN клиент openconnect: Это всё таки роутер и нужно чтобы не curl из соседней консоли мог достучаться куда надо, а клиентская машина через этот роутер, то есть должна быть прописана правильная маршрутизация. И нужно чтобы при перезагрузке по питанию всё это само восстанавливалось и не требовало ввода в консоли 100500 давно забытых команд. Итак, на Keenetic установлен openconnect. Из консоли VPN поднимается. Точнее сначала не поднимается, а ругается на сертификат letsencrypt, дескать не может проверить корневой сертификат. Благо сам openconnect предлагает решение - добавить параметр --servercert pin-sha256:... но похоже придётся обновлять эту команду каждые 3 месяца после перевыпуска сертификата letsencrypt и это так себе решение. Правильнее прописать корневой сертификат, но я пока не разбирался как это сделать для openconnect на Keenetic. Также возможно стоит добавить параметры --no-dtls --non-inter --background --syslog --script /opt/lib/netifd/vpnc-script --interface=ssltun0 Явно задать имя интерфейса (в данном случае ssltun0) поможет при дальнейшей конфигурации маршрутизации. Будет ли всё это подниматься само после перезагрузки? Наверное нет, то есть нужно куда-то прописывать. Но сначала нужно решить проблемы с маршрутизацией, ибо после поднятия VPN клиента, подключенные к роутеру клиенты уже никуда попасть не могут вообще. Нужно добавить что-то типа iptables -w -A FORWARD -i br0 -o ssltun0 -j ACCEPT но где и как - загадка, ибо роутер это всё таки не ubuntu. То есть пока утверждение не подтверждается. На OpenWrt/X-Wrt, не на всех, но на определённых версиях, openconnect работает из коробки, включая роутинг для клиентов. Очень хочется увидеть полноценную инструкцию. Заранее спасибо.

Эта тема хоть и называется просто openconnect и создана не мной, но очевидно целью создания этой темы было громко заявить о необходимости добавить полноценную поддержку openconnect в прошивку Keenetic, для начала хотя бы клиента. Также важный момент - официальная поддержка не распространяется на компоненты entware, то есть если у кого-то что-то не получится, поддержки спросить негде. В реальной жизни многие используют VPS и давно подняли там ocserv. Клиентов для openconnect полно под любую операционку или смартфон. Проблема возникает когда на роутере чуть больше чем 1 VPN клиент и больше чем полтора клиента. Услышьте пожалуйста - нужна полноценная поддержка openconnect в прошивке чтобы можно было через UI настраивать правила для разных клиентов и пр. Да, можно пол дня тыкать в консоль, но когда я за рулём, мне звонят и нужно что-то переконфигурировать, я могу это сделать в 3 клика в UI со смартфона, а не с компа на следующий день. Тут рядом ещё есть тема про Cisco AnyConnect, где было заявлено что этим пользуется полтора человека и это никому не нужно. Если лично вы не пользуетесь этим, это не значит что это не востребовано. Другое дело, если разработчик не хочет или не может это сделать. Тогда так и скажите что поддержки openconnect не будет по такой то причине.