Чем заменить старый ClearOS: пошаговая миграция офисного шлюза
ClearOS был удобен тем, что собирал в одной панели маршрутизацию, NAT, DHCP, DNS, VPN и фильтрацию. Через несколько лет это удобство часто превращается в проблему: система устарела, документации нет, а выключить её страшно, потому что никто точно не знает, какие службы на ней завязаны.
В этой инструкции мы не будем менять ClearOS одним резким движением. Новый шлюз сначала поднимем рядом со старым, проверим его на одном компьютере, перенесём критичные функции и только после этого переключим офис. Такой подход даёт главное преимущество: при ошибке можно быстро вернуть старый шлюз, а не чинить сеть под звонки пользователей.
Что получим в итоге
- новый шлюз на поддерживаемой Debian или Ubuntu Server;
- понятную схему LAN и WAN;
- явные правила firewall и NAT;
- контролируемую раздачу DHCP и DNS;
- перенесённые публикации внутренних сервисов;
- проверочный лист и план быстрого отката.
1. Сначала выясняем, что делает старый ClearOS
Не начинайте с установки нового сервера. Сначала зафиксируйте адреса интерфейсов, маршруты, открытые порты, правила NAT, DHCP-диапазоны, резервирования, DNS-записи и VPN-сети. Эта инвентаризация часто обнаруживает забытые правила для камер, телефонии или удалённого доступа.
mkdir -p /root/clearos-export
ip -br addr > /root/clearos-export/ip-addresses.txt
ip route > /root/clearos-export/routes.txt
ss -lntup > /root/clearos-export/listening-ports.txt
iptables-save > /root/clearos-export/iptables-save.txt 2>/dev/null || true
nft list ruleset > /root/clearos-export/nftables.txt 2>/dev/null || true
find /etc -maxdepth 3 -type f -iname '*dhcp*' > /root/clearos-export/dhcp-files.txt
find /etc -maxdepth 3 -type f -iname '*dnsmasq*' > /root/clearos-export/dns-files.txt
find /etc -maxdepth 3 -type f -iname '*openvpn*' > /root/clearos-export/vpn-files.txt
tar -czf /root/clearos-export.tar.gz /root/clearos-exportЭти команды не создают полный образ системы, но сохраняют главное: текущее сетевое состояние и список файлов, которые потребуется перенести или перепроверить.
2. Рисуем будущую схему
Для примера используем LAN 192.168.10.0/24. Старый ClearOS остаётся на адресе 192.168.10.1, а новый шлюз во время теста получает 192.168.10.254. Временный адрес позволяет проверить новый сервер, не меняя настройки всего офиса.
WAN: подключение провайдера
LAN: 192.168.10.0/24
Старый шлюз: 192.168.10.1
Новый тестовый шлюз: 192.168.10.254
DHCP: 192.168.10.100-192.168.10.200
Внутренний сайт: 192.168.10.20:4433. Проверяем новый сервер до настройки NAT
Новый сервер должен сам видеть локальную сеть, интернет и DNS. Пока это не работает, настройка NAT только усложнит диагностику.
ip -br addr
ip route
ping -c 3 192.168.10.1
ping -c 3 1.1.1.1
getent hosts example.comПинг до 1.1.1.1 проверяет обычную IP-связность, а getent hosts отдельно проверяет DNS. Это важно: когда IP работает, а сайты не открываются, проблема обычно не в NAT.
4. Включаем маршрутизацию
Linux по умолчанию не пересылает пакеты между интерфейсами. Параметр ip_forward превращает сервер из обычного хоста в маршрутизатор.
printf 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-gateway.conf
sysctl --system
sysctl net.ipv4.ip_forwardПоследняя команда должна вывести значение 1. Это означает, что ядро готово передавать трафик между LAN и WAN, но доступ всё ещё должен разрешить firewall.
5. Настраиваем firewall и NAT
В примере интерфейс LAN называется lan0, WAN — wan0. Замените их на реальные имена из вывода ip -br addr. Правила разрешают клиентам выходить из LAN в интернет, блокируют незапрошенные входящие подключения и выполняют masquerade.
apt update
apt install -y nftables
cp /etc/nftables.conf /etc/nftables.conf.backup 2>/dev/null || true
printf '%s' 'flush ruleset table inet filter { chain input { type filter hook input priority 0; policy drop; ct state established,related accept; iif lo accept; iifname lan0 ip saddr 192.168.10.0/24 accept; } chain forward { type filter hook forward priority 0; policy drop; ct state established,related accept; iifname lan0 oifname wan0 ip saddr 192.168.10.0/24 accept; } chain output { type filter hook output priority 0; policy accept; } } table ip nat { chain postrouting { type nat hook postrouting priority 100; oifname wan0 ip saddr 192.168.10.0/24 masquerade; } }' > /etc/nftables.conf
nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list rulesetКоманда nft -c проверяет синтаксис без применения. Это страховка от ситуации, когда одна опечатка отрезает SSH и весь интернет.
6. Проверяем новый шлюз на одном компьютере
На одном тестовом ПК вручную укажите шлюз 192.168.10.254. Остальные устройства пока продолжают работать через ClearOS.
ip route
ping -c 3 192.168.10.254
ping -c 3 1.1.1.1
getent hosts example.com
curl -I https://example.com
traceroute 1.1.1.1Первый узел в traceroute должен быть новым шлюзом. Если IP-адреса пингуются, но имя сайта не определяется, маршрутизация и NAT уже работают, а исправлять нужно DNS.
7. Готовим DHCP, но пока не включаем
Два DHCP-сервера в одной сети могут выдавать разные шлюзы. Поэтому конфигурацию нового DHCP проверяем заранее, но службу запускаем только после остановки DHCP на ClearOS.
apt install -y dnsmasq
cp /etc/dnsmasq.conf /etc/dnsmasq.conf.backup
printf '%s' 'interface=lan0 bind-interfaces dhcp-range=192.168.10.100,192.168.10.200,255.255.255.0,12h dhcp-option=3,192.168.10.254 dhcp-option=6,192.168.10.254 server=1.1.1.1 server=8.8.8.8' > /etc/dnsmasq.d/lan.conf
dnsmasq --test
systemctl disable --now dnsmasqПосле переключения проверьте новый адрес клиента, шлюз и DNS. Для Linux это можно сделать командами ip addr, ip route и resolvectl status.
8. Переносим публикации внутренних сервисов
Если ClearOS публиковал сайт, видеорегистратор или другой сервис, переносите каждое правило отдельно. Не открывайте весь внутренний сервер наружу.
nft add table ip nat
nft add chain ip nat prerouting '{ type nat hook prerouting priority -100; }'
nft add rule ip nat prerouting iifname wan0 tcp dport 443 dnat to 192.168.10.20:443
nft add rule inet filter forward iifname wan0 oifname lan0 ip daddr 192.168.10.20 tcp dport 443 ct state new,established accept
nft list rulesetПроверяйте правило из внешней сети, например через мобильный интернет. Проверка из LAN по внешнему адресу может дать другой результат из-за hairpin NAT.
9. Проводим переключение
В окно работ остановите DHCP на ClearOS, назначьте новому шлюзу основной адрес 192.168.10.1, включите dnsmasq и обновите аренду на тестовом клиенте. После этого проверяйте не только браузер, но и телефонию, камеры, VPN, печать и внутренние веб-сервисы.
systemctl enable --now dnsmasq
systemctl restart nftables
systemctl status dnsmasq --no-pager
nft list ruleset
journalctl -u dnsmasq --since '10 min ago' --no-pager10. Диагностика
Проверяйте сеть по слоям. Сначала адрес и маршрут клиента, затем доступ до шлюза, потом внешний IP, DNS и только после этого конкретный сервис.
ip -br addr
ip route
sysctl net.ipv4.ip_forward
nft list ruleset
tcpdump -ni lan0
tcpdump -ni wan0
journalctl -u nftables -b --no-pager
journalctl -u dnsmasq -b --no-pager11. Откат
Откатывайтесь, если перестали работать несколько критичных функций и причина не ясна. Быстрый возврат на известную рабочую схему лучше многочасового ремонта под нагрузкой.
systemctl disable --now dnsmasq
systemctl disable --now nftables
cp /etc/nftables.conf.backup /etc/nftables.conf 2>/dev/null || true
rm -f /etc/sysctl.d/99-gateway.conf
sysctl --systemПосле этого верните ClearOS адрес 192.168.10.1, включите на нём DHCP и обновите аренду клиентов.
Критерий успеха: клиенты получают корректные адреса, используют новый шлюз и DNS, открывают интернет и внутренние сервисы, внешние публикации работают, а в журналах нет массовых блокировок или конфликтов DHCP.
