Dale

Идеологически правильно было бы внедрить группы IP адресов (сетей). ИМХО, конечно. В идеале, конечно, динамическая загрузка группы данными, которые предоставлены в формате JSON, например, как вот тут https://www.gstatic.com/ipranges/goog.json

У меня гостевой сегмент вообще выключен. Прикрепляю письмом ниже селфтест с ретранслятора. На всякий случай - у меня ретранслятор подключен не по кабелю, а по Wi-Fi

Мой предыдущий селфтест, судя по всему, был уничтожен, когда открытую мною отдельную тему перенесли сюда. Прикладываю еще один селфтест сообщением ниже

4.0.2 проблема по прежнему не исправлена! В списке ЗАРЕГИСТРИРОВАННЫХ устройств по прежнему наблюдается ретранслятор!

Всем добрый день! После обновления связки Ultra II + Buddy 5 на прошивку 4.0.1 в списке зарегистрированных клиентов появился ретранслятор (контроль доступа к беспроводной сети включен в режиме белого списка). Если его удалить, то доступ к ретранслятору пропадает. Возможно, но не уверен, что в 4.0.0 было тоже самое (по крайней мере в конфиге от 4.0.0 запись Buddy-V присутствует, а в конфиге от 3.9 ее точно нет)

А тут, например, https://support.purevpn.com/android-openvpn-manual-configuration смотрели? В этой статье есть линк на скачивание конфигов OpenVPN (архив приложен к сообщению). Но я бы рекомендовал Вам использовать IPsec соединение, там шифрование ускоряется аппаратно и никаких конфигов не надо. Что-то вроде такого: Recommended-CA2.zip

Был уже раньше такой вопрос, в этой теме https://forum.keenetic.net/topic/9108-35-количество-соединений-vpn/ и был такой ответ:

Решение проблемы в моем случае оказалось таким: после ручной установки времени жизни ключей через interface IKE0 ipsec proposal lifetime меньше, чем фактически используемый сервером интервал, клиентом инициируется процедура rekey и она проходит штатно, без разрывов соединения такого рода, как описаны в шапке. Кто был виновником проблемы - клиент или сервер, установить не удалось. Единственный баг, который очень хотелось бы, чтобы пофиксили разработчики ( @Le ecureuil, это возможно?) - сбрасывается время соединения, хотя фактически оно не разрывалось, а происходил rekey по инициативе клиента (при прохождении процедуры rekey по инициативе сервера время не сбрасывается, все работает штатно).

Возможно, имеется в виду, что Keenetic по умолчанию не раздает по DHCP опцию 42, а указанные устройства своих настроек на NTP сервера не имеют или они не настроены? Тогда в CLI надо подать команду вроде ip dhcp pool _WEBADMIN option 42 time.google.com system configuration save Имя нужного DHCP пула можно посмотреть командой show ip dhcp pool

Недавно пришлось перейти к другому VPN провайдеру, потому что старый перестал поддерживать L2TP/IPSec и PPTP соединения, у нового наблюдаю такую ситуацию: устанавливается соединение, например в 01:34, проходит какое-то количество времени, успешно проходит rekey в 04:25, а в 07:16, когда казалось бы должен произойти второй rekey, вместо него вижу в логе: [I] Nov 15 07:16:38 ipsec: 08[IKE] integrity check failed [I] Nov 15 07:16:38 ipsec: 08[IKE] CREATE_CHILD_SA request with message ID 0 processing failed [E] Nov 15 07:16:38 ndm: IpSec::Configurator: IKE message parsing error for crypto map "IKE0". [W] Nov 15 07:16:38 ndm: IpSec::Configurator: (possibly because of wrong pre-shared key). [I] Nov 15 07:16:38 ndm: IpSec::CryptoMapInfo: "IKE0": crypto map active IKE SA: 0, active CHILD SA: 0. [W] Nov 15 07:16:38 ndm: IpSec::Configurator: fallback peer is not defined for crypto map "IKE0", retry. [I] Nov 15 07:16:38 ndm: IpSec::Configurator: "IKE0": schedule reconnect for crypto map. [I] Nov 15 07:16:38 ndm: IpSec::Interface::Ike: "IKE0": IPsec layer is down, shutdown. И соединение разрывается. Полный кусок лога приведен ниже: Селфтест с этими событиями приложен сообщением ниже. Это можно как-то починить с моей стороны? Роутер Ultra II, прошивка 3.5.2. PS Есть заявка в техподдержке 517114

Писали же уже про это не один раз. Функция мастер браузера на роутере нужна из-за того, что это - самое редко отключаемое устройство, кому, как не ему вести список NetBIOS устройств домашней сети, где, как правило, отсутствуют круглосуточно работающие сервера. Типичная проблема в домашней сети - после выключения компьютера, который был мастером, список устройств в локальной сети еще достаточно долгое время выводится либо непозволительно долго, либо не выводится вообще. Да, конечно, NetBIOS и все, что с ним связано - вещь устаревшая, но во вкладке "сеть" используется, и без стабильно работающего master browser'а часто глючит. Проблема с Windows 10 - совсем другая история, к топику отношения не имеющая.

Уважаемый @ndm, боюсь, что Вы поняли неправильно. Нужна именно функция Master Browser'а. В сетевом окружении роутер и так прекрасно видится по имени, есть же настройка соответствующая в #usb.cifs. 2.09.C.0.0-5:

