Le ecureuil

NAS подключается как NFS, CIFS, или еще как-нибудь?

Эти разделы никак не связаны между собой кроме того факта, что если на устройстве нет 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 пока реализован на зачаточном уровне. Планируется улучшение ситуации.