Домашняя сеть, Часть 2. Аудит домашней сети.

Приветствую форумчане, поздравляю всех с Новым 2026 годом. Независимо от того, как вы встретили этот год, желаю вам чтобы он стал ярче и продуктивнее всех предыдущих.
Как и обещал, сегодня я вам расскажу про аудит вашей домашней сети, про создание которой я говорил в прошлой статье. Эта статья будет в формате чистой инструкции, здесь мы не будем отходить от темы и любоваться картинками (ну ладно, только одной). Давайте начинать.

В современном доме почти каждый предмет имеет подключение к интернету: телефоны, ноутбуки, умные колонки, видеокамеры, лампы и даже холодильники. Всё это образует единый цифровой организм, который без надлежащего контроля легко превращается в уязвимую точку входа для злоумышленников.

Аудит позволяет вам увидеть, что происходит под капотом вашей сети, и ответить на три ключевых вопроса:

1. Кто и как подключается к вашему роутеру?
2. Какие сервисы открыты наружу и могут быть использованы против вас?
3. Насколько эффективно работает ваша инфраструктура и не теряется ли производительность?

Ответив на эти вопросы, вы получаете контроль над тем, какие данные проходят через ваш домашний шлюз, какие устройства могут взаимодействовать друг с другом и какие риски присутствуют в текущей конфигурации. Это и есть фундамент цифровой суверенности - способность самостоятельно управлять своей сетью, а не полагаться на, так называемый, черный ящик, который может менять правила без вашего ведома.

Итак что мы проверим: безопасность, производительность, конфигурацию и соответствие - цели аудита.​

Аудит домашней сети обычно делится на четыре взаимосвязанных направления:

1. Безопасность - проверка наличия уязвимых сервисов, слабых паролей, неправильных правил фаервола и отсутствия шифрования. Здесь мы ищем любые дыры, через которые злоумышленник может попасть в вашу локальную сеть или вывести наружу личные данные.
2. Производительность - измерение реальной пропускной способности, задержек и потерь пакетов. Часто медленный интернет объясняется не провайдером, а внутренними конфликтами, перегрузкой роутера или плохой сегментацией трафика.
3. Конфигурация - сравнение текущих настроек роутера, DHCP, NAT, VLAN и Wi‑Fi с лучшими практиками. Мы проверяем, насколько ваша конфигурация документирована, повторяемая и готова к восстановлению после сбоя.
4. Соответствие - оценка того, насколько ваша сеть соответствует вашим собственным требованиям например, изоляция IoT‑устройств, наличие VPN‑доступа, контроль доступа для гостей. Это помогает убедиться, что сеть работает так, как задумано, а не просто как попало.

Каждое из этих направлений будет подробно рассмотрено в последующих разделах, но уже сейчас ясно, что их совместный анализ даст вам полную картину состояния домашней сети и план действий для ее улучшения.

---

Подготовительный этап​

Сбор исходных данных: топология, список устройств, используемые прошивки.​

Прежде чем приступить к сканированию и тестированию, необходимо собрать базу знаний о вашей сети. Это позволяет быстро ориентироваться в результатах аудита и избежать лишних вопросов в процессе.

Топология - нарисуйте схему, где будет указано, как соединены основные элементы:

1. Интернет‑модем -> основной роутер или комбинированный модем‑роутер.
2. Порты LAN, Wi‑Fi‑точки доступа, коммутаторы, репитеры.
3. Любые отдельные подсети к примеру, гостевая Wi‑Fi, VLAN для IoT.
   Даже простая схема в виде рисунка в пеинте поможет визуализировать потоки трафика.

Список устройств - составьте перечень всех подключенных к сети узлов:

• ПК, ноутбуки, смартфоны, планшеты.
• Умные колонки, камеры, лампы, розетки, термостаты.
• Сетевые хранилища, медиа‑серверы, принтеры.
  Для каждого укажите мак адрес, IP‑адрес, тип устройства и назначение. Это можно получить через веб‑интерфейс роутера (раздел DHCP‑clients) или с помощью arp-scan.

Версии прошивок и программного обеспечения - запишите, какая ОС/прошивка работает на роутере (OpenWrt, DD‑WRT, фирменный образ) и на ключевых устройствах (NAS, IP‑камеры). Проверьте даты релизов, ибо уязвимости часто исправляются в новых версиях.
Эти данные станут контрольной точкой, к которой вы сможете вернуться, если в ходе аудита обнаружите изменения или захотите сравнить текущий статус с предыдущим.

Инструменты аудита​

Для полного охвата всех аспектов аудита понадобится набор проверенных утилит. Ниже перечислены самые популярные и удобные решения, которые легко установить на любой ноутбук или Raspberry Pi.

• Nmap - основной сканер портов и сервисов. Позволяет быстро выяснить, какие порты открыты на роутере и на устройствах в локальной сети, а также получить отпечаток ОС.
• Wireshark - пакетный анализатор, который поможет увидеть, какие протоколы и данные передаются по сети в реальном времени. Отлично подходит для обнаружения небезопасных передач.
• OpenWrt / LuCI - если ваш роутер работает под управлением OpenWrt, веб‑интерфейс LuCI предоставляет удобный доступ к конфигурации, журналам и статистике. Кроме того, в консоли можно выполнить команды uci, iptables и logread.
• Fail2Ban - daemon, который автоматически блокирует IP‑адреса после повторяющихся неудачных попыток входа. Его конфигурацию стоит проверить и при необходимости доработать.
• Logwatch или logread + grep - собирает и формирует отчеты из системных журналов. Позволит быстро увидеть подозрительные события без ручного перебора логов.
• Prometheus + Grafana - если вы хотите вести постоянный мониторинг, Prometheus собирает метрики, а Grafana визуализирует их в виде графиков. Это особенно полезно для выявления периодических перегрузок.
• Git‑репозиторий для конфигураций - храните копии всех конфигурационных файлов (/etc/config/в OpenWrt) в отдельном репозитории. Это обеспечивает версионирование, быстрый откат и удобный аудит изменений.

Все перечисленные инструменты работают на популярных операционках и могут быть запущены как в интерактивном режиме, так и автоматически через скрипты.

Создание контрольной точки - резервное копирование текущей конфигурации роутера​

Прежде чем вносить какие‑либо изменения, сделайте полную копию текущего состояния роутера. Это позволит быстро восстановиться в случае ошибок и будет отправной точкой для сравнения после аудита.

Экспорт конфигурации - в OpenWrt это делается командой:

ubus call system board
tar -czf /tmp/config-backup-$(date +%F).tar.gz /etc/config
scp root@192.168.1.1:/tmp/config-backup-*.tar.gz ~/router-backups/

