Valery Lutoshkin

С п.5 заработало, спасибо! Но на одной из инсталляций выдало при первичной настройке вот такое: Естественно, никаких 32 VPN интерфейсов там нет. Перечислены, похоже, вообще зарегистрированные компьютеры (а 30-31 пункты - это br1 и br2 соответственно, а 13 - WAN). П. 29 тоже как-то странно сложился из разных IP.

Доброго. Обратная связь - проапгрейдил до 1.1.7-3, теперь поведение с kvas vpn net add стало еще интереснее. Команда выполняется, пишет успешно добавлен, но в гостевой сети не работает, а последующая команда kvas vpn net показывает, что интерфейс не добавлен.

Есть группа интерфейсов, показываемых в kvas vpn net. Сейчас выглядит вот так: Сети Guest и Phones добавлены через kvas vpn net add. Сеть WG MSK никогда не активировалась через kvas vpn net add. При попытке исполнить kvas vpn net del и выборе этой сети - все отрабатывает как бы корректно: но после этого вывод команды kvas vpn net не меняется - на 4 месте так и остается WG MSK с параметрами ВКЛ, ДОБАВЛЕНА. Обратил сейчас внимание, что скрипт говорит про интерфейс nwg0, а на самом деле он wg0 же. В дебаге сети отличаются в выводе тоже: Не может ли быть причиной проблемы пробел в имени сети? Она "WG MSK" называется, с пробелом.

Так переподключение сетей тоже не помогло, к сожалению. Через vpn net del / vpn net add - не заработал сервис. Только через ручной набор правил.

Проапгрейдился с 1.1.6 до 1.1.7 release-2 - отвалились гостевые сети. Дебаг в аттаче. Есть предположение, что kvas не выставил в iptables соответствующий DNAT с редиректом. Т.е. после установки в iptables есть строки для ветки nat: -A PREROUTING -i br0 -p tcp -m set --match-set unblock dst -j REDIRECT --to-ports 1181 -A PREROUTING -i br0 -p udp -m set --match-set unblock dst -j REDIRECT --to-ports 1181 А трафик, приходящий из гостевых сетей (которые br1 и br2), под них очевидно не попадает Для эксперимента вручную добавил iptables -t nat -A PREROUTING -i br1 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.135.1 iptables -t nat -A PREROUTING -i br1 -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.135.1 iptables -t nat -A PREROUTING -i br1 -p tcp -m set --match-set unblock dst -j REDIRECT --to-ports 1181 iptables -t nat -A PREROUTING -i br1 -p udp -m set --match-set unblock dst -j REDIRECT --to-ports 1181 И сразу все заработало для гостевой сети br1. Возможно, это неправильный путь и трафик редиректится где-то в другом месте (iptables уж больно развесистый у кинетика), но вот такое решение у меня работает прямо сейчас. PS. И в целом что-то сломалось с работой kvas vpn net - показывает, что сервис включен для WG-интерфейса, хотя он там никогда не включался. При попытке удалить говорит "успешно", но при следующем запуске опять показывает, что включен. debug20240122.txt

Подключение других сетей на роутере к решению. Например, guest. Делается командой kvas vpn net add, поэтому я сократил до такой формулировки. Спасибо!

Конечно, можно и так, просто и такой строки в получающемся конфиге сейчас нет. Хорошо бы, чтобы была

@Zeleza а можно ли научить kvas не убивать полностью dnsmasq.conf при обновлении? Или хотя бы записывать в него по умолчанию что-то типа conf-file=/opt/etc/dnsmasq.local.conf (или что-нибудь подобное), в котором уже будут храниться специфические настройки? У меня в отдельном файле форвардеры для специфических доменов, и при каждом обновлении приходится не забыть сходить и поправить dnsmasq.conf руками. И еще - не знаю, баг это или фича, но после обновления сегодня на обоих роутерах пропали ранее добавленные vpn net, пришлось их тоже после обновления добавлять заново.

Ну я предполагал, что последний этап дебага - как раз показать содержимое ipset и проверить, все ли записи из нашего списка туда установились. Поэтому формулировка про них "адреса нет" меня несколько смутила и я искал причину проблем, пока не догадался посмотреть прямо в вывод команды ipset list unblock. Но могу быть не прав, конечно. И спасибо вам за решение, очень рад, что оно есть.

Доброго. При последнем этапе kvas debug префиксы не находятся в соответствующем ipset. При этом в выводе команды 'ipset list unblock' эти префиксы есть. Т.е. видимо парсер, который проверяет наличие и пишет в итоге "АДРЕСА НЕТ", не обучен находить именно префиксы.

Протупил и не прочитал документацию. Добавил префиксы меты через kvas add и проблема решилась. Можно копипастить ниже. Правда, debug не умеет нормально отрабатывать префиксы, поэтому не находит их в ipset. Но хорошо, что записывает

