Евгений

Любой "Wi-Fi репитер" такое сумеет, не обятательно той же модели или вендора.
Проверено на самых дешевых китайских.

При использовании в качестве технических терминов слова "маршрутизатор" и "роутер" - это абсолютные синонимы. Безальтернативно.

То, что ты описываешь - слэнговое понимание этих слов. Для потрындеть на завалинке. Для бложика сойдёт, наверное, если там никто вообще не в теме. Но у технического специалиста ощущение от такого текста однозначное - очередной ламер решил просветить других ламеров по теме, в которой и сам мало что понимает. А стиль изложения только усиливает это впечатление.

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

Всё, что написано про "выбор наименее загруженного маршрута" - это какой-то бред. Всё определяется тем, какие именно возможности заложены в программное обеспечение либо прошивку маршрутизатора, какие протоколы поддерживаются.

Термин "шлюз" применительно к сетям имеет два значения. Программно - это адрес, через который отправляются пакеты информации для достижения узлов, которые не достижимы непосредственно. Аппаратно - это пограничное устройство между двумя сегментами сети, которое как минимум маршрутизирует, но как правило ещё и дополнительно обрабатывает (чаще всего - фильтрует и/или шифрует) передаваемый трафик. Ну то есть это по сути маршрутизатор, как правило обременённый дополнительными (чаще всего - защитными) функциями.

у вас правило в таблице nat, а проверяете в таблице filter.
нужно указать таблицу аналогично первой команде
iptables -t nat -C ...

Ну вот смотрите. Есть объект на порядка 100 камер, можно считать что на вас похоже.

1. Сервер видеонаблюдения: 24 отсека на 3,5", занято половина. интерфейсы как медные 1Гб, так и оптика 10Гб. 2 процессора Xeon Silver 4208 @ 2.10GHz. Чтобы принимать и класть потоки и отдавать видео без компрессии клиентам - более чем. По заббиксу загрузка процессоров выглядит как-то так:



2. Диски. Состояние массива сейчас примерно следующее:

/dev/sdc         13T  2.6T   11T  20% /mnt/cctv14tb02
/dev/sdb         13T  2.6T   11T  20% /mnt/cctv14tb01
/dev/sdj         13T  2.6T   11T  20% /mnt/cctv14tb09
/dev/sdm         13T  2.6T   11T  20% /mnt/cctv14tb12
/dev/sde         13T  2.6T   11T  20% /mnt/cctv14tb04
/dev/sdf         13T  2.6T   11T  20% /mnt/cctv14tb05
/dev/sdk         13T  2.6T   11T  20% /mnt/cctv14tb10
/dev/sdd         13T  2.6T   11T  20% /mnt/cctv14tb03
/dev/sdl         13T  2.6T   11T  20% /mnt/cctv14tb11
/dev/sdh         13T  2.6T   11T  20% /mnt/cctv14tb07
/dev/sdi         13T  2.6T   11T  20% /mnt/cctv14tb08
/dev/sdn         15T  4.4T   11T  30% /mnt/cctv16tb01

Естественно, никаких рейдов. Убьёте весь массив если начнёте восстанавливать. Просто следить за СМАРТом и менять при подозрениях. Софт, что мы используем умеет автоматом размазывать по имеющимся дискам

Хочется SSD под систему, ставьте. Не хочется, не ставьте

3. Сеть. Сеть сегментировать. Вам же не хочется чтобы юзеры были в той же сети что и камеры. Трафик на этих 100 камерах примерно вот такой:



Казалось бы немного. Но зато стабильно. У нас в выделенном влане с бэкбоном в 10Гбит о пропускной способности ещё долго не придётся задумываться

4. Что касается софта - когда изучали вопрос, тестировали всякие опенсорсные. Близко не в состоянии. Остановились на коммерческом. Будет интересно, в личке скажу. Тут полный фарш. Отсутствие лицензий на пользователей, только на камеры и функциональность. Рабочих мест может быть сколько угодно. При этом по разным причинам у нас разные пользователи в разных вланах и камеры тоже. Управлять этим совсем не сложно. Умеет размазывать архив по разным дискам, регулярные обновления. Всякое ИИшное

5. Кстати, об ИИ. Не забудьте предусмотреть в сервер подходящую видеокарту, если захочется например лиц или номеров, никуда не деться.

Потому что за 10 лет домен сменил владельца и на данный момент им владеет кто-то нехороший

Если задача всплывает часто, освой Midnight Commander или иной двухпанельный файловый менеджер. Он запускается в терминальном режиме и прекрасно подходит для таких ситуаций.

в целом мысль верная.
в конфиге опенВПН сервера ставится dhcp, он так уже есть "внутри", ничего сверх ненужно
отключи(не включай) masquerade на интерфейсе WAN на сервере - и клиенты в инет не выйдут, тут придумывать тоже особо нечего

но при таких настройках у тебя на клиентах сломается инет - чтобы этого не произошло НЕ ставь в конфиге сервера и клиентах настройку "шлюз по умолчанию"
Так же сделай просто пуш нужной подсети в впн - push-route

тогда только эта подсеть пойдет в впн, а остальное будет работать как обычно.

Ну и еще момент - в РФ опенВПН может запросто блочиться, учитывай это. Лично я перешёл на p2p сети, ну либо SSTP на крайняк \ CiscoAnyConnec(ocserv для убунты)

При настройке OpenVPN клиента в правила iptables нужно разрешить трафик, который уже инициирован вами или вашими приложениями. Порт менять не нужно.

# Разрешить входящий трафик для установленных/связанных соединений
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Разрешить исходящий трафик для установленных/связанных соединений
sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT