keenet07

Вроде уже обещали увеличить, или даже увеличили. Говорили никаких проблем с этим нет. Но это не точно.

Более того, даже не обязательно VPN. У меня через WISP соединение работает. Лишь бы интерфейс был представлен в системе и шлюз.

У меня то через ipset-dns.

Там решение простое. Чтоб меньше переписывать, просто дописываете недостающие параметры в конфиг. И дублируете все скрипты во всех папках которые ставятся в оригинальном решении. Попутно меняете во вторых копиях параметры на настройки для второго VPN из конфиге. И в одном из скриптов указываете какой порт слушать вместо 5353. Дальше просто. Если нужно направить домен через первый VPN ставите в записи порт 5353, если через второй то с другим портом. Работать будет параллельно.

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

Спасибо. Вы абсолютно правы. Буквально несколько минут назад сам догадался указать вручную шлюз в эту строку через via и всё заработало.

В основе оригинальный скрипт. Через OpenVPN соединение всё работает. Как пустить нужные домены через WISP подключение? (это когда роутер подключается по WIFI к точке доступа на мобильном телефоне) Нашёл его в списке интерфейсов apcli0. VPN_SUBNET вписал 172.20.10.10/32. Именно та что получает устройство при подключении. Список ip адресов bypass формируется. Маршрут по умолчанию из table подставляется. Скрипты работают. Но трассировка спотыкается на втором хопе. Трассировка маршрута к myip.ru [178.62.9.171] с максимальным числом прыжков 30: 1 1 ms <1 мс <1 мс 192.168.1.1 2 172.20.10.10 сообщает: Заданный узел недоступен. Трассировка завершена. Это я проверяю с клиента домашней сети. Почему не идёт трафик? Где и что ещё нужно дополнительно разрешить? Особенности работы с WISP. Не знаю имеет ли это значение. В системе WISP является резервным подключением. Когда ставлю его основным подключением, понятное дело весь трафик роутера идёт через него. И всё что нужно работает. Проблемы с самой точкой доступа нет. Когда основным подключением является проводной провайдер. А WISP подключен, но висит как резервное подключение. Если добавить статический маршрут к нужному сайту через WISP по IP в меню Маршрутизация, то трафик корректно идёт через него, но вторым хопом там становится 172.20.10.1 (шлюз на ТД) а не 172.20.10.10 (адрес клиента WISP который получает роутер). Нужный сайт открывается. Скрипт же подставляет в маршрут именно 172.20.10.10 и в итоге трафика нет. Даже если в конфиге скрипта указать прямо адрес 172.20.20.1 то вторым хопом который недоступен всё равно будет 172.20.20.10. Он видимо сам его берет из системы по названию сетевого интерфейса apcli0 или исходя из самого маршрута. Но так не работает. Как это поправить? Может NAT какой в команде iptables нужен? В чем принципиальная разница между VPN соединением и WISP для роутера?

@Александр Рыжов и другие. Может кто-нибудь переписать эту приблуду таким образом чтоб она работала сразу с несколькими VPN (шлюзами, интерфейсами)? В моем случае VPN и WISP подключение. Второе нужно для выхода на некоторые ресурсы с которыми у многих сейчас проблемы через интернет розданный с мобильного телефона на WISP. Там это пока работает. Идеально было бы если бы записи к разным "ВПН" можно было задавать просто меня порт подключения в записи. Например, в моем случае это могло быть так: 192.168.1.1:5353 это через VPN и 192.168.1.1:5454 это через WISP соединение. Способ рабочий. По сути достаточно только три домена прописать.

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

Да всего лишь полностью переписать архитектуру прошивки. ) А ещё учесть систему зависимостей и всё такое...

И как отдельные компоненты будут устанавливаться на стороне клиента? Вся прошивка будет локально собираться? На микротике отдельная программа шьёт.

Да я понимаю. Озвучил свой взгляд. В целом я даже и не против чего-то такого.

Ну даже не знаю. Наверное тут больше вопрос к провайдеру чем к роутеру. Можно конечно много полезного, но потенциально опасного прикрутить, но наверное разработчик не станет этим усложнять себе и тех. поддержке жизнь. Проще окажется физически эту кнопку reset обезвредить. Или опломбировать.

А если пароль забыл?

Нужные люди уже увидели. Думаю поправят в одной из следующих версий.

Возможно есть ошибки. А сам то этот режим то вам нужен? Пользуетесь? Можно отключить в параметрах системы.

Оно есть и во вкладке Анализатор трафика. Вот если оттуда реализовать переход к функциям работы с клиентом в Список клиентов. Вот тогда можно было бы и видеть трафик и заблокировать или ограничить скорость клиенту без лишних путешествий и поисков по интерфейсу.

Зачем ему метаться? Запрос отправляется сразу на все одновременно. Который первый ответил, тот и быстрее. И так с каждым запросом. Чем больше серверов, тем потенциально стабильнее. В какой-то момент основной может оказаться чуть более загружен, ответ быстрее придёт от второго или вообще от DNS другого сервера, если пропишите ещё пару сторонних.

Версия 4.2 Alpha 17 Теперь всё ок. Спасибо.

Всё верно. В кейсе топикастера удобнее использовать политики. Эксклюзивный маршрут как вспомогательное средство со схожим функционалом.

Есть ещё вот это https://help.keenetic.com/hc/ru/articles/360000925780-Статические-маршруты см. Эксклюзивный маршрут.

Нет, ну конечно вести, при изменениях. Но так же как оборудование с истекшей гарантией. Да, это доп. нагрузка. Просите надбавку ЗП. )

А можно было бы вывести все такие неоднозначные или сложные в юзабилити функции и возможности в какое-то скрытое по умолчанию меню. Назвать это экспериментальными функциями. Официально не документировать, разве что на форуме. Не распространять на них тех. поддержку. До возможного момента смены их статуса. Я бы за такое проголосовал. ) И овцы целы и волки сыты.

Ну видимо потому-что домен youtube.com хоть и имеет множество IP которые можно добавить, но это только доступ к самому сайту. Видео на нем как правило загружаются с различных сторонних облачных или кэширующих серверов, в адресе которых скорее всего домен youtube.com даже не присутствует. Таким образом если ресурс заблокирован полностью, включая и такие сервера (что не всегда бывает возможно сделать в виду их универсальности) то и видео поток не будет работать, хотя сам сайт загружаться будет. Если эти сервера не блокировались, то будет. В любом случае, штука была бы удобная. Останется только добавить в маршрутизацию определенные подсети. А на большинстве ресурсов и без этого заработает.

Хотелось бы видеть больше полезной информации в меню Другие подключения о статусе VPN-подключения. Сейчас это выглядит так для OpenVPN подключения: жмем переключатель установки соединения и статус меняется с "Отключено" на "Неизвестно", а дальше либо подключение устанавливается и статус меняется на то что соединение установлено, либо он так вечно и висит в стадии "Неизвестно", если что-то не так. А нет ли возможности в этом же статусе отобразить в чем собственно заминка, что там происходит с соединением? Ну самое минимальное, хотя бы показать, что соединение не установлено и идёт очередная попытка подключения или инициализации. А то либо ждать, либо в лог лезть смотреть. Хотя что-то понять можно было бы уже и в этом меню.