AUser0

Вообще-то для WEB-интерфейса Zabbix необходима установка пакета zabbix-web и PHP (в какой-либо форме).

Если от провайдера заходит кабель с восьмью жилами, а у вас физическое подключение до 100Mbit - то можно по четырём неиспользуемым жилам организовать второе подключение к роутеру. Как это скажется на скоростях - не знаю, нет опыта.

Второй вариант - адаптеры PowerLine, передающие сетевой сигнал по проводам 220 Вольт. Как это выразится в скоростях - тоже не подскажу, знаю только о возможности.

Мало настроить проброс трафика, надо ещё объяснить вашему HTTP-серверу, что https://176.16.16.25/ - это он и есть, и должен обслуживать это доменное имя (да, IP-адрес тоже является доменным именем). В зависимости от программы HTTP-сервера рекомендации будут разные.

! -dport 22 Или ACCEPT порта 22 перед DNAT.

Делаете в таблице ACCEPT/REJECT для каждого исключённого адреса. А после прохода таблицы уже DNAT.

70-C9-4E-54-03-2F, Загляните в Tools -> Packet Sniffer. Впишите туда "UDP" и 67-ой порт, и смотрите, какие пакеты откуда-куда приходят-уходят. Если правила работают - то будет логирован только приход пакетов на физический интерфейс, но не ответы на них... Поможет найти "мокрый пол".

P.S. Ну и логирование работы DHCP Server, тоже полезно видеть.

P.P.S. DHCP рассылаются броадкастом, может на них отвечает кто-то другой?

Если имеется ввиду входящий трафик - легко, REJECT-ите/DROP-аете любой трафик на этот IP, пришедший с неправильного интерфейса - и вуаля! Хотя это в принципе уже должен делать провайдер(ы).

Для исходящего трафика есть routing, поэтому делаете SNAT - тоже будет работать.

Default Gateway нужен в случае, когда устройство хочет, но не знает куда/кому нужно передать пакет, что бы он дошёл до пункта назначения. Тобишь когда устройство идёт в глобальный огромный Интернет.

У вас же сеть - локальная, и она прописана в routing tables. Default Gateway не используется, потому что сеть - локальная, а устройство отвечает на коннекты к нему.

Если к розетке подключены провода - то она расшита.
Ну а найти расшитую розетку можно по кабелю, подключенному к ней.

Как правило на задней стороне патч-панели расположение каждой розетки подписано.
Либо просто - самая левая розетка находится у правого края на обратной стороне патч-панели.

Во-первых,

потребность в ещё одном сервисе, который также должен иметь доступ по домену

доступ должен быть снаружи во внутрь, или наоборот?

Во-вторых, если снаружи во внутрь - какой именно сервис имеется ввиду? Стандарт HTTP вполне допускает любое кол-во доменов на одном IP, SMTP тоже. Или нужно что-то другое?

В-третьих, для выхода наружу доменное имя на вашем белом IP нужно постольку-поскольку. Ну, для почты, для проверки на спам нужны домен и IP reverse lookup, да. А так - всё, остальное может без доменного имени работать.

Таким --state NEW -j ACCEPT вы разрешили новые коннекты на любые порты с любых IP-адресов через любой интерфейс.
И все правила, идущие уже после этого ACCEPT - вообще не сработают, до них обработка не дойдёт, потом что это правило уже всем всё разрешило...
И да, это полный аналог дефаултного правила INPUT[ACCEPT]. Поэтому так ни кто не пишет, в такое правило обязательно добавляют разные аргументы, типа через какой интерфейс, на какой порт, и с каких IP, и т.д.

Вам нужен pac-файл:

if (shExpMatch(url, "*abcdomain.com/some_folder/*"))
return "PROXY 127.0.0.1:3128";
else return "DIRECT";

но работу с pac поддерживают только браузеры с их встроенными JavaScript-ами.

На сколько я понял, достаточно приколотить на задействованный интерфейс на сервере локальный IP. А в маршрутизаторе отключить firewall, поскольку у вас на wan только сервер, который сам является firewall-ом для трафика из модемного Интернета. Или переключить wan-порт в режим lan.

Ну что фаервол мешает - вы уже и сами поняли, осталось добавить разрешающее правило для 80 и 443 портов на IP этого Комп1. Что hosts необходимо настраивать на каждом компьютере - тоже догадались. И обращаться надо к странице vhost1/index.html, vhost2/index.php (если такой файл там есть), и т.д. Файла vhost3.php на хосте vhost3 нет - вот и получили "404 Не найдено", всё правильно.

А вот обращение к виртуальным сайтам по IP или по IP/имя_сайта/ - не получится. И тот, и другой случай невозможны. Ну то есть второй случай можно сделать конфигурированием, но большого смысла в этом нет, только набить опыт в нестандартной конфигурации.

Вот представьте, DDoS - это час пик в Москве. А вы турникетами перегородили въезд на придомовую территорию. И теперь искренне надеетесь, что благодаря придомовым турникетам МКАД перестанет пробками забиваться. Аналогия понятна?

P.S. Даже если вы выдернете провод из сервера - DDoS трафик не исчезнет, он просто перестанет доходить до конечного устройства, будет подвисать на стадии инициализации коннекта. Cloudflare вам в помощь.

Нужны двойные кавычки вокруг ключа: "/RETAIL-1C/SQLData(D:): Space utilization"

Создаёте необходимое кол-во интерфейсов внутри этой виртуальк, и прибиваете к ним провайдерские IP. К vmbr0 ProxMox-а они сами присоединятся. Вот и всё.

Смотреть командой netstat, она выведет все текущие соединения. Там и найдёте этот IP. Если сидите на Windows, то netstat -o (на Unix-like: netstat -p), с выводом PID того процесса, который соединение открыл. Найдёте нужный PID нужного соединения в диспетчере задач - вот и узнаете имя программы...