Коллеги, подскажите за фейсбук-инстаграм. Подключение через shadowsocks. Прописал вот таким образом их домены (цитата из /opt/etc/hosts.list): Но при этом в таблицу ipset попадают очевидно другие IP-адреса относительно тех, которые получают компьютеры в локальной сети (и понятно, потому что у этих сервисов очень агрессивный раундробин и на каждый запрос выдается новый адрес). Соответственно, ничего не работает, сервиса нет. Даже когда очень редко какие-то адреса совпадают — далеко не все, поэтому сайты открывается кусочками, а потом новый адрес - и опять не работает вообще ничего. Есть ли какой-нибудь файл, который не автогенерится, но подключается и в него можно просто положить всё адресное пространство IPv4 для Meta - чтобы весь их сервис гарантированно уходил в SS? Вывод дебага, как положено, прикладываю, хотя он тут малополезен.

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

Поддерживаю запрос, особо больно в таком режиме, когда основным стоит серый провайдер, что невозможно переключиться в прямой доступ и запустить ikev2. Хотелось бы иметь возможность привязаться прямым доступом к резервному каналу и запустить ikev2 на нем.

Понятно, что это уже ближе к энтерпрайзу. Но было бы полезно иметь возможность аутентифицировать пользователей VPN не по локальной базе пользователей устройства, а на внешнем сервере по любому из стандартизованных протоколов. В устройствах существует поддержка EAP для вайфая (WPA Enterprise), поэтому есть предположение, что подтянуть тот же EAP на VPN подключения может оказаться не очень трудоемко. Например, IKEv2 с EAP есть в некоторых сравнительно недорогих роутерах.

К сожалению, не могу найти там возможности по приоритету трафика выбирать канал связи (а не вытеснять трафик меньшего приоритета, как обычно работает QoS). Подскажите более конкретную ссылку, пожалуйста.

Анализатор трафика приложений сейчас прекрасно показывает данные в моменте за последние 3 минуты. Было бы полезно выгружать эти данные на внешний сервер, чтобы в дальнейшем анализировать из в долгосрочной перспективе. Самый простой и, вероятно, наименее трудоемкий вариант — сбрасывать эти данные так же раз в три минуты в syslog строкой в CSV ("клиент,категория1,объем1,категория2,объем2..."). Дальше уже это всё со стороны сервера разобрать, переложить в какую-нибудь TSDB (например, Influx) и отобразить в Grafana не составит труда. В большинстве использований SMB это будет огромным подспорьем системным администраторам.

В устройствах уже есть "Анализатор трафика приложений", который прекрасным образом классифирует трафик пользователей по группам. Было бы крайне полезно на основе этой классификации отправлять трафик в тот или иной канал (например, через логику "приоритетов подключений" - просто в качестве критерия задавая не клиентское устройство, а тип трафика из существующих или хотя бы уровень приоритета трафика из IntelliQoS). Это бы позволило, например, убирать голос и ВКС в канал высокого качества и низкой пропускной способности, для обычного трафика при этом используя более дешевый канал низкого качества (тот же мобильный интернет).

Там хуже - в принципе плохо предсказуемо, в каком сервисе будет следующая ВКС. Корпоративных сервисов много разных.

Нет, к сожалению, ВКСы могут быть достаточно широко размазаны по сети. Поэтому вопрос именно про классификатор — если он умеет классифицировать, то следующий шаг "для так размеченного трафика nexthop такой-то" не должен бы быть принципиально нереализуем.

Сам использую такое, правда не за кинетиком, но суть не меняется. 1. Proxy_pass на nginx будет работать хорошо, но нужно не забыть для сабдомена выпустить соответствующий сертификат, чтобы nginx отвечал по https. А сама вебморда внутри пусть по http работает. 2. Порты почтового сервера просто пробросить на 0.101. Сертификат для SSL не забыть уволочь с nginx и подложить почтовому. И повторять это при обновлении, скриптом. 3. Спам-валидаторы больше будут пугаться IP из пула операторских хоумюзеров. Но в целом большинство на них не реагирует уж очень активно. Надо не забыть от оператора добиться работающего бэкрезолва в существующее доменное имя, отрабатывающее в прямой резолв, потому что иногда это проблема. И вот на это антиспам реагирует болезненно. 4. Несколько доменов особо не усложняют решение. Всё работает. Btw, из яндекса мне оказалось проще уйти на VPS внешний, который и так существовал для VPN-туннеля, и не греть голову.

Добрый день! Вероятно, такой вопрос задавался, но где-то с полчаса искал похожие темы — не нашел (возможно потому что я в кинетике нуб и не совсем хорошо понимаю внутреннюю терминологию), буду признателен, если ткнете непосредственно в статью. Дано: Giant, 4.0.2. Два внешних канала — один условно WAN "дорогой и хороший" (низкий джиттер, минимальные потери, небольшая выделенная полоса), второй - Mobile "дешевый и плохой" (джиттер и потери достаточные для BE-трафика, но войс там уже очень так себе работает). Есть несколько клиентов, каждый из которых бродит в сети и иногда участвует в звонках и ВКС. Включен "Анализатор трафика приложений", который прекрасным образом классифицирует нужный трафик и показывает его (пытается использовать QoS, но так как очереди появляются отнюдь не на портах маршрутизатора, QoS не работает по понятным причинам). Есть ли возможность на кинетике трафик, который анализатор помечает как высокоприоритетный (в нашем случае STUN), отправлять в дорогой канал, а весь остальной трафик - в другой? Использую фичу управления через "приоритеты подключений", но там раскладка по каналам реализуется по устройствам, а не по типу трафика.