Алексей Черемисин

book.itep.ru/4/41/802_412.htm читать

Rtsp - протокол управления потоками, а сами потоки могут идти по t cp, rtp, udp, igmp. Если транспортный протокол tcp, то пробросить можно через прокси. Во всех остальных случаях нужна конвертация и rtsp- прокси.

А лучше не zabbix, а prometheus или victoriametrix. И node-exporter на хостах.
Графики и алерты в grafana.

Теоретически может, практически - нафиг ему это не нужно.
По хорошему - что Вы хотите от роутера начального уровня (keenetic start KN-1111? )? Дай бог, он бы себя переварил, не то что поток в 100 мегабит. А если подулючение по PPPoE или L2TP, то и того меньше.
Не даром на нем только 100-мегабитные порты.

Испытать роутер можно - подключите два компа с одной и другой стороны роутера и утилитой iperf проверьте в двухстороннем режиме скорость.

Добавить OSD на ноды, и добавить ноды, если не хватсет.

Поставьте комп посередине с двумя сетевыми карточками.
Сделайте из этих карточек бридж.
На на виртуальном бридже запустите tcpdump или wireshark (что одно и тоже).

Для пущей убедительности возьмите утилиту netcat (nc) и просто погоняйте трафик на каком нибудь порту в режиме echo.
Посмотрите что приходит в tcpdump.

0) Чем и как измеряли? Надеюсь не SpeedTest, а что-то наподобие iperf с двух концов роутера?!
1) Девайс не особенно мощный, но со своими задачами роутинга почти справляется.
2) Чем больше правил, тем ниже скорость.
3) Девайс сильно просаживается на VPN.
4) Так как Сиськи Системз официально запрещают публиковать писькомерки своих девайсов, конечно же без их согласия (а оного хрен получишь), то придется верить на слово, скорость просто роутинга будет в пределах 70% от гигабита. Далее, каждое правило на 3-5% будет снижать скорость и повышать загрузку CPU, но все зависит от настроек...

Ну и девайс ну очень уж старый, рекомендую посмотреть на альтернативы...

Ну, вместо микротика, я обычно ставлю компухтер с intel atom, парой-тройкой сетевых карт и линуксом. По деньгам - одно и тоже.
Очень часто такое решение намного гибче, чем роутер.
Например на нем можно держать и прокси и пару-тройку контейнеров.
А если вместо атома воткнуть что-то с поддержкой VT-x, то можно и несколько виртуалочек развернуть дополнительно.

Настроить фаерволл на комп 1.

Если свитч (коммутатор), всотроен в шлюз (роутер), то проблемы никакой нет.
Практически все девайсы (устройства) для рынка SOHO (для малых предприятий) так и устроены.
Другими словами, в каждый небольшой роутер обычно встроен коммутатор.
Но не наобот - практически никогда во коммутатор не встраивают роутер.

Так что свич обычно не может выступать шлюзом!

Но из каждого правила есть исключения - в промышленные, дорогие и управляемые коммутаторы обычно встраивают ПО для обеспечения элементов роутинга :) И тогда коммутатор может быть и частично роутером.

1) не делать свой почтовый сервер
2) хорошо подумать, и не делать свой почтовый сервер
3) если все равно хочется сделать, но еще раз подумать, и не делать почтовый сервер.
Ну и нужно настроить:
- записи MX, SPF, DKIM
- настроить подписи DKIM
- установить SMTP-вервер (opensmtpd например),
- установить POP и/или IMAP серверы
- настроить TLS на всем этом с сертификатами
- очень желательно настроить антиспам типа spamassist
А также по просьбе старого друга и авторитетного администратора крупных почтовых (и не только) сервисов Alexey Dmitriev

Просьба добавить в свой правильный список - настройку записи DMARC и PTR - для полноты картины.

Без этого тоже никуда никто не едет.
И еще раз крепко подумать, нужна ли Вам эта головная боль и разбирательства, "почему меня все блокируют"...
Один из выходов, хостить почту у провайдеров почты, а себе забирать архивы раз в день...

PS, И да, если уж речь зашла о настройках, Всякие PTR, SPF, MX, DKIM, DMARC и прочие вещи я не всегда знаю сам как автоматизировать. В основном ручками все собираю по привычке и правлю конфиги. А в больших инсталляциях еще и разношу на несколько серверов.
И все равно, почта требует практически еженедельного (если не ежедневного, в больших инсталляциях) присмотра и ухода, чистки очередей, разгрузки сервисов, борьбы со спамом и прочей хренью.

PPS. Лет 25 назад доставляло мне удовольствие, забирать отдавать почту по UUCP по модемному коннекту на организацию в 100 человек :)
Теперь нет никакого удовольствия. Это все равно что содержать ftp-сервер. Старый протокол, старые технологии, куча говна и палок.

Ну и коли пошла такая пьянка, некоторые корпоративные почтовики оборудуют всякими фильтрами:
- первое письмо не проходит, и его нужно ставить в отдельную очередь на минут 20-30 для повторного ответа - не выдержал таймаут - БАН
- первое письмо просто валится в спам - повторная отправка - БАН
- нельзя отправлять почту более 10 ресипиентам - БАН
- пигн-понг короткими сообщениями - иначе БАН

Ну и прочие чудеса эквилибристики почтовых администраторов.

Все просто
1) На каждый офис по маршрутизатору. (Я бы брал программный на линуксе. Просто комп или сервер с нужным количеством интерфейсов, с с установленным линуксом. Но это я)
2) В каждом офисе своя выделенная и замаскараденная сеть - другими словами, никто никуда не ходит, только интернет.
3) Каждый офис наводит VPN/VLAN/VxLAN с центральным, и по необходимости с нужными соседями
4) На маршрутизаторах разрешаем, какие ресурсы будут доступны внутри центра и филиалов
5) Все доступные ресурсы убираем в зоны DMZ

Во первых, подозреваю, что никому не нужно ходить из офисов непосредственно на компы.
Во вторых, извне все должно быть прикрыто, даже от офиса, ибо нефиг по компам шастать.
В третьих, общие ресурсы тоже не должны быть совместно с компами, ибо иногда их ломают...
В четвертых, тут много всякого, от броадкаста, до dhcp, авторизации и разделения...

Ах, да, есть коммутаторы L3, которые могут не только VLAN, но и VxLAN, и MPLS, и маршрутизацию.
Такие ставьте в центр сети, и рулите маршрутами, доступом и прочим...

Посмотрите на wstunnel - https://github.com/erebe/wstunnel
Но наверное нужно будет что-то доработать.
Или вот еще, но опять же нужно доработать наверное https://www.section.io/engineering-education/ssh-i...
А вот вообще законченный вариант! https://github.com/elisescu/tty-share

У TCP есть не только IP-адрес, но ещё и порт. Как со стороны сервера, так и со стороны клиента. Если со стороны сервера порт обычно задан статически (например 80), то со стороны клиента он выбирается динамически из не занятых. В результате, каждый клиент получает свою уникальную пару IP-порт, по которым сервер и отправляет пакеты клиентскому сокету. Тем самым мы можем иметь кучу клиентских соединений на одном компьютере, различающиеся разными клиентскими портами на каждое соединение к одному серверу.

Проблема в dhcp. Вариантов два, либо маленький пул и разные адреса постоянно раздаются на разные устройства, либо второй dhcp в сети.
В результате у вас иногда возникает конфликт адресов.

Опять же, в линуксе, можно:
- изменить мак-адрес карты
- дополнительно привязать к карте еще один мак
- создать бридж и к нему привязать кучу виртуальных портов со своими мак-адресами.