Максим Гришин

Похоже заббикс такого не умеет, для графаны есть вот такой вопрос на SO: https://stackoverflow.com/questions/77682714/last-... возможно его решение вам подойдет.

Frame challenge: а нафига они нужны? Надо L3 - бери роутер, не надо L3 - бери L2-свитч, строй на нем вланы, подключай роутер извне если надо, и на роутере управляй доступом, а свитч останется пакеты гонять, без лишнего функционала. ИМХО L3-свитч это "недо-роутер", зато с кучей портов, и нужен тем, кто не может поднять виртуалку хоть с routerOS хоть с линуксом, и делегировать роутинг на неё.

Выставь мускул слушать на 10.0.0.1, должно хватить.

systemctl list-units|grep ssdp
Судя по тому, что отправляется NOTIFY, ваша система сообщает всем кто слышит о том, что у неё есть что-то из функционала. Нужно найти в системе SSDP-демон и отключить.

L2 VPN объединяет локальную и удаленную сети в один L2 сегмент, а L3 VPN требует маршрутизации для обмена данными между сетями. Неприменимо, если к VPN подключается конкретно хост, а не сразу подсеть.

Похоже, в Zabbix 5.4 появился новый синтаксис для агрегированных вычислений https://www.zabbix.com/documentation/current/en/ma... и для вычисления вашего "среднего CPU на SNMP" нужно написать обычный item, типа calculated, с формулой из примера №2 по ссылке, только вместо sum поставить avg. Т.е. формула должна быть вроде вот такой:

avg(last_foreach(/host/hrProcessorLoad[*]))

DameWare NT Utilities ЕМНИП на такое была способна. В сущности, нужно добавить проверку на наличие элементов реестра, характерных для развернутого ПО, и по ним отслеживать, есть ПО или нет. В любом случае, для такой инвентаризации ПК должен быть включен и доступен по сети, а для нормальной инвентаризации всё равно придется телепать по кабинетам и лазать под столы, особенно если на ПК есть какой-нибудь инвентарный номер, нарисованный маркером по корпусу.

Добро пожаловать в чебурнет. Это следствие вот этого https://habr.com/ru/news/t/577602/ после чего Ростелеком начал тестировать блокировку 8.8.8.8 и подмену DNS-записей google.com на своей стороне.

На хостовой машине пишете правило forward, разрешающее подключения с 192.168.122.0/24 до 172.16.55.0/24 и 192.168.0.1, а остальное дропаете. Маршруты у вас все уже есть, как я понимаю, так как хост видит всё что надо. Если ВМ за локальным NAT'ом, проверьте, что правило для NAT на эту машину находится в ветке POSTROUTING, если это iptables, в противном случае вы так ещё и хосту интернет обрежете.

Проверьте, не завелся ли у вас в сети левый DHCP-сервер. Помнится, когда у нас какой-то умник поднял DHCP, сеть начала рандомно отваливаться (1000+ ПК, десятка два потеряли сеть), выловили, что они айпи получили от какого-то странного адреса и выпилили его.

Такие штуки по идее должен решать Network Policy Server на микрософте, тем более если у вас Windows AD. Во всяком случае, в руководстве к нему я такое видел, но на практике я не видел, чтобы он где-то был развернут. Вообще в вашем случае я бы назначал диапазон DHCP в .2.0/24 а статику назначал на том же DHCP-сервере по MAC-адресу устройства, но если вдруг устройство окажется с настроенной статикой .1.0/24, можете поиметь проблем.

Скорее всего вы упускаете настройку порта, которым свитч соединен с интерфейсом роутера eth1.20. Если там внезапно tagged vlan 20 (а может и 50 на нем же), а на портах, которыми остальные свитчи подключены, access vlan 20 (т.е. порт без поддержки vlan), остальные свитчи знать о vlan 20 не будут, для них вся сеть будет vlan0.
Вообще, настройка vlan желательна сквозной, чтобы не поймать случайную петлю в бэкбоне или не соединить на L1 сети, должные быть развязанными, имхо админ, настраивавший это, поленился сделать одинаковые вланы везде, и настроил отображение default vlan остальных свитчей в vlan 20 на том, где вланы таки настроены.

Ставить вместо клиентской ОС серверную. С клиентской ОС такой трюк не пройдет, если не нарушать лицензии.

Не выйдет - тот айпи, который вы видите через 2ip.ru и т.п., выдан роутеру (даже не столько ему, сколько динамически провайдером на все подключения с порта в оборудовании провайдера, куда воткнут роутер). Чтобы айпи были разные, вам нужно поднять на одном из ПК VPN-сессию куда-то ещё, и через неё пытаться выходить в Интернет.

Проверьте порт свитча, в который воткнут адаптер #3 сервера Hyper-V. Ваша конфигурация сети показывает, что все пакеты, отправляемые в адаптер, идут с tagged vlan 5, порт должен принимать на своей стороне tagged vlan 5, чтобы пакеты попали в пятый влан. Скорее всего, порт на свитче стоит в режиме access vlan 5, в этом случае со стороны сервера VLAN tag указывать не нужно (указать vlan id 0). Иначе конфигурировать порт в trunk и разрешать принимать на нем tagged vlan 5.

В рамках телепатии - маршрут из 172.16 сети в сторону 10.10 сети проходит через NAT, из-за чего 10.10 сеть о 172.16 просто ничего не знает.
PS: почему подсеть 172.16.3.0 с шестнадцатой маской, когда должна быть с 24й? Опечатка?

Нужно смотреть логи клиента вначале. Может, отъезжает синхронизация времени, может, разрешение имен по DNS/WINS, может, просто сетевая глючит, попробуйте поменять.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule (попробованы значения 2 и 0) - оставить в 2, в любом случае клиент за натом, и если вдруг сервер тоже за натом, то без двух здесь не заведется в принципе.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\ProhibitIpSec (опробовано 0 и 1) - оставить в 0, без шифрования глухо, а в IPsec оно как раз хорошее - MPPE в L2TP мягко скажем слабое по сегодняшним стандартам.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\AllowL2TPWeakCrypto (опробовано 0 и 1) - должно быть нерелевантно, но зависит от настроек сервера.
Windows Firewall полностью отключать и добавлять правила для UDP 500, 1701, 4500 - нерелевантно, со стороны клиента соединение исходящее, политика по умолчанию разрешает их.

Дальше - запустить VPN на том ПК с семеркой, который подключается, потом поднять сниффер на роутере и собирать обмен пакетами между вторым компом и сервером. Есть подозрение, что роутер некорректно реализует обработку NAT-T для L2TP и транслирует пакеты от второго клиента тоже в порт 4500, или выбивая его, или просто направляя ответ для второго клиента первому, возможно, имеет смысл отключить на нем отдельную обработку L2TP/IPsec passthrough и проверить работу всех клиентов.