Le ecureuil
-
Постов
11 072 -
Зарегистрирован
-
Посещение
-
Победитель дней
648
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
Попробуйте 0 вместо 7, или явно указать "sun". -
Файлы *noLAN битые (пустые). Эта схема вам (на мой взгляд) подойдет больше, приложите нормальный вариант файлов и мы по ней сделаем.
-
Скидывайте self-test, подскажу что и куда ввести, чтобы заработало, как вы хотите.
-
Во всех серверах и клиентах должно работать.
-
Вы пишете в теме, в которой в первом посте описано о GRE/IPsec, IPIP/IPsec и о EoIP/IPsec, а также о чистых GRE, IPIP и EoIP. То есть во всех Keenetic (кроме устройств на 3052/5350) это уже больше года как есть.
-
Zywall больше не наши, и вообще они умеют GRE/IPsec (насколько я помню из их настроек). Неужто Juniper SRX не умеет GRE/IPsec?
-
Судя по опыту прошлых лет, скорее всего мы не будем лепить костыли под чужое вендороспецифичное решение.
-
Смысла нет абсолютно, особенно после появления автотуннелей и L2TP/IPsec всех видов. Берите и используйте, а не костыли лепите.
-
Так не будет работать ни один VPN из-за Reverse Path Filtering - у вас получаются на 1 устройстве два интерфейса с одинаковыми ptp/gw адресами, что является нерабочей схемой. Или делайте еще один сегмент на роутере с другой подсетью, и привязывайте vpn к нему.
-
Они здесь, мы их видим. Большое спасибо.
-
А вы можете self-test с включенным system debug предоставить с 2.11.A.6.0-0 и с текущего драфта, где он отваливается? Было бы очень полезно для нахождения причины.
-
Все поправлено, причем было сломано получение на всех интерфейсах, в том числе и на L2TP и PPTP. Главное - удаленный адрес в VPN должен отличаться от локального, иначе из-за Reverse Path Filtering вы ничего не получите. То есть если на сервере VPN привязан к интерфейсу с адресом 192.168.1.1, то на клиенте не должно быть интерфейса с таким адресом (а желательно чтобы и с подсетью, иначе будет конфликт роутинга, который будет маскироваться из-за метрики).
-
Там рассылка исправлена, а не прием. Прием пока еще в стадии отладки. Когда сломался - неизвестно, но факт, что сейчас не работает.
-
Угу, отловил этот баг тоже. Поправлено.
-
Там по идее должно прийти событие c DHCP INFORM, и отразиться в логе.
-
@r13 Насчет дублирования правил - спасибо, найдено и поправлено.
-
Насчет маршрута - а клиент что? Он его запросил? Добавил к себе в таблицу маршрутизации? Хотя, пока не исправите interface ISP на interface Home у вас так и будет мусорный роутинг и DNS.
-
Все понятно с вами. Цитата из конфига: sstp-server interface ISP interface здесь - это один из интерейсов в домашней сети, обычно это Bridge0 / Home, а не интерфейс на котором надо слушать подключения. Все абсолютно также, как в PPTP и как в L2TP/IPsec сервере. У вас так настроилось через Web? Или руками вбили? Потому что это явный баг, если через Web.
-
Это всего лишь замена уже существующей дисциплины. На шейпер это никак не влияет - у нас отдельная от tc реализация. Ни один из ускорителей при этом не отключается. Относится ко всем железкам.
-
Старые домены (которые mykeenetic) не подходят. Работает только на новых доменах, на которых есть автоматическое получение сертификата.
-
self-test приложите. И вывод команды show sstp-server.
-
А можно еще попросить вывод more temp:/run/sstp-server/accel.conf с сервера, когда приходят такие DNS и удаленный хост (скрытым постом)?
-
Это конфигурационные. Для управления нужно слать команды через метод POST.
-
Да, тут пока так и будет - особенность реализации.
-
Я так понимаю, сервером выступает тоже Keenetic? Прошу снять self-test с обоих устройств: - на сервере нужно запустить > system debug - на клиенте нужно запустить > interface SSTP0 debug и после этого дождаться подключения.
