Le ecureuil
-
Постов
10 850 -
Зарегистрирован
-
Посещение
-
Победитель дней
634
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
Если у вас Android подключается посредством IKEv2 через WAN, то через команду crypto map VirtualIPServerIKE2 virtual-ip interface Bridge0 присоедините его в сегмент Bridge0 (или в другой), а этот сегмент уже добавьте в политику. В итоге все клиенты этого IKEv2 сервера будут ходить в Интернет через политику, а в ней уже оставьте OpenVPN и все. -
Почему не добавите в конфиг секцию <auth-user-pass> vpnclient # логин r3d23xs87 # пароль </auth-user-pass> и дело с концом?
-
А зачем?
-
Встает на паузу он автоматически - планировщик ядра "тормозит" процесс transmission на операциях ввода вывода настолько, чтобы он не мешал другим. С точки зрения самого transmission выглядит так, что накопитель стал сильно медленнее работать, только и всего. По сути ваши тормоза переносятся на тормоза transmission.
-
Есть уверенность, что это не "внешние силы"?
-
В таком случае обратитесь в официальную поддержку, там вам помогут снять правильную диагностику, чтобы понять, что происходит.
-
Сейчас никакими средствами это сделать не выйдет, но по-хорошему нужно следующее: - добавить в сборку CFQ IO-планировщик - назначать transmission и всем его дочерним процессам приоритет IO idle В таком случае transmission будет работать только если никому еще не нужен диск, иначе пойдет на автоматическую паузу.
-
А вы уверены, что дело в Keeentic, а не в том, что IKEv2-соединения фильтруются провайдерами и ТСПУ? Можете проверить на ПК или на смартфоне, соединение устанавливается?
-
Пока никак, но команду в cli для этого приделаем.
-
Когда будет очередной выпуск draft / beta.
-
В апстриме ядра был найден коммит, похожий на правду https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/netfilter/nf_queue.c?h=linux-4.14.y&id=f7e6a2f9e2f2b7d87cded41f904268865f44f967 Занес его к нам, проверяйте на следующих версиях.
-
Вобщем, проверяйте на следующей beta.
-
У меня почему-то удаленная сторона WARP с вашим конфигом вообще не отвечает. Потому проверьте на следующей бете сами. Команда interface Wireguard0 wireguard peer <peer> client-id send <value> value - десятеричное число, сделанное простым переводом hex: из 0x1620a6 получается просто 1450150 В итоге в сеть улетает как задумано:
-
Посмотрел self-test'ы, ничего фатального не вижу. У вас очень прилично ушло в TCP slab, но у вас в opkg запущены жирные процессы, и это, наверное, норма. Попробуйте понаблюдать неделю без перезагрузок, и посмотрите на результат.
-
Нет, напишите скрипт в opkg который будет передобавлять.
-
Это сообщение, конечно, неприятно, но по сути не должно влиять на общую работоспособность (кроме получения роутов с удаленной стороны). Какие наблюдаются вопросы кроме этой записи?
-
Конфиг вообще не сохраняется, или его невозможно скачать? Что сообщает команда system configuration save в лог?
-
Я правильно понял, что нужно три байта подствлять в message_header при отправке, и все?
-
MWS есть?
-
Пришлите, пожалуйста, self-test скрытым файлом снятый в момент, когда все включено, но не работает. И еще конкретный хост подскажите (его MAC или IP), с которого вы пытаетесь это проверить.
-
Это, по сути, и есть автоматический фаервол. Прописывайте mac-и ваших серверов, и все будет работать.
-
Пришлите self-test в момент, когда "висит и не работает".
-
Нет, только версии 3.5 и выше.
-
Прочитайте 2 поста выше.
