Хотспотов можно настроить несколько, там же можно создать несколько шаблонов.
На один бридж нельзя настроить несколько ip подсетей...
Только если к примеру с маской /8 делать подсеть на бридже, и далее на хотспоты выводить с маской /24
Qos. Тема обширная с не слишком простая. Начните с теории, на habr есть вполне неплохие статьи на этот счёт. Если не хотите изучать лучше обратитесь к оутсорсерам, тема qos с наскока без понимания процесса не решается.
Даня, да когда ты уже поймешь, что ты нахрен никому не уперся? Статика есть? Разверни bind на своем линухе, и там хоть запрописывайся любых записей! Что за манера искать проблемы где их нет? Потрать ты едрить 150 руб на secondary DNS (а может и бесплатно где есть).
Никаких тяжелых процессов не выполняется. Запущены 3 браузера
Вот тут-то я и охренел.
Тот же Хром запросто может посоревноваться по степени нагружаемости ПК с какой-нибудь топовой игрой 5-7-летней давности, а у вас три (я так понял, разных?).
Это битовые флаги того, что разрешено пробрасывать через RDP соединение. К отпечатку отношения не имеют. Точною документацию искать особого смысла нет, достаточно взять значение из вручную созданного соединения с нравящимися параметрами.
Тут по-моему вообще можно без процессоров, и без контроллеров обойтись. Гуглить пороговый датчик температуры хотя бы. Или термостат. Или термопредохранитель - самовосстанавливающийся или нет.
Смотря что конкретно вам требуется.
И вообще при таком условии:
if TEMP=50 and TEMP>50
then [разорвать цепь]
else [ничего не делать*]
Можно вообще и без всего этого обойтись - все равно работать не будет, поскольку условие невыполнимо
Настроить маршруты, очевидно.
Все запросы на 0.0.0.0 направлять на карточку, которая смотрит наружу (то есть она будет default gateway), локальный трафик на внутреннюю.
Любая проблема, тем более в сети, ищется методом исключения.
Для этого делаете глобальное предположение, и пытаетесь его опровергнуть. Например, дело может быть либо в клиенте, либо в сервере, либо в обоих. Проверили - исключили что-то - дальше сужаете круг поиска. И так до тех пор, пока не попадете точно в причину.
Медитировать на графики и пытаться понять их с помощью телепатии и экстрасенсорных способностей - не надежный путь. Бывает, приходит инсайт. Но лучше не надеяться на удачу, а идти проверенным путём, добывая всё больше и больше информации, помогающей исключать сразу множество вариантов.
Полагаю, что только в случае если на ноутбуке данного пользователя осуществлялся когда-либо вход с учёткой доменного администратора или при наличии явных незакрытых уязвимостей на ваших серверах или ПК, на которых осуществлялся вход с учёткой доменного администратора.
Отсюда вытекает рекомендация - никогда не входить на какие-либо ПК под учёткой администратора домена! В идеале - вовсе не использовать данный тип учётных записей где-либо вне самого сервера DC.