Коротко: есть два надёжных подхода — взять готовый firewall-дистрибутив (pfSense / OPNsense) и запустить его как «пограничный» VM/машину с прямым доступом к NIC’ам, либо поставить Linux (Debian/Ubuntu) и собрать маршрутизатор/файрвол самому (nftables + dhcpd + ipset + squid/tc). Для «строгого» контроля важна правильная сетап-архитектура (firewall между LAN и WAN, хост не должен «обходить» его), а также метод аутентификации/идентификации устройств (MAC/IP статика, DHCP static-mapping, captive‑portal или прокси с MITM при HTTPS).
Ниже — рекомендованный план и практические шаги.
1) Архитектура и принцип
- Физически: Eth2 — LAN, Eth1 — WAN. Всё устройство LAN должно идти через сервер/VM, который является шлюзом. Нельзя, чтобы хост/виртуалка делала NAT/мост так, что пакеты обходит firewall.
- Варианты VM-сетей: лучше всего либо:
- PCI-passthrough отдельных NIC в firewall-VM (лучше всего), либо
- на хосте создать два бриджа (br-wan, br-lan) и подключить VM NIC’ы к этим бриджам (и не давать хосту IP на них).
- Firewall решает: «выпустить/заблокировать» на основании MAC/IP/пользовательской аутентификации/политик.
2) Что выбрать (рекомендации)
- Если вы хотите GUI, готовые функции (captive portal, DHCP, proxy, пакеты блокировки, IDS/IPS): pfSense или OPNsense.
- Простая админка, много пакетов (Squid, pfBlockerNG, ntopng, Suricata).
- Если вы предпочитаете гибкость и умеете в Linux: Debian/Ubuntu + nftables + isc-dhcp-server/dnsmasq + ipset + Squid (ssl_bump) + tc (shaping).
- Более тонкая настройка, скрипты автоматизации, низкий оверхед.
- Для домашней/малого офиса обычно pfSense/OPNsense быстрее довести до рабочего состояния.
3) Как настраивать (pfSense/OPNsense — быстрый план)
- Установите pfSense/OPNsense на отдельную VM/хост. Используйте PCI passthrough или bridged NIC’ы так, чтобы WAN и LAN физически шли через VM.
- Назначьте интерфейсы: WAN = Eth1, LAN = Eth2.
- Включите DHCP на LAN (или назначьте статические IP через DHCP static mappings по MAC).
- Правила firewall: «по умолчанию DENY» (запретить forward), затем разрешающие правила для конкретных IP/alias’ов.
- Создайте alias’ы: список разрешённых устройств, список заблокированных, группы портов и т. д.
- Captive Portal (если нужно, чтобы пользователь «включался» вручную): включите captive portal (можно vouch/voucher, RADIUS или локальную авторизацию).
- Прокси/фильтрация: установите Squid (и SquidGuard или pfBlockerNG) для URL-фильтрации. Для HTTPS — Squid с SSL Bump (потребует установки CA на клиентских устройствах).
- Логирование и отчёты: установить ntopng, SARG или использовать встроенные графики и пакеты pfSense.
4) Как настраивать (Linux + nftables — быстрый план)
- Установка: чистый Debian/Ubuntu.
- Включите роутинг: sysctl net.ipv4.ip_forward=1 (и persist).
- DHCP/DNS: dnsmasq или isc-dhcp-server для выдачи IP и статических связок MAC→IP.
- NAT/masquerade на WAN: nftables/iptables правило POSTROUTING masquerade.
- Базовый nftables (пример логики):
- policy forward drop;
- allow related,established;
- allow forward from @allowed_ips to any;
- drop all other forward.
- @allowed_ips — ipset, который пополняется статикой из DHCP или API.
- Управление устройствами: поддерживайте список разрешённых MAC/IP (ipset или база), скрипт, который на добавление статической записи в DHCP ещё добавляет IP в ipset.
- Прозрачный прокси: Squid + redirect (iptables/nft REDIRECT) для HTTP; для HTTPS — ssl_bump (требует CA на клиентах) или captive portal.
- Captive portal на Linux: coova-chilli + freeradius или nodogsplash (простой).
5) Важные моменты по HTTPS и «строгому» контролю
- Без установки CA на клиентах вы не сможете «просмотреть» HTTPS-пакеты для фильтрации по URL. Можете ограничиться:
- блокировкой по IP/портам/портам SNI (ограниченно), или
- использовать captive portal/explicit proxy (который требует настройки клиентов), или
- принудительно перенаправлять весь трафик и сделать MITM (ssl_bump) — требует установки доверенного CA на клиентских машинах.
- Для «жёсткого» непрохода всего, что не разрешено, делайте default DROP/deny и вручную добавляйте разрешения по MAC/IP или по аутентификации в captive portal.
6) Частые ошибки (возможно причина ваших проблем с Kerio/IPFire)
- Виртуализация неправильно настроена: NIC’ы на хосте выполняют NAT/маршрутизацию и позволяют трафику обходить firewall-VM.
- DHCP сервера на нескольких устройствах (модем/роутер + firewall) конфликтуют.
- Правила firewall неправильного порядка — «allow any» в LAN chain раньше специфичных deny.
- Прозрачный прокси без корректной настройки SSL приводит к падению HTTPS.
- NIC’ы не в режиме promiscuous или без passthrough — пакеты не проходят как ожидалось.
7) Пример простой политики «только разрешённые устройства»
- На pfSense: создаёте alias «Allowed_LAN», пишете правило на LAN interface: allow from alias Allowed_LAN to any; потом правило deny from any to any.
- На Linux (nftables/ipset): ipset create allowed hash:ip; nft add rule inet filter forward ip saddr @allowed accept; nft add rule inet filter forward drop.
8) Рекомендация для вашего случая
- Если вы не хотите глубоко ковыряться в Linux — установите pfSense/OPNsense в VM, убедитесь, что NIC’ы переданы VM правильно (passthrough или бриджи), отключите IP на хосте на этих интерфейсах, включите DHCP на pfSense и настройте default deny + alias’ы/сaptive portal.
- Если хотите гибкость/низкий ресурсный оверхед — Debian + nftables + dhcpd + Squid.
Если хотите — помогу конкретно:
- С инструкцией по установке pfSense в вашей виртуалке (скажите гипервизор: Proxmox, KVM/libvirt, VMware, Hyper-V).
- С примером nftables-конфигурации + скриптом синхронизации ipset с DHCP.
- С конфигурацией Squid ssl_bump и способом развёртывания CA и распространения на клиентские устройства.
Напишите: какой гипервизор/серверная ОС сейчас, есть ли возможность PCI passthrough, сколько клиентов и нужно ли фильтровать HTTPS (есть ли возможность ставить CA на устройства).