То есть сейчас PEM уже поддерживается? Какой для него нужно ставить тег, <pem></pem>? auth-user-pass, как я понял, пока не поддерживается?

Хотелось бы, чтобы клиент поддерживал вариант конфига с CA и X509 PEM, конечно же в виде файлов. Спасибо.

Жаль От нагрузки, по моим наблюдениям, не зависит, к тому же через этот интерфейс работает transmission, долгий простой исключен. Если включить debug на этом интерфейсе, это может как-то прояснить картину?

Только сейчас заметил то, на что, похоже, никто не обратил внимание в теме Периодически отваливается L2TP/IPSec соединение - при использовании L2TP/IPSec соединения отваливается только L2TP без пересогласования IPSec. Поэтому скромно спрошу у уважаемых администраторов, программистов и @Le ecureuil персонально - не появилось ли у Вас новых идей, почему такое может быть? Полный селфтест, как обычно, в следующем сообщении. PS Более того, VPN провайдер, похоже, не считает это событие разрывом соединения, потому что, например, сохраняется port-forwarding, запрошенный в начале соединения.

В клиентском. Серверный точно не померить, но видно, что нагрузка больше. Но топикстартер говорил, кажется именно о клиентском соединении? Кстати, вопрос, почему шифрование клиентского PPTP соединения явно ускоряется аппаратно, а серверного - нет, может @Le ecureuil знает что-нибудь по этому поводу?

Неправда Ваша, у меня на Ultra II при соединении по PPTP со 128битным шифрованием MPPE выдает порядка 80-90 МБит/c при загрузке процессора около 30%.

Это не баг, Le ecureuil уже писал по этому поводу тут. Другое дело, что значение, на которое меняется MTU, отсюда не узнать, т.к. во всех vanilla-like версиях, к которым относится и прошивка наших роутеров, в выводе этого сообщения используется неправильная переменная, я про это уже писал.

Понятно, неудивительно, что этот баг плавает с 2005 года и периодически выныривает Смотрите, в данном куске кода сравниваются значения osize и isize+MPPE_OVHD+2. В случае, если первое меньше второго, то пакет дропается и выводится то самое отладочное сообщение, что osize (практически это MTU) слишком мало и оно должно быть не меньше чем osize+MPPE_OVHD+2, хотя по логике вещей должно выводиться сообщение, что osize должно быть не меньше чем isize+MPPE_OVHD+2. В первом случае сообщение бесполезно и является неинформативным, более того, в интернете полно пользователей и советчиков, которые увидев это сообщение увеличивают MTU на 4 и удивляются, почему сообщение продолжает возникать вновь, но со значениями, увеличенными на 4. Во втором случае сообщение весьма информативно и пользователь может из него сделать выводы в виде изменения начального значения MTU на основании реальных данных. А вы говорите, про новые алгоритмы, которые не реализовывают якобы из-за каких-то высших соображений, а такой банальный баг копипастят уже более 10 лет. PS Кстати, можете считать это сообщение багрепортом.

А я не про то, что такое сообщение выводилось, хотя оно, конечно, раздражало, а про то, что оно выводилось неправильно. Как Вы там говорили, "Talk's cheap, show us the code!"? Их есть у меня: https://github.com/torvalds/linux/blob/master/drivers/net/ppp/ppp_mppe.c#L384 https://github.com/ndmsystems/linux-3.4/blob/master/drivers/net/ppp/ppp_mppe.c#L383 И т.д. Ничего странного не замечаете?

Это не показатель. Например, баг в модуле PPTP "mppe_compress[0]: osize too small! (have: 1404 need: 1408)" существует как минимум с 2005 года, а периодически он прорывается до сих пор (у вас это тоже было, кстати, совсем недавно ).

Понятно. А как же RFC4821? Там как раз описывается вариант PMTUD с увеличением MSS.

Я эту статью привел просто в качестве примера того, что не всегда увеличение MSS приводит к увеличению скорости инкапсулированного соединения (интересно было бы посчитать с учетом всех заголовков, а какой MSS действительно будет оптимальным), а уж про увеличение MTU при активном PMTUD я и не говорю даже. Кстати, после изучения цисковского описания PMTUD у меня сложилось впечатление, что он может только уменьшать MSS при попытке TCP соединения, а увеличение как-то не предусмотрено. Я что-то недопонял или тут алгоритм более гибкий?

Я это понимаю так: тут дело не в размере MTU, допустимом у конкретного VPN провайдера, а в том, что при соединении с некоторыми сайтами алгоритм автоматического регулирования MSS по каким-то причинам работает криво (например, админы запретили ICMP пакеты на каком-то промежуточном узле и не приходит ответ fragmentation needed), если изначально установлено слишком большое значение MTU. И именно поэтому я предлагаю изменить дефолтное значение MTU при создании соединения L2TP/IPSec, чтобы алгоритм автоматического изменения MSS работал более корректно. PS Кстати, по поводу MSS на L2TP/IPSec соединении. Прочитал тут один занятный документ, называется "IPSec Bandwidth Overhead Using AES". Там расчитывается полный overhead для разных MSS и показывается, что максимизация MSS вовсе не ускоряет скорость инкапсулированного соединения, а оптимальное значение равно 1328.