Le ecureuil

Эти разделы никак не связаны между собой кроме того факта, что если на устройстве нет USB-разъема, то и раздела /storage тоже нет.

Пока на клиенте не сделаете туннель с SL public и ip global > 0 и не пропишете default route на него через ip route - никак.

Никак, такой функционал не закладывался.

Включайте system debug, отключайте openvpn, снимайте self-test и кидайте сюда. Посмотрим, что не так.

А много клиентов умеют задавать порты источника для исходящих содинений? Я что-то не помню, покажите если так. В таком случае конечно можно.

Если подскажете, как дешево (в смысле нагрузки на CPU) отличить каждый TCP/UDP поток торрента от TCP/UDP потока неторрента, то подумаем. Пока у меня идей нет.

Может быть, но пока давайте хотя бы вариант с раскидыванием хостов и встроенных в Keenetic сервисов по нужным политикам доведем до ума. Ну и load-balancing на несколько каналов мне видится тоже приоритетнее.

Там не совсем точная информация, особенно если хосты за рипитером.

С антеннами все проще - они внутри сделаны на печатной плате и с высокой точностью + усилки и выходной тракт специально калибруется в полном сборе с уже припаянными антеннами для максимальных показателей. Потому замена антенны на другую во-первых только ухудшит характеристики тракта, а во-вторых потери в разьеме будут очень сильные - опять падение характеристик. Это все в теории можно побороть, но цена заметно возрастет, сами понимаете. Насчет умирающих усилков - у меня активно используется пара отладочных плат под разрабатываемые устройства - это вообще голые платы, даже без радиаторов и тем более без антенн WiFi. Тем не менее, до сих пор все живы (например Ultra II с 2015 года, пережившая несколько тысяч перепрошивок) - в целом выходной тракт WiFi неплохо защищен от таких издевателств. PoE на Ultra II точно не планируется - это устройство 2014-2015 года разработки, оно уже финализировано и никто железную часть перерабатывать не будет. Если будут еще какие вопросы - пишите, упоминайте меня, постараемся решить что возможно.

Если прошивка свежая (2.11 и выше), то лучше смотреть на вывод show ip hotspot или show ip neighbour. Там более полная и точная информация.

На Кинетике они будут видется с настоящим IP клиента, потому нужно разрешить "ото всех" на эти порты. А мы сейчас про GPON и открытие портов говорим про клиент или про сервер? На клиенте ничего открывать не нужно.

Насчет рогов - насколько я в курсе, то сейчас все WiFi-антенны несьемные, и точно такими будут в ближайшее время. Потому если сильно бесит - отключайте Wifi и отламывайте. Думаю, на ваших объемах можно в какой-то мере забить на гарантию, все равно так или иначе будет текучка. Насчет отключения NAT - есть на это тема: Вам придется отключить глобально NAT и настроить на строго определенные исходящие и входящие интерфейсы, но опять-таки при автоматизации это мелкий и решаемый вопрос. Трафик между остальными будет идти без NAT вообще. Еще можете отключить NAT Loopback, если он мешается:

Здесь идет все обсуждение MultiWAN в NDMS.

я правильно понимаю что с этим обновлением появилась возможность сделать так, чтобы траффик определенных устройств шел через openvpn-подключение? (то есть делаю соединение через openvpn, создаю профиль где указываю его как соединение с интернетом и в привязке задаю устройства?) Да, можно. Давайте создадим новую тему, чтобы не тащить весь груз истории. Дальнейшее обсуждение тут:

Да, нужно открывать порты сервера на WAN + включать проброс на терминале (если он настроен как L3/L4-роутер, а не как L2 bridge).

Да, порты на WAN на сервере обязательно должны быть открыты. У клиента нет. Если вы используете команду "push route" на сервере или "route"/"iroute" на любой из сторон соединения, то нужна - она позволяет передать в систему нужные маршруты, чтобы система их себе установила. В том числе и default route.

Расскажите, что вы хотите видеть (какой именно nat), и мы подумаем. "Без ваших идей не обойтись" (ц), потому что мы не можем предвидеть все желания пользователей. Насчет мануала по RCI - он готовится, доделываем.

Один раз, и все? Это как-то повлияло на работоспособность?

А почему бы вам в официальную техподдержку не обратиться?

Это не очень хорошая команда в плане безопасности, она разрешает свободный проход трафика между всеми private-сегментами. Возможно, в вашем случае нехватало одного-двух правил в МСЭ.

Скидывайте self-test с сервера, постараюсь разобраться что там не так.

1 - нужно настраивать ping и pinr-timer в openvpn. Инструкция там базовая, в ней ничего это не описано. Читаете man по openvpn - и вперед. 2 - потому что PSK меньше 8 символов - это не безопасность вообще, а так, "сикалки". Лучше вообще pptp без шифрования тогда.

2.12 никогда не выйдет на Keenetic 3 в качестве официальной стабильной.

Пока никак, функционал сервера openvpn пока реализован на зачаточном уровне. Планируется улучшение ситуации.

Вполне ожидаемо, облако не резиновое. Оно лишь запасной вариант для тех, кто не может использовать прямой режим.