Pop70

И да. Вопросов про "допиливание" oldstable не должно быть. Понятно, что кучу разных веток тянуть - пупок развяжется. Если только, какие-то критичные изменения со стороны прилетят (вроде acme 3), или сами чего-нибудь в своих "облаках" намутят несовместимое.

В таком виде не вариант. Вся ветка 4.хх "stable", 3.9 "oldstable". Появится релиз 5.0, к тому времени 4ю опилят до состояния "oldstable". Нафига забагованные релизы сохранять, пока их не допилили? смысл именно иметь "откатанную", стабильную версию про запас

Значит, их конкретно задолбали. На моей памяти, разрабы весьма активно на этом форуме помогали даже с дурацкими вопросами (моими, например ). Много полезных знаний почерпнуто с этого форума. А сейчас в основном "отмораживаются" и кивают на оф. ТП.

Не факт. Скорее, "маркетолог" потребовал удивить базар. Вот и удивляют. "Один сломал, а другой потерял"(два метровых чугунных шара)

Роадмапы можно и на "бетах"("гамах") гонять, пока юзеры сами не убедятся, что с новыми прошивками они получат больше, чем потеряют. Я же говорю, что проблема "олдстэйбл" возникла исключительно от того, что в "стабильную" ветку попадает низкокачественное, неоттестированное, которому место ещё в бетах. И поддержку которым нужно бы ещё на форуме вести, а лучше на багтреккере, где и пользователям проще, и разрабам.

Дык... это, как раз, повод не пересаживать насильно на "новые-мажорные", пока их "минорными" не допилят. Это ли не принцип "беты", которую всем желающим предлагают, а не желающие на стабильной остаются, если бета чем-то конкретно подгадила? Вот и с "олдстэйбл" вопрос из-за этого же возник. Из-за того, что "стэйбл" по факту бетой оказалась. А то, что это давно происходит, для меня не новость. Я с этой 4-й "стабильной бетой", как раз в премодерацию влетел, когда выразил своё фи офподдержке и позиции поддержки на форуме только бет. Ну правда, выбесило это очередное "мажорное бетатестирование"

Это легко делается через CLI. Немножко только, совсем чуть-чуть поднапрячься, и несколько команд написать хоть в веб-интерфейсе /a

Хех... Это обратная сторона "мегафичь", за которые, кстати, кинетик и выбирают. То acme отвалится - и хочешь-не хочешь, а переделать надо, иначе тыква..., то собственные "облака" переделают. И обратная сторона схемы сборок. А у "других производителей" заявленный основной функционал изделий не деградирует при обновлении, как это с 4й "стабильной", а по факту бетой произошло. Оно бы и не нужен был "oldstable", если бы "stable" не оказался сырятиной.

А ничё, что "полный набор" в некоторые аппараты просто не влазит?

Вообще не понимаю принципа привязки sstp и ikev2 сервера к доменному имени keendns. У меня на "белом" адресе вообще есть своё доменное имя, даже с прописанной обратной зоной, и с сертификатом, получаемым тем же роутером. А keendns вполне устраивает в облачном виде. Почему нельзя (или как-то через cli можно?) привязать sstp или ikev2 к "независимому" домену? Облачный keendns тем и хорош, что облачный, и поднимется на любом, самом неожиданном подключении к и-нету, и даст доступ к телу. А так - да. "Белый" гусь сдох, и приплыли... (Если sstp или ikev2, и "авто" не годится)

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

Во всяком случае, то, что есть в справочнике по CLI уже можно пользовать.

И это... попытки вывести справку по ndmc, тоже успехом не увенчались. Ни -help не работает, ни -?, ни help ndmc. Где получить доступ к тайным знаниям?

Я знал! Я знал, что оно должно быть :). А где почитать про другие специфичные утилиты?

Собственно, возможно ли из entware посылать команды в CLI кинетика? Не в смысле "подключиться телнетом и посылать", а какими-то другими способами? Ну, вот простенькая задачка. Нужно перезапустить OpenVPN0 на кинетике. "interface OpenVPN0 no up", "interface OpenVPN0 up". Есть чистая установка Entware. Как это должно (может) выглядеть в скрипте? Может быть, у кого-нибудь есть ссылка на более подробные мануалы, чем описание opt/ndm/*.d?

Заставить работать кинетик в таком случае можно только если одно из подключений пропустить через ещё один маршрутизатор (и его NAT).

Другие - по сути L3. А tap в ovpn - это L2. - что на уровне L2 "прилетело" с одной стороны, то же на другой стороне и "вылетело". Только на уровне link-ов по L3 ходит. Тот же L2tp в мост не цепляется, а потому, что "вход-выход", всёже, L3 Ну, так мне это виделось. Ещё раз спасибо за помощь.

Без идеи, tap-интерфейс - это как провод между свичами. У него не может быть "своего mtu". Там даже маршрутизатор "не маршрутизирует" - "просто мост". С tun - другое дело.

Вот отсюда, видимо, и расхождения в соответствии link-mtu и tun-mtu, и разный "зачёт" tun-mtu-extra в разных версиях ovpn?

Я думал, что этот "служебный трафик" учитывается в link-mtu, а tun-mtu, по идее, должен соответствовать mtu пакетов в виртуальном туннеле.

Да. Ха! Помогло обратное. Прописал tun-mtu 1514, и теперь пинги ведут себя как положено. С -f идут по -l 1472, потом ругаются на "не фрагментировать" Без -f пинги ходят любые. OpenVPN где-то сжирает ещё 14 байт от параметра tun-mtu. Реальный mtu в туннеле на 14 байт меньше, чем параметр tun-mtu. Возможно, это из-за разных версий клиента и сервера? Или так и должно быть?

Да. Не помогло. Теперь через туннель проходит ping -l 1394 mtu снова на 14 байт меньше, чем должно быть. ping с разрешённой фрагментацией, больше, чем -l 1394 просто теряется. Не фрагментируется.

ОК, спасибо. Буду пробовать.

Т.е., ещё уменьшить tun-mtu на обоих концах туннеля? Допустим, пишу им (серверу и клиенту) tun-mtu 1436 А на интерфейсе "Home" (к которому комп подключен) надо "подравнять", или кинетик, получив 1500, отправит в интерфейс openvpn1 уже значение как в tun-mtu, фрагментировав пакет, или отбосит, если df ? Но там же "мост"...?

Через туннель нет. Напрямую в интернет - да. Он же фрагментирует "по максимуму", по mtu до следующего узла. А на интерфейсе, к которому подключен комп mtu 1500