Перейти к содержанию

Valery Lutoshkin

Участники форума
  • Постов

    22
  • Зарегистрирован

  • Посещение

Оборудование

  • Кинетик
    KN-1011

Посетители профиля

564 просмотра профиля

Достижения Valery Lutoshkin

Пользователь

Пользователь (2/5)

12

Репутация

  1. С п.5 заработало, спасибо! Но на одной из инсталляций выдало при первичной настройке вот такое: Естественно, никаких 32 VPN интерфейсов там нет. Перечислены, похоже, вообще зарегистрированные компьютеры (а 30-31 пункты - это br1 и br2 соответственно, а 13 - WAN). П. 29 тоже как-то странно сложился из разных IP.
  2. Доброго. Обратная связь - проапгрейдил до 1.1.7-3, теперь поведение с kvas vpn net add стало еще интереснее. Команда выполняется, пишет успешно добавлен, но в гостевой сети не работает, а последующая команда kvas vpn net показывает, что интерфейс не добавлен.
  3. Есть группа интерфейсов, показываемых в 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" называется, с пробелом.
  4. Так переподключение сетей тоже не помогло, к сожалению. Через vpn net del / vpn net add - не заработал сервис. Только через ручной набор правил.
  5. Проапгрейдился с 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
  6. Подключение других сетей на роутере к решению. Например, guest. Делается командой kvas vpn net add, поэтому я сократил до такой формулировки. Спасибо!
  7. Конечно, можно и так, просто и такой строки в получающемся конфиге сейчас нет. Хорошо бы, чтобы была
  8. @Zeleza а можно ли научить kvas не убивать полностью dnsmasq.conf при обновлении? Или хотя бы записывать в него по умолчанию что-то типа conf-file=/opt/etc/dnsmasq.local.conf (или что-нибудь подобное), в котором уже будут храниться специфические настройки? У меня в отдельном файле форвардеры для специфических доменов, и при каждом обновлении приходится не забыть сходить и поправить dnsmasq.conf руками. И еще - не знаю, баг это или фича, но после обновления сегодня на обоих роутерах пропали ранее добавленные vpn net, пришлось их тоже после обновления добавлять заново.
  9. Ну я предполагал, что последний этап дебага - как раз показать содержимое ipset и проверить, все ли записи из нашего списка туда установились. Поэтому формулировка про них "адреса нет" меня несколько смутила и я искал причину проблем, пока не догадался посмотреть прямо в вывод команды ipset list unblock. Но могу быть не прав, конечно. И спасибо вам за решение, очень рад, что оно есть.
  10. Доброго. При последнем этапе kvas debug префиксы не находятся в соответствующем ipset. При этом в выводе команды 'ipset list unblock' эти префиксы есть. Т.е. видимо парсер, который проверяет наличие и пишет в итоге "АДРЕСА НЕТ", не обучен находить именно префиксы.
  11. Протупил и не прочитал документацию. Добавил префиксы меты через kvas add и проблема решилась. Можно копипастить ниже. Правда, debug не умеет нормально отрабатывать префиксы, поэтому не находит их в ipset. Но хорошо, что записывает
  12. Коллеги, подскажите за фейсбук-инстаграм. Подключение через shadowsocks. Прописал вот таким образом их домены (цитата из /opt/etc/hosts.list): Но при этом в таблицу ipset попадают очевидно другие IP-адреса относительно тех, которые получают компьютеры в локальной сети (и понятно, потому что у этих сервисов очень агрессивный раундробин и на каждый запрос выдается новый адрес). Соответственно, ничего не работает, сервиса нет. Даже когда очень редко какие-то адреса совпадают — далеко не все, поэтому сайты открывается кусочками, а потом новый адрес - и опять не работает вообще ничего. Есть ли какой-нибудь файл, который не автогенерится, но подключается и в него можно просто положить всё адресное пространство IPv4 для Meta - чтобы весь их сервис гарантированно уходил в SS? Вывод дебага, как положено, прикладываю, хотя он тут малополезен.
  13. В нетфлоу мы можем слить 4 уровень модели (вплоть до порта), а упомянутый анализатор работает, как я понимаю, более глубоко, на сигнатурах трафика.
  14. Поддерживаю запрос, особо больно в таком режиме, когда основным стоит серый провайдер, что невозможно переключиться в прямой доступ и запустить ikev2. Хотелось бы иметь возможность привязаться прямым доступом к резервному каналу и запустить ikev2 на нем.
  15. Понятно, что это уже ближе к энтерпрайзу. Но было бы полезно иметь возможность аутентифицировать пользователей VPN не по локальной базе пользователей устройства, а на внешнем сервере по любому из стандартизованных протоколов. В устройствах существует поддержка EAP для вайфая (WPA Enterprise), поэтому есть предположение, что подтянуть тот же EAP на VPN подключения может оказаться не очень трудоемко. Например, IKEv2 с EAP есть в некоторых сравнительно недорогих роутерах.
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.