Для фирменных прошивок обычно имеется кнопка Backup/Restore в веб интерфейсе.
Сохраните образ прошивки - если ваш роутер поддерживает загрузку пользовательского образа, скачайте текущий файл прошивки с официального сайта производителя. Это пригодится, если понадобится откат к «чистой» версии.
Запишите текущие правила фаервола - выполните iptables-save > iptables.rules и поместите файл в тот же репозиторий, где храните конфиги.

Инициализируйте Git‑репозиторий если еще не сделано:

mkdir -p ~/router-config && cd ~/router-config
git init
cp /etc/config/* .
git add .
git commit -m "Initial backup - $(date +%F)"

Проверьте возможность восстановления - проверьте, что импортированный бэкап действительно загружается без ошибок, запустив тестовый роутер в виртуальном окружении например, с помощью docker образа openwrtorg/rootfs.
Созданный бэкап станет контрольной точкой, к которой вы сможете вернуться после всех проверок, а также будет полезен в случае, если после внедрения изменений возникнут непредвиденные проблемы.

Собрав полную картину текущей сети, подготовив инструменты и создав резервную копию, вы получаете надежную основу для дальнейшего аудита. На следующих этапах мы будем проверять внешнюю поверхность, внутреннюю сегментацию, правила фаервола, а также измерять производительность и уровень журналирования. Всё это позволит вам построить домашнюю сеть, полностью соответствующую вашим требованиям к безопасности и комфорту.

---

​

Тестирование внешней поверхности​

Сканирование открытых портов извне​

Цель - выяснить, какие сервисы ваш роутер предоставляет наружу. Даже если вы сами не используете удаленный доступ, иногда провайдеры, облачные сервисы или умные устройства оставляют открытые порты, которые могут стать точкой входа для атаки.

Что делаем:

Shodan - онлайн‑поисковик, который уже проиндексировал ваш публичный IP.

1. Введите ваш внешний IP (например, 123.45.67.89) в строку поиска.
2. Теперь обращаем внимание на список найденных сервисов: открытые HTTP интерфейсы, SSH, RDP, Telnet, UPnP и т.д.
3. Сохраните полученные данные в виде простого списка - они станут отправной точкой для дальнейшего локального сканирования.

Nmap - локальный сканер, позволяющий получить более детальную информацию, чем Shodan.

Пример базового сканирования без ARP‑пинга (чтобы обойти некоторые IDS):

nmap -Pn -sS -T4 -p- 123.45.67.89 -oN external-ports.txt

-Pn - отключает предварительную проверку «жив ли хост», полезно, если ваш ISP блокирует ICMP‑эхо.
-sS - SYN‑скан, считается полуподключением, оставляет минимум следов в логах.
-p- - сканирует все 65535 TCP‑портов. если хотите ускорить, можно ограничиться популярными (-F).

Анализ результатов

Сопоставьте открытые порты с вашими ожиданиями. Например, если видите 80/tcp и 443/tcp, проверьте, действительно ли ваш роутер обслуживает веб‑интерфейс на этих портах.
Любой неожиданный порт (например, 23/tcp Telnet, 1900/tcp UPnP, 3389/tcp RDP) требует немедленного расследования.

Проверка доступности сервисов

После того как список открытых портов получен, переходите к живой проверке каждого сервиса. Это позволяет убедиться, что сервис действительно работает, а не просто оставлен открытым в брандмауэре.

Сервис​	Как проверить​	Что ищем в ответе​
SSH (22/tcp)	ssh -v -p 22 user@123.45.67.89	Приветственное сообщение, поддержка только ключей, отсутствие пароля root.
Web‑UI (80/tcp, 443/tcp)	curl -I Ссылка скрыта от гостей и curl -I Ссылка скрыта от гостей	HTTP‑статус 200/302, наличие заголовков X-Frame-Options, Strict-Transport-Security.
UPnP (1900/udp)	upnpc -s -l 123.45.67.89 (или gupnp-universal-cp)	Список опубликованных портов. Если виден ваш роутер - значит UPnP включен.
Telnet (23/tcp)	telnet 123.45.67.89 23	Приветствие без шифрования, запрос пароля в открытом виде.

Перейдем к практике

SSH - если порт открыт, но попытка входа завершается сообщением Connection refused или Permission denied, значит сервис либо не запущен, либо имеет строгие ограничения. Если же соединение устанавливается, проверьте, включена ли двухфакторная аутентификация, и отключен ли вход под root.

Web‑UI - откройте интерфейс в браузере. Убедитесь, что:

1. Используется HTTPS с валидным сертификатом.
2. Страница входа защищена от CSRF (наличие токенов).
3. Нет возможности перебрать логины (защита от брута).

UPnP - в большинстве домашних сетей UPnP включен по умолчанию, но это открывает возможность автоматического проброса портов без вашего ведома. Если вы не используете эту функцию, отключите ее в веб‑интерфейсе роутера.
Telnet - любой открытый Telnet‑порт представляет серьезную угрозу, так как передача данных происходит в открытом виде. Отключите Telnet, заменив его на SSH, либо полностью закройте порт в фаерволе.

---

Оценка наличия уязвимостей в прошивке​

Даже если сервисы закрыты или защищены, устаревшая прошивка роутера может содержать известные уязвимости, которые позволяют обойти любые ограничения.

Определение версии прошивки

• В веб‑интерфейсе роутера обычно внизу страницы указана версия (например, OpenWrt 19.07.7).
• Через консоль: cat /etc/openwrt_release (OpenWrt) или cat /proc/version.

Поиск CVE

• Перейдите на сайт CVE Details (
  Ссылка скрыта от гостей
  ) или NVD (
  Ссылка скрыта от гостей
  ).
• В поле поиска введите номер версии, например OpenWrt 19.07.7. Система выдаст список уязвимостей, привязанных к данной версии.
• Обратите внимание на Critical и High‑уровень уязвимостей - они требуют немедленного обновления.

OpenWrt Security Advisories

• Откройте официальную страницу объявлений (
  Ссылка скрыта от гостей
  ).
• Сравните текущий релиз с последними патчами. Если ваш роутер имеет stable‑ветку, в списке будут указаны фикс‑версии (19.07.8, 21.02.1 и т.д.).

Автоматический сканер

Инструменты вроде RouterScan (Python‑скрипт) могут автоматически собрать информацию о модели и версии роутера, а затем проверить ее в базе уязвимостей.

Пример запуска:

git clone https://github.com/bitdefender/router-scan.git
cd router-scan
python3 routerscan.py -t 123.45.67.89

Оценка риска

• Сопоставьте найденные CVE со статусом "exploitable" (есть известные эксплойты).
• Если уязвимость относится к remote code execution (RCE) или authentication bypass, классифицируйте ее как приоритетную.

Действия после обнаружения

Обновление прошивки - скачайте последнюю стабильную версию с официального сайта, проверьте контрольную сумму и прошейте роутер через веб‑интерфейс или консоль (sysupgrade).
Патч‑менеджмент - включите автоматическое уведомление о новых версиях (можно настроить в OpenWrt через opkg‑скрипты).
Аудит конфигураций после обновления - иногда новые версии меняют структуру файлов конфигурации, проверьте, что все правила фаервола и VPN‑конфиги остались прежними.

---

Аудит внутренней сети​

Инвентаризация устройств​

Что делаем: получаем полную карту MAC‑address -> IP -> тип -> роль. Это фундамент, без которого невозможно понять, кто и как взаимодействует в вашей LAN.

Последовательность действий:

1. Собираем список ARP‑таблицы

• На роутере (OpenWrt) выполните: arp -n > /tmp/arp-list.txt
• На любом компьютере в сети можно воспользоваться arp-scan: sudo arp-scan --localnet --interface wlan0 > arp-scan.txt
• Оба файла содержат строки вида 192.168.1.45 aa:bb:cc:dd:ee:ff <manufacturer>.

2. Определяем тип устройства

• По MAC‑адресу часто можно определить производителя - это уже подсказка (Apple, Samsung, Raspberry Pi, ESP8266 и т.п.).
• Для более точного определения используйте онлайн‑базу MAC‑lookup (например,
  Ссылка скрыта от гостей
  ) или локальный файл oui.txt, который можно загрузить в nmap:nmap -sP -n 192.168.1.0/24 --script broadcast-arp-discover -oG arp-nmap.txt

3. Разбираемся в роли

• LAN - компьютеры, ноутбуки, смартфоны, ноутбуки.
• IoT - умные лампы, розетки, камеры, термостаты, датчики.
• Guest - устройства, подключенные к гостевой Wi‑Fi (обычно помечаются отдельным SSID).

4. Храним инвентарь в Git

Коммитите файл каждый раз после сканирования. Это даст историю появления/исчезновения устройств и поможет быстро обнаружить чужие MAC‑адреса.

---

Проверка сегментации​

Задача: убедиться, что разные группы устройств находятся в изолированных сетевых сегментах и не могут свободно переправлять трафик друг к другу без необходимости.

Определяем, какие VLAN уже настроены

• На OpenWrt: uci show network | grep vlan
• В LuCI откройте Network -> Switch (если ваш роутер имеет управляемый коммутатор) и посмотрите, какие порты отнесены к каким VLAN‑ID.

Проверяем, привязан ли каждый SSID к отдельному VLAN

• В разделе Wireless -> Interface смотрим параметр Network - он указывает, к какой VLAN‑интерфейсу относится данный SSID.

Тестируем меж‑VLAN‑трафик

На машине из LAN (например, ноутбук) попытайтесь достучаться до устройства в IoT‑сети, используя его IP.
ping 192.168.2.15 - если IoT‑сеть находится в 192.168.2.0/24

Если пинг проходит, проверьте правила iptables/firewall на роутере:
iptables -L -v -n | grep VLAN

Ожидаемый результат - блок для всех входящих/исходящих соединений между VLAN, кроме явно разрешенных.

Добавляем недостающие правила

Пример правила, запрещающего любой трафик из VLAN 10 (IoT) в VLAN 20 (LAN), кроме DNS:

uci add firewall rule
uci set firewall.@rule[-1].src='vlan10'
uci set firewall.@rule[-1].dest='vlan20'
uci set firewall.@rule[-1].proto='tcp udp'
uci set firewall.@rule[-1].dest_port='53'
uci set firewall.@rule[-1].target='ACCEPT'


uci add firewall rule
uci set firewall.@rule[-1].src='vlan10'
uci set firewall.@rule[-1].dest='vlan20'
uci set firewall.@rule[-1].target='DROP'


uci commit firewall
/etc/init.d/firewall restart

Проверяем изоляцию гостевой сети

Убедитесь, что устройства, подключенные к SSID Guest, находятся в отдельном VLAN и не имеют доступа к LAN‑ресурсам.

---

​

Анализ DHCP‑политик и статических привязок​

Неправильные DHCP‑настройки могут привести к конфликтам IP‑адресов, утечкам информации (например, выдача DNS‑серверов сторонних провайдеров) и невозможности контролировать, какие устройства получают постоянные адреса.

Получаем текущую конфигурацию DHCP: uci show dhcp

Основные параметры, которые стоит проверить:

• dhcp.lan.start и dhcp.lan.limit - диапазон выдаваемых адресов.
• dhcp.lan.leasetime - длительность аренды.
• dhcp.lan.dhcp_option - переопределенные DNS, шлюз, NTP.

Статические привязки (DHCP‑reservation)

На роутере в разделе Network -> DHCP and DNS -> Static Leases перечислены MAC‑адрес -> IP‑соответствия.
Экспортируйте их в файл: uci export dhcp > dhcp-backup.txt

Проверьте, что все важные устройства (NAS, серверы, камеры) имеют фиксированные IP‑адреса через DHCP‑reservation, а не через ручную статическую настройку.

Проверка конфликтов

Сравните список статических привязок с результатом сканирования ARP. Если найдёте два разных MAC‑адреса, привязанные к одному IP, это конфликт, который нужно устранить.

Контроль DNS‑серверов

Убедитесь, что в DHCP‑опциях указываются только доверенные DNS (например, 1.1.1.1, 8.8.8.8 или ваш локальный Unbound). Если в сети присутствуют устройства, которые могут подменять DNS (например, заражённые роутеры), это потенциальный вектор атаки.

Ограничение выдачи IP‑адресов

Если у вас есть отдельный диапазон для гостей, задайте отдельный dhcp.guest‑раздел с меньшим диапазоном и более коротким временем аренды.

---

​

Выявление мертвых или "забытых" устройств​

Устройства, которые уже не используются, но все еще занимают IP‑адрес в DHCP‑пуле, могут стать привидениями, мешающими новым подключениям, а также скрывать потенциально вредоносный трафик.

Сбор данных о последних арендах

На OpenWrt файл /tmp/dhcp.leases хранит текущие аренды:cat /tmp/dhcp.leases
Формат: expiry MAC IP hostname.

Проверяем, реално ли устройство отсутствует

Попробуйте пинговать IP‑адрес, указанный в заброшенной записи. Если нет ответа в течение 3‑х попыток, скорее всего, устройство отключено.

Очистка пула

Удалите устаревшие записи из DHCP‑конфигурации (в OpenWrt просто перезапустите сервис, он автоматически очистит файл).
/etc/init.d/dnsmasq restart

Регулярный аудит

• Настройте cron‑задачу, которая будет раз в сутки генерировать отчет о забытых арендах и отправлять его на ваш e‑mail или в телеграмм бота: 0 3 * * * /root/scripts/check-dhcp.sh | mail -s "DHCP‑audit" your@email.com

Следующий шаг - настроить постоянный мониторинг (Prometheus + Grafana) и автоматические оповещения о новых MAC‑адресах, изменениях в правилах фаервола и попытках доступа из одной VLAN в другую.

---

Проверка политики фаервола и NAT

Сравнение фактических правил с конфигурацией

Получаем текущие правила ядра - выполните на роутере команду iptables -L -v -n > /tmp/iptables‑current.txt`. Параметры -v добавляют счетчики пакетов/байтов, а -n выводят IP‑адреса и порты в числовом виде.

Экспортируем декларативную конфигурацию - файл /etc/config/firewall хранит правила в виде UCI‑модулей. Сохраните его в читаемый вид командой cat /etc/config/firewall > /tmp/firewall‑config.txt.

Подготавливаем сравнение - из iptables‑current.txt удаляем строки, относящиеся к системным цепочкам (PREROUTING, POSTROUTING, INPUT, FORWARD, OUTPUT) без пользовательских правил, а из firewall‑config.txt оставляем только секции config rule, config redirect, config nat.

Автоматическое сравнение - можно написать небольшой скрипт (вставьте в файл compare‑fw.sh):

bash
   #!/bin/bash
   cfg="/tmp/firewall-config.txt"
   cur="/tmp/iptables-current.txt"

   echo "Проверка наличия правил из конфигурации в iptables..."
   grep -F -f <(awk '/config rule/ {print $0}' "$cfg") "$cur" || echo "Некоторые правила не найдены."

Сделайте файл исполняемым (chmod +x compare‑fw.sh) и запустите (./compare‑fw.sh). Вывод покажет, какие правила из /etc/config/firewall не присутствуют в текущей таблице iptables - значит они не применились.

5. Ручная проверка «потерянных» правил - откройте оба файла, найдите конкретные правила и проверьте правильность указания зон (src, dest), наличие соответствующего интерфейса в network‑конфигурации и отсутствие конфликтов с другими правилами. После исправления перезапустите фаервол командой /etc/init.d/firewall restart.

---

Тестирование правил доступа

Подготовка тестовой среды

Создайте тестовые машины (или контейнеры) в каждой VLAN (LAN, IoT, Guest). Если используете Docker, запустите, например, docker run -d --name test‑lan --net=lannet alpine sleep 3600, docker run -d --name test‑iot --net=iotnet alpine sleep 3600 и docker run -d --name test‑guest --net=guestnet alpine sleep 3600.
В каждый контейнер установите nmap (apk add --no-cache nmap в Alpine, apt-get install -y nmap в Debian/Ubuntu).

Порт‑сканирование из разных зон

Для каждого источника выполните сканирование целевых подсетей, например, из LAN в IoT (192.168.2.0/24):

nmap -p 22,80,443,8080 -sS -T4 192.168.2.0/24 -oN /tmp/lan‑to‑iot.txt

Повторите комбинации: LAN -> IoT, LAN -> Guest, IoT -> LAN, IoT -> Guest, Guest -> LAN, Guest -> IoT. Сравните полученные списки с ожидаемыми - любые открытые порты, которые должны быть закрыты, фиксируйте как нарушение.

Проверка обходных путей

ICMP‑пинг: ping -c 3 192.168.2.10 (из Guest к IoT).
Traceroute: traceroute -T 192.168.2.10 для проверки прохождения через нужный интерфейс.
UDP‑тест (DNS): dig @192.168.2.53 example.com из Guest к DNS‑серверу в IoT.
Port‑knocking (если используется): сначала nmap -p 7000,8000,9000 192.168.2.20, затем nmap -p 22 192.168.2.20.

Документирование

Записывайте каждый тест в простой текстовый файл, например fw‑test‑report.txt, указывая: источник (VLAN/устройство), цель (IP‑подсеть или конкретный IP), сканируемые порты, ожидаемый результат (разрешено/запрещено) и фактический результат (открыт/закрыт).

---

Оценка NAT‑правил

Получаем текущие правила NAT

Выполните iptables -t nat -L -v -n > /tmp/iptables‑nat.txt.

Проверка скрытия внутренних адресов (MASQUERADE / SNAT)

Откройте iptables‑nat.txt и найдите цепочку POSTROUTING. Пример строки:

  Chain POSTROUTING (policy ACCEPT 1500 packets, 120000 bytes)
   pkts bytes target prot opt in out source destination
    30 2100 MASQUERADE all -- * eth0 192.168.0.0/16 0.0.0.0/0

С клиентского хоста (например, из LAN) запросите свой публичный IP: curl -s https://ifconfig.me. Если полученный адрес совпадает с публичным IP вашего провайдера, NAT работает корректно.

Проверка порт‑форвардинга (DNAT)

В iptables‑nat.txt ищите правила в цепочке PREROUTING. Пример:

  Chain PREROUTING (policy ACCEPT 200 packets, 15000 bytes)
   pkts bytes target prot opt in out source destination
    5 300 DNAT tcp -- * * 0.0.0.0/0 203.0.113.10 tcp dpt:8080 to:192.168.1.100:80

Тест из внешней сети (мобильный телефон, VPN‑сервер или любой сервис, позволяющий выполнить запрос к вашему публичному IP) выполните: curl -s http://203.0.113.10:8080. Ожидается ответ от внутреннего сервера 192.168.1.100:80.

Тест из внутренней сети (проверка hairpin NAT): curl -s http://203.0.113.10:8080 из LAN. Если ваш роутер поддерживает hairpin, запрос тоже отработает; иначе будет таймаут.

Проверка DMZ‑зоны

Ищите правило DNAT без указания конкретного порта, например:

  DNAT tcp -- * * 0.0.0.0/0 203.0.113.20 tcp dpt:1:65535 to:192.168.2.200

Тестируйте несколько портов к публичному IP DMZ: nmap -p 22,80,443 -sS 203.0.113.20. Открытые порты должны обслуживаться тем же внутренним хостом.

Общие рекомендации по NAT

1. Открывайте только те порты, которые действительно нужны извне.
2. Добавляйте логирование для всех DNAT‑правил, например: iptables -t nat -A PREROUTING -p tcp --dport 8080 -j LOG --log-prefix "DNAT‑8080: ".
3. Убедитесь, что ответы от внутренних серверов проходят через POSTROUTING‑MASQUERADE; иначе они могут уйти напрямую в интернет, минуя роутер.

После выполнения всех пунктов вы получите набор текстовых файлов с результатами, которые можно хранить в системе контроля версий и использовать для сравнения после обновлений прошивки или изменения конфигурации.

Следующий шаг - автоматизировать запуск этих проверок (cron или systemd‑таймер) и отправлять результаты в ваш мониторинг (email, Telegram‑бот, Grafana‑alert), превратив ручной аудит в постоянный процесс контроля безопасности домашней сети.

---

Оценка механизмов аутентификации и шифрования

Безопасность Wi‑Fi

Проверка режима защиты

• Откройте веб‑интерфейс или подключитесь по SSH к роутеру.
• Выполните:

bash
     uci show wireless.@wifi-iface[0].encryption

Ожидаемый результат: psk2+ccmp (WPA2‑PSK с AES) или sae (WPA3‑SAE). Если вывод содержит mixed‑mode или tkip, необходимо заменить его.

Переключение на WPA3, если поддерживается

• В файле /etc/config/wireless найдите секцию config wifi-iface.
• Установите параметры:

bash
     uci set wireless.@wifi-iface[0].encryption='sae'
     uci set wireless.@wifi-iface[0].key='НовыйСильныйПароль'
     uci commit wireless
     /etc/init.d/network restart

Если ваш роутер не поддерживает WPA3, оставьте WPA2‑PSK, но убедитесь, что используется только AES (ccmp).

Аудит паролей

Выведите текущий пароль:

bash
     uci get wireless.@wifi-iface[0].key

Он должен быть минимум 12‑символьным, включать буквы разного регистра, цифры и специальные символы.

Отключение WPS

WPS часто реализуется как отдельный сервис. Проверьте наличие опции:

bash
     uci get wireless.@wifi-iface[0].wps

Если значение 1, отключите:

bash
     uci set wireless.@wifi-iface[0].wps='0'
     uci commit wireless
     /etc/init.d/network restart

Проверка реального уровня защиты

• С помощью ноутбука/смартфона откройте список доступных сетей.
• Убедитесь, что рядом с именем SSID отображается WPA2‑AES или WPA3‑SAE (в зависимости от вашего роутера).
• Попробуйте подключиться, используя неправильный пароль - система должна отклонить подключение без выдачи дополнительных сведений.

---

VPN‑конфигурация (WireGuard / OpenVPN)

WireGuard

Список активных интерфейсов

bash
   wg show

Вы должны увидеть один или несколько интерфейсов (например, wg0).

Проверка публичных и приватных ключей

• Откройте файл конфигурации (обычно /etc/wireguard/wg0.conf).
• Убедитесь, что в секции [Interface] присутствуют строки:

     PrivateKey = <64‑символьный‑ключ>
     ListenPort = 51820   # или другой порт, но не 22/80/443

- В секциях [Peer] каждый клиент должен иметь уникальный PublicKey.

Ограничения доступа

В каждом [Peer] проверьте, что указано поле AllowedIPs. Оно должно ограничивать трафик только теми подсетями, которые клиенту действительно нужны. Пример:

     AllowedIPs = 10.0.0.2/32, 192.168.10.0/24

Если AllowedIPs = 0.0.0.0/0, ::/0, клиент получает полный доступ к сети - используйте только при необходимости.

Фаервол для WireGuard

Убедитесь, что входящий UDP‑порт, указанный в ListenPort, разрешён только из доверенных источников (если это необходимо). Пример правила iptables:

bash
     iptables -A INPUT -p udp -m udp --dport 51820 -s 203.0.113.0/24 -j ACCEPT
     iptables -A INPUT -p udp -m udp --dport 51820 -j DROP

Регулярная ротация ключей

При изменении конфигурации генерируйте новые ключи:

bash
     wg genkey | tee privatekey | wg pubkey > publickey

Обновите wg0.conf, перезапустив интерфейс:

bash
     wg-quick down wg0 && wg-quick up wg0

---

OpenVPN

Проверка наличия сервера

bash
   ps aux | grep openvpn

Должен быть запущен процесс openvpn --config /etc/openvpn/server.conf.

Аудит сертификатов и ключей

Откройте server.conf и найдите строки:

     ca ca.crt
     cert server.crt
     key server.key
     dh dh.pem

Убедитесь, что файлы находятся в защищённом каталоге (/etc/openvpn/keys/) и имеют права 600 (только root).

Проверьте срок действия CA‑сертификата:

bash
     openssl x509 -noout -dates -in /etc/openvpn/keys/ca.crt

Если срок истекает в ближайшее время - генерируйте новый CA и переиздайте клиентские сертификаты.

Настройки шифрования

В server.conf должно быть указано минимум 256‑битное шифрование, например:

     cipher AES-256-CBC
     auth SHA256

Если присутствует cipher BF-CBC или auth MD5 - замените их на более сильные варианты и перезапустите сервер.

Ограничение доступа по клиенту

• В конфигурацию client-config-dir добавьте отдельные файлы для каждого клиента (например, client1).
• В файле client1 пропишите push "route 10.0.0.0 255.255.255.0" только для нужных подсетей.
• Для полной изоляции клиента добавьте iroute в его конфиг и client-to-client не включайте.

Фаервол для OpenVPN

Откройте UDP/TCP‑порт, указанный в port (по умолчанию 1194):

bash
     iptables -A INPUT -p udp --dport 1194 -j ACCEPT
     iptables -A INPUT -p tcp --dport 1194 -j ACCEPT

При необходимости ограничьте IP‑адреса источников:

bash
     iptables -A INPUT -p udp --dport 1194 -s 203.0.113.0/24 -j ACCEPT

Ротация сертификатов

• Создайте новые клиентские сертификаты, отзовите старые (через crl.pem).
• Обновите client-config-dir и перезапустите OpenVPN.

SSH‑доступ

Проверка текущих параметров

bash
   grep -E '^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AllowUsers|AllowGroups|Match)' /etc/ssh/sshd_config

Ожидаемые значения:

• PermitRootLogin no
• PasswordAuthentication no (если используется только аутентификация ключами)
• PubkeyAuthentication yes
• AllowUsers или AllowGroups - список конкретных пользователей/групп, которым разрешён вход.

Включение аутентификации по публичному ключу

• Убедитесь, что в sshd_config присутствует строка PubkeyAuthentication yes.
• На клиентском компьютере создайте пару ключей (если ещё нет):

bash
     ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

Скопируйте публичный ключ на роутер:

bash
     ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<router_ip>

Публичный ключ будет помещён в /root/.ssh/authorized_keys (или в домашний каталог другого пользователя, если вы отключили root).

Отключение входа под root

• В sshd_config установите PermitRootLogin no.
• Если вам нужен доступ к привилегированным операциям, создайте отдельного пользователя (например, admin) и добавьте его в группу wheel (или sudo).

bash
     adduser admin
     usermod -aG wheel admin
     echo 'admin ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

Ограничение доступа по IP

Добавьте в конец sshd_config блок Match для ограничения диапазоном:

bash
     Match Address 192.168.1.0/24,10.0.0.0/8
         PasswordAuthentication no
         PubkeyAuthentication yes

При необходимости добавьте отдельный DenyUsers/DenyGroups для всех, кто не входит в список разрешённых.

Перезапуск SSH‑демона

bash
   /etc/init.d/sshd restart   # OpenWrt
   systemctl restart sshd     # systemd‑based

Тестирование

Попробуйте подключиться из разрешённого IP‑адреса:

bash
     ssh -i ~/.ssh/id_ed25519 admin@<router_ip>

Затем попытайтесь подключиться из неразрешённого диапазона (например, через мобильный hotspot). Ожидается отказ с сообщением «Connection closed by …» или «Permission denied».

Попробуйте вход под root: ssh root@<router_ip> - должно быть отклонено.

---

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

Неподдерживаемый режим Wi‑Fi - переключите роутер в режим WPA2‑AES, замените пароль, отключите WPS.
Слабый пароль Wi‑Fi - замените его на случайную строку длиной минимум 16 символов, включающую специальные символы.
VPN‑правила слишком широкие - сузьте AllowedIPs (WireGuard) или push "route …" (OpenVPN) до минимально необходимого набора подсетей.
Старые/слабые сертификаты OpenVPN - сгенерируйте новые с RSA‑4096 или ECC‑256, замените cipher и auth на AES‑256‑GCM и SHA‑256.
SSH‑доступ без ключей - отключите PasswordAuthentication, создайте ключи, добавьте их в authorized_keys.
Root‑логин включён - отключите PermitRootLogin, создайте обычного пользователя с sudo‑правами.
Отсутствие ограничения по IP - добавьте Match Address в sshd_config и/или firewall‑правила (iptables -A INPUT -p tcp --dport 22 -s <trusted‑net> -j ACCEPT).

После внесения правок всегда проверяйте, что сервисы успешно перезапускаются и работают корректно, а затем фиксируйте изменения в системе контроля версий (Git) и в журнале изменений. Это позволит быстро откатить конфигурацию в случае ошибки и сохранять историю аудита безопасности.

---

Мониторинг и журналирование в домашней сети (OpenWrt/LEDE)

Ниже - пошаговый чек‑лист, который можно выполнять вручную или превратить в небольшие скрипты/cron‑задачи. Все команды проверяются на типовой прошивке OpenWrt; при необходимости замените пути/имена пакетов на те, что есть в вашей сборке.

Проверка включённого системного логирования

Syslog‑демон (rsyslog / syslog-ng)

Убедитесь, что пакет установлен

bash
   opkg list-installed | grep -E 'syslog|rsyslog|syslog-ng'

Если ничего не найдено - ставьте один из вариантов:

bash
   opkg update
   opkg install rsyslog   # или syslog-ng

Запуск и автозапуск

bash
   /etc/init.d/rsyslog enable
   /etc/init.d/rsyslog start

Для syslog-ng команды аналогичны (/etc/init.d/syslog-ng).

Проверка, что логгер действительно пишет

bash
   logger "Тестовое сообщение от $(hostname)"
   grep "Тестовое сообщение" /var/log/messages

Если строка найдена - логирование работает.


logread (встроенный буфер журнала)

OpenWrt хранит последние записи в кольцевом буфере /var/log/.

logread | tail -n 20

Если вывод пустой, проверьте, что logd запущен:

bash
  /etc/init.d/logd status
  /etc/init.d/logd start   # при необходимости

Чтобы увеличить размер буфера, отредактируйте /etc/config/system:

bash
  uci set system.@system[0].log_size='256'   # размер в КБ (по умолчанию ~64КБ)
  uci commit system
  /etc/init.d/logd restart

Настройка и проверка Fail2Ban / IP‑tables‑банов

Установка Fail2Ban

opkg update
opkg install fail2ban

Базовая конфигурация

Создайте директорию для локальных правил

bash
   mkdir -p /etc/fail2ban/jail.d

Файл jail.local (можно разместить в /etc/fail2ban/jail.local или в jail.d/ssh.conf):

ini
   [DEFAULT]
   banaction = iptables-multiport
   banaction_allports = iptables-allports
   findtime  = 600          ; 10 минут
   bantime   = 3600         ; 1 час
   maxretry  = 5

   [sshd]
   enabled   = true
   port      = ssh
   filter    = sshd
   logpath   = /var/log/auth.log

Если ваш роутер пишет ssh‑логи в другой файл (/var/log/messages), замените logpath соответственно.

Запуск

bash
   /etc/init.d/fail2ban enable
   /etc/init.d/fail2ban start

Проверка статуса

bash
   fail2ban-client status sshd

Вывод покажет количество текущих банов и их IP‑адреса.


Проверка работы вручную

Смоделировать несколько неудачных попыток входа

bash
   for i in $(seq 1 6); do
       ssh -o PreferredAuthentications=publickey -o PubkeyAuthentication=no \
           -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null \
           root@<router_ip> 2>/dev/null || true
   done

После пятой‑шестой попытки Fail2Ban должен добавить ваш IP в iptables‑правило.

Показать правило в iptables

bash
   iptables -L -n -v | grep -i fail2ban

Ожидается строка типа:

   REJECT     all  --  192.0.2.55  0.0.0.0/0  reject-with icmp-port-unreachable

Настройка дополнительных фильтров

Web‑сервер (nginx/Apache) - используйте готовый фильтр nginx-http-auth, apache-auth.
VPN‑сервер (WireGuard/OpenVPN) - создайте собственный фильтр, ищущий сообщения вида Failed to authenticate в логах OpenVPN (/var/log/openvpn.log).

Пример простого фильтра openvpn.conf в /etc/fail2ban/filter.d/:

[Definition]
failregex = ^.*AUTH_FAILURE.*<HOST>$
ignoreregex =

И соответствующий jail:

[openvpn]
enabled = true
port    = 1194
protocol = udp
filter  = openvpn
logpath = /var/log/openvpn.log
maxretry = 3
bantime = 7200

Перезапустите Fail2Ban:

/etc/init.d/fail2ban restart

Сбор метрик трафика и визуализация

Установка collectd и luci-statistics

opkg update
opkg install collectd luci-statistics

luci-statistics - это набор плагинов collectd, упакованных для OpenWrt, а также веб‑интерфейс в LuCI.

Базовая настройка collectd

Файл конфигурации - /etc/collectd/collectd.conf. Пример минимального набора:

Hostname    "router01"
FQDNLookup  false
BaseDir     "/var/run/collectd"
PIDFile     "/var/run/collectd.pid"
PluginDir   "/usr/lib/collectd"
TypesDB     "/usr/share/collectd/types.db"

LoadPlugin cpu
LoadPlugin interface
LoadPlugin df
LoadPlugin network

<Plugin interface>
    Interface "eth0"
    Interface "wlan0"
</Plugin>

<Plugin network>
    Server "192.0.2.200" "25826"
</Plugin>

Server - IP‑адрес машины, где будет принимать метрики (например, ваш сервер с Graphite/InfluxDB).
Если планируете хранить данные локально, замените <Plugin network> на <Plugin csv> или <Plugin rrdtool>.

Запуск и проверка

/etc/init.d/collectd enable
/etc/init.d/collectd start

Проверьте, что процесс работает:

ps | grep collectd

Посмотрите, какие метрики собираются:

collectdctl listval

Отправка данных в Grafana (через InfluxDB)

Установите InfluxDB на отдельном сервере (Ubuntu/Debian пример):

bash
   sudo apt-get install influxdb
   sudo systemctl enable influxdb
   sudo systemctl start influxdb

Создайте базу данных:

bash
   influx -execute "CREATE DATABASE router_stats"

Настройте collectd отправлять в InfluxDB - используйте плагин write_http:

Добавьте в collectd.conf:

conf
   LoadPlugin write_http

   <Plugin write_http>
       URL "http://192.0.2.200:8086/write?db=router_stats"
       User "router"
       Password "s3cr3t"
       Format "json"
   </Plugin>

Перезапустите collectd.

Grafana

1. Установите Grafana на том же сервере, где InfluxDB, или на отдельном.
2. В веб‑интерфейсе Grafana добавьте Data Source -> InfluxDB, укажите URL (http://localhost:8086), базу router_stats.
3. Создайте дашборд:

• Panel 1 - Трафик по интерфейсам: запрос SELECT mean("bytes") FROM "interface" WHERE $timeFilter GROUP BY time($__interval), "interface" (показывает входящий/исходящий трафик).
• Panel 2 - Загрузка CPU: SELECT mean("value") FROM "cpu" WHERE $timeFilter GROUP BY time($__interval), "type"
• Panel 3 - Объём свободного места на диске: SELECT last("value") FROM "df" WHERE "type"='free' AND $timeFilter GROUP BY "mountpoint"

Сохраните дашборд и установите автоматическое обновление (например, каждые 30 сек).


Локальная визуализация через LuCI

В LuCI уже есть раздел Status -> Statistics (если установлен luci-statistics).

• Здесь можно увидеть графики в реальном времени без дополнительных серверов.
• При желании экспортировать данные в CSV: нажмите «Download CSV» рядом с нужным графиком.

Тестирование и проверка «сквозных» данных

Генерация трафика - запустите iperf3 между роутером и клиентом:

bash
   iperf3 -c <router_ip> -t 30

Сравните показания:

• В Grafana должен отразиться рост метрик interface (bytes/packets).
• В LuCI в разделе Statistics тот же рост будет виден в графике «Network Interface».

Проверьте, что метрики сохраняются - выполните запрос к InfluxDB напрямую:

bash
   influx -database router_stats -execute "SELECT * FROM interface ORDER BY time DESC LIMIT 5"

Последние записи должны соответствовать вашему тестовому трафику.

---

Как собрать всё в один мониторинг‑скрипт (опционально)

#!/bin/sh
# monitor.sh - базовая проверка состояния логов, Fail2Ban и collectd

# 1. Syslog
if ! pgrep -x rsyslog >/dev/null; then
    echo "rsyslog не запущен, пытаемся стартовать..."
    /etc/init.d/rsyslog start
fi

# 2. Logread - проверяем, что буфер не пустой
if [ -z "$(logread | tail -n 5)" ]; then
    echo "logread пуст, стартуем logd"
    /etc/init.d/logd start
fi

# 3. Fail2Ban статус
if ! pgrep -x fail2ban-server >/dev/null; then
    echo "Fail2Ban не работает, стартуем"
    /etc/init.d/fail2ban start
else
    echo "Fail2Ban запущен, текущие баны SSH:"
    fail2ban-client status sshd | grep Banned
fi

# 4. Collectd статус
if ! pgrep -x collectd >/dev/null; then
    echo "Collectd не запущен, стартуем"
    /etc/init.d/collectd start
else
    echo "Collectd работает, проверяем метрики интерфейсов:"
    collectdctl listval | grep interface
fi

Сделайте файл исполняемым (chmod +x monitor.sh) и добавьте в cron, чтобы он проверял состояние каждую полночь:

0 0 * * * /root/monitor.sh >> /root/monitor.log 2>&1

---

Тестирование производительности домашнего маршрутизатора

Измерение пропускной способности между VLAN:

1. Подготовка среды

Создайте два VLAN‑интерфейса (если они ещё не созданы).

bash
   # пример: VLAN 10 на eth0, VLAN 20 на eth0
   uci set network.vlan10=interface
   uci set network.vlan10.ifname='eth0.10'
   uci set network.vlan10.proto='static'
   uci set network.vlan10.ipaddr='10.0.10.1'
   uci set network.vlan10.netmask='255.255.255.0'

   uci set network.vlan20=interface
   uci set network.vlan20.ifname='eth0.20'
   uci set network.vlan20.proto='static'
   uci set network.vlan20.ipaddr='10.0.20.1'
   uci set network.vlan20.netmask='255.255.255.0'

   uci commit network
   /etc/init.d/network restart

Подключите два тестовых клиента

• Клиент A - в VLAN 10, IP 10.0.10.10
• Клиент B - в VLAN 20, IP 10.0.20.10

Оба клиента должны иметь доступ к роутеру (пинг до 10.0.10.1 и 10.0.20.1 работает).

Установите iperf3 на роутер и на оба клиента

bash
   # на роутере
   opkg update
   opkg install iperf3

   # на Linux‑клиентах (Debian/Ubuntu)
   sudo apt-get install iperf3

2. Запуск теста

Запустите сервер iperf3 на роутере (можно привязать к конкретному VLAN‑интерфейсу).

bash
   iperf3 -s -B 10.0.10.1   # слушаем только на IP VLAN 10

Если хотите измерять сразу оба направления, запустите два сервера (по одному на каждый VLAN) в разных терминалах, либо используйте -B 0.0.0.0 (весь роутер).

Тест из VLAN 10 -> VLAN 20 (клиент в VLAN 10, сервер в VLAN 20).

На клиенте A:

bash
   iperf3 -c 10.0.20.1 -t 30 -i 5

Параметры:

- -t 30 - 30 секунд теста (достаточно, чтобы увидеть стабильный профиль).
- -i 5 - вывод промежуточных результатов каждые 5 сек.

Тест в обратном направлении (VLAN 20 -> VLAN 10).

На клиенте B:

bash
   iperf3 -c 10.0.10.1 -t 30 -i 5

Тест с несколькими потоками (чтобы задействовать всю пропускную способность ASIC/CPU).

bash
   iperf3 -c 10.0.20.1 -P 4 -t 30 -i 5   # 4 параллельных TCP‑потока

3. Интерпретация результатов

• Throughput (Mbits/sec) - основной показатель. Если получаете менее 80 % от номинального порта (например, 950 Mbit/s на гигабитном соединении), ищите узкое место:
• Перегрузка CPU
• Ограничения MTU (проверьте, нет ли фрагментации)
• Неправильные VLAN‑теги на коммутаторе

Retransmits - количество повторных передач. Наличие их указывает на потери/перегрузку канала.

CPU‑load во время теста - если CPU поднимается до 80‑90 % на роутере, то именно он ограничивает пропускную способность.


4. Оценка задержек и потерь пакетов

Простой ping

# из VLAN 10 к VLAN 20
ping -c 20 -i 0.2 10.0.20.1

• -c 20 - 20 запросов, достаточно для статистики.
• -i 0.2 - интервал 200 мс (не слишком часто, чтобы не создавать нагрузку).

Что смотреть:

• min/avg/max/stddev - средняя задержка и разброс.
• % packet loss - если > 0 %, значит где‑то происходит потеря (может быть в VLAN‑транке, в коммутаторе, в кабеле).

5. Тест UDP‑потока (iperf3 UDP)

Для оценки потерь при нагрузке используйте UDP‑тест:

# На роутере - сервер UDP
iperf3 -s -u -B 10.0.10.1

# На клиенте VLAN 20 - клиент UDP, 10 Mbit/s
iperf3 -c 10.0.10.1 -u -b 10M -t 30 -i 5

iperf3 выведет lost packets, jitter и bandwidth. Если наблюдается значительная потеря (> 1 %), значит в пути (или на роутере) не хватает буферов/CPU.


6. Анализ нагрузки на роутер

CPU и RAM в реальном времени

# Стандартный монитор
top -b -d 2 | head -n 20

Обратите внимание на %CPU у процессов collectd, dnsmasq, hostapd, firewall, iptables, ppp и, конечно, iperf3 (если тест запущен).

Для более детального профиля используйте htop (если установлен) или procps‑скрипт:

# скрипт, выводящий среднюю загрузку за 10 сек
cat <<'EOF' > /usr/bin/cpu_load.sh
#!/bin/sh
echo "CPU load (1,5,15 мин): $(cat /proc/loadavg)"
echo "CPU usage per core:"
mpstat -P ALL 1 1 | awk '/Average/ && $2 ~ /[0-9]/ {printf "core %s: %.1f%%\n",$2,100-$12}'
EOF
chmod +x /usr/bin/cpu_load.sh
/usr/bin/cpu_load.sh

Память (RAM)

free -h

• used + buff/cache не должны превышать 80 % от общей памяти.
• Если swap активно (включён в OpenWrt), это уже сигнал о нехватке RAM.

Конвейерные (pipeline) таблицы и NAT

OpenWrt использует iptables/nftables. При большом числе правил (например, в Fail2Ban, в DHCP‑резерве, в статических маршрутах) ядро может начать тратить значительные ресурсы на поиск в таблицах.

Показать количество правил

bash
   iptables -L -v -n | grep -c "policy"

Для nftables:

bash
   nft list ruleset | wc -l

Собрать статистику по цепочкам

bash
   iptables -L INPUT -v -n
   iptables -L FORWARD -v -n
   iptables -L OUTPUT -v -n

Обратите внимание на столбцы pkts и bytes - если одна цепочка получает сотни тысяч пакетов в секунду, имеет смысл вынести её в отдельный iptables‑модуль (например, conntrack).

Проверка таблицы соединений (conntrack)

bash
   cat /proc/sys/net/netfilter/nf_conntrack_count
   cat /proc/sys/net/netfilter/nf_conntrack_max

- Если count приближается к max (по умолчанию 65536), увеличьте лимит:

bash
     echo 131072 > /proc/sys/net/netfilter/nf_conntrack_max
     # или через sysctl
     uci set system.@system[0].nf_conntrack_max='131072'
     uci commit system
     /etc/init.d/sysctl restart

Сбор метрик в collectd

Если collectd уже установлен, включите плагины cpu, memory, interface, iptables (плагин iptables доступен в пакете collectd-mod-iptables). После перезапуска collectd метрики появятся в Grafana, и можно построить графики "iptables‑hits per rule", "conntrack‑usage", "CPU‑load vs. iperf3 throughput".


Сводный скрипт для однократного замера

#!/bin/sh
# performance_snapshot.sh - собрать «одноразовый» набор метрик

echo "=== CPU load ==="
cat /proc/loadavg

echo "=== CPU usage per core ==="
mpstat -P ALL 1 1 | awk '/Average/ && $2 ~ /[0-9]/ {printf "core %s: %.1f%%\n",$2,100-$12}'

echo "=== RAM ==="
free -h

echo "=== Conntrack ==="
echo -n "count: "; cat /proc/sys/net/netfilter/nf_conntrack_count
echo -n "max:   "; cat /proc/sys/net/netfilter/nf_conntrack_max

echo "=== iptables rule counters ==="
iptables -L INPUT -v -n | grep -v "policy"
iptables -L FORWARD -v -n | grep -v "policy"
iptables -L OUTPUT -v -n | grep -v "policy"

echo "=== Interface stats (collectd) ==="
collectdctl listval | grep interface

Сделайте исполняемым (chmod +x performance_snapshot.sh) и запустите сразу после завершения iperf3‑теста. Сравните полученные цифры с «покойным» состоянием (без нагрузки) - разница покажет, насколько сильно тест нагружает роутер.

---

Ну что? Не устали? Аудит сети прошел успешно. Мы выявили и устранили ряд потенциальных уязвимостей, значительно повысив уровень безопасности и управляемости нашей сети.
Теперь сеть не только готова к обороне, а еще и проверена тестами.

Можно спать спокойно. Или нет?


В любом случае, еще раз поздравляю вас всех с Новым годом. Желаю успехов в дальнейших изучениях. Уверен, что у вас все получится.