Le ecureuil
-
Постов
11 324 -
Зарегистрирован
-
Посещение
-
Победитель дней
665
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
yota-yota проще всего с sstp. С реальным IP разницы нет, если сервер напрямую в Интернет не торчит - у вас кроме sstp выбора нет.
-
Версия ПО у вас какая? В 3.0 должно уже работать.
-
Разработчики не сами решают что им прямо сейчас делать (небольшой намек). Руководство считает, что это пока можно отложить.
-
Такое и правда может быть. Сейчас явно настроить роутинг для VPN-клиентов невозможно.
-
У вас оба WAN опущены, и они в разных подсетях. - Настройте общую подсеть - Соедините WAN-ы друг с другом - Настройте клиента, чтобы он подключался к WAN ответной стороны Должно работать.
-
Будет, главное чтобы они все были в одном L2-сегменте.
-
Ну в https://github.com/ndmsystems/packages/wiki/Opkg-Component#ndmpptp_vpn_upd в переменных окружения $iface есть имя системного интерфейса linux. Вот с него через ip a например считать. -
Отключите оба ppe и посмотрите, как работает fq_codel, который у всех стоит по умолчанию начиная с 2.11.
-
Раз поддерживаете, тогда уточните - вы это хотите в виде модулей в opkg и рулить самим через entware?
-
Стандартные Hilink-дашборды от операторов мы тоже стараемся поддерживать. Благо по API там разницы почти нет - только в дизайне и картинках.
-
А покажите-ка. Причем, чтобы в магазине можно было у нас купить, а не где-то там, за горизонтом...
-
gpon - это всегда почти 100% жесткая связка головы и абонентского оборудования, потому мы тут влезть без явного желания провайдеров не можем.
-
Тут на мой взгляд загвоздка в том, что пропадание связи с сервером окирпичит устройство - подвиснет все. Очень ненадежная конструкция, которую лучше оставить в opkg для тех, кто точно понимает зачем он это делает.
-
Там все равно link-local назначают сами стороны, проще в up-скрипте считать по systemname с интерфейса его local и remote адреса.
-
Спасибо за репорт, посмотрим.
-
Маловероятно, очень сильно разошлась кодовая база.
-
Версия 2.11.D.2.0-0: ACME клиент: бекпорт из 2.15: поддержка ACMEv2, удаление поддержки ACMEv1 обновлен openssl до 1.1.1c удален компонент cloudcontrol2 как неподдерживаемый L2TP/IPsec сервер: исправлено сохранение MTU/MRU kernel 3.4: рефакторинг механизма возврата памяти из кэша
- 32 ответа
-
- 15
-
-
-
PingCheck на EoIP вкупе с interface-restart. EoIP - stateless. Потому отслеживать его состояние нужно снаружи. Хотя при изменении состояния подлежащего интерфеса он должен тоже реагировать. Надо бы проверить это.
-
Site-to-site IPsec не умеет работать с транзитом и в режиме hub by design.
-
Вкратце там всего четыре команды: > interface SSTP<X> > peer <fqdn>:<port> > authentication identity <user> > authentication password <password> > connect > up Все.
-
Опишите ситуацию зачем это может быть нужно.
-
Собрано, проверяйте (только из CLI).
-
Версия 2.11.D.1.0-0: SSTP клиент: бекпорт из 2.15 обновлен пакет tzdata до версии 2019a обновлен openssl до 1.1.1b PPTP: исправлена обработка пакетов Echo Request/Reply (сообщил @T@rkus) DHCP Relay: возможность задавать любой IP-интерфейс в качестве WAN Wi-Fi: rt539x: исправлена совместимость с клиентами, высылающими Null data-фреймы между Auth и Assoc
- 32 ответа
-
- 13
-
-
-
Покажите конфиг, возможно ключ от ikev1 остался лишний или еще что.