Сегментация сети на VPS нужна, чтобы приватные сервисы не были доступны напрямую из интернета и не «перетекали» друг в друга слишком широко. Проще говоря: вы разделяете трафик на зоны, а правила фаервола решают, кто с кем может общаться и через какие порты.
На практике сегментация сводится к двум задачам. Первая — сделать так, чтобы у сервиса не было прямого маршрута/доступа с публичной стороны. Вторая — закрепить доступ правилами фаервола по принципу минимальных разрешений: всё запрещено по умолчанию, разрешаем только нужное.
Дальше разберём, как спроектировать зоны, как сформировать правила фаервола для приватных сервисов и как проверить, что модель реально работает.
Модель сети: зоны, адреса и маршрутизация
Перед настройкой фаервола удобно описать, какие зоны у вас будут и какой трафик в них допустим. Даже если всё крутится на одной VPS, полезно мыслить «как в облачной сети»: есть публичная часть, приватная часть и отдельная зона для администрирования.
Типовые зоны для приватных сервисов
- Публичная зона (Internet-facing)
- туда попадают сервисы, которые должны быть доступны извне: web (80/443), иногда API.
- у этих сервисов обычно внешний IP или публичный интерфейс.
- Приватная зона (Service-private)
- туда вы размещаете базы данных, внутренние API, очереди, админские endpoints, которые не должны открываться в интернет.
- обычно у приватных сервисов нет прямого доступа с публичной стороны.
- Зона администрирования (Management)
- доступ к SSH, панелям мониторинга, репозиториям, консольным сервисам.
- обычно это либо отдельный IP, либо ограничение по списку доверенных адресов, либо доступ через jump host/ VPN.
Как выглядит адресация и доступы
Есть два рабочих варианта:
- На уровне провайдера: вы используете отдельную приватную сеть (VPC/VNet) или private IP и правила провайдера (security groups/ACL) дополняете фаерволом на хосте.
- На уровне ОС: на одной VPS вы делите сеть на сегменты логически (интерфейсы/бриджи) или технически (network namespaces/контейнерные сети), а фаерволом ограничиваете потоки между ними.
В обоих случаях принцип один: приватные сервисы должны быть доступны только из нужных источников. Если вы рассчитываете «на то, что порт не открыт», это часто ломается при рефакторинге или ошибке в правилах. Фаервол должен оставаться последней линией защиты.
Маршрутизация как точка риска
Сегментация теряется, если маршруты позволяют обойти ограничения. Например, вы разрешили доступ к сервису с приватной зоны, но забыли запретить форвардинг между интерфейсами или ошибочно включили проброс портов.
Поэтому перед правилами уточните:
- какие интерфейсы у VPS (например, eth0 публичный, eth1 приватный/внутренний мост);
- включён ли IP forwarding (и зачем);
- какие порты реально слушает сервис (на адресе 127.0.0.1, на приватном IP, на 0.0.0.0).
Зачастую уже выбор listen-адреса уменьшает нагрузку на фаервол и снижает шанс утечки.
Базовые правила фаервола для приватных сервисов
Дальше — ядро. Хорошая модель фаервола для приватных сервисов строится вокруг трёх принципов: default deny, явные allow по источникам и учёт состояний соединений.
Принцип default deny: всё запрещено, кроме разрешённого
Начинайте с того, что запрещаете входящий и форвардируемый трафик, а затем разрешаете точечно.
Для INPUT цепочки (вход на саму VPS) это означает:
- по умолчанию DROP или REJECT;
- разрешаем только то, что действительно нужно: SSH из доверенных IP, 80/443 на web, и доступ к приватным портам только с конкретных подсетей/адресов.
Если у вас есть форвардинг (например, VPS маршрутизирует трафик между сегментами), то аналогично:
- FORWARD по умолчанию запрещён;
- разрешаем только конкретные направления.
Statefull-подход: учитывайте существующие соединения
Большинство сетевых атак используют необычные пакеты и попытки «вписаться» в неочевидные этапы сессии. Statefull-фильтрация решает часть проблем проще и быстрее.
В терминах практики:
- разрешайте входящие пакеты в рамках уже установленного/связанного соединения;
- новые соединения разрешайте только через чётко заданные правила.
Это снижает количество «дыр» от случайно открытых портов.
Allow по минимальным источникам
Для приватных сервисов вам почти всегда нужны правила в формате:
- разрешить доступ к порту сервиса только с адреса(ов) reverse proxy, jump host или VPN;
- запретить доступ к этому же порту из интернета.
Хорошее правило звучит так: «разрешаем порт БД только с подсети, где живут приложения, и только с нужных интерфейсов».
Если у вас несколько приложений, не открывайте порт всем. Лучше перечислить подсети/адреса приложений, а не «разрешить всё внутри приватной сети», если внутри сети много сущностей.
Логирование: меньше шума, больше смысла
Логирование не должно превращаться в поток гигабайтов. Делайте так:
- логируйте DROP только в ограниченном режиме или с префиксами/фильтрами;
- логируйте отдельные важные политики (например, попытки доступа к портам БД из публичной зоны).
Если вы настраиваете фаервол впервые, логирование поможет понять, какие правила на самом деле попадут в реальный трафик.
nftables vs iptables: логика одинаковая, синтаксис разный
В современных системах чаще встречается nftables, но принципы те же.
- nftables хорошо подходит для структурирования правил по таблицам/цепочкам и работе с наборами адресов.
- iptables подходит, если у вас уже есть готовая схема и привычные шаблоны.
Важно не то, чем вы режете трафик, а то, что вы придерживаетесь модели «разрешаем только нужное». Ниже примеры будут в стиле nftables/универсальной логики, но вы сможете перенести смысл на ваш стек.
Сценарий 1: приватный сервис за reverse proxy или балансировщиком
Самая частая схема: приватный сервис не открывается в интернет, а общается с приватной сетью через proxy. В интернете остаётся только точка входа: proxy (или load balancer), а правила фаервола блокируют прямые подключения к приватному сервису.
Приватный сервис доступен только прокси: правила по источнику
Допустим:
- публично доступен Nginx/Envoy на VPS по 80/443;
- приватный сервис (внутренний API) слушает порт 8080 только на приватном интерфейсе;
- БД слушает порт 5432 на приватном интерфейсе.
Тогда правила выглядят концептуально так:
- INPUT: разрешить 80/443 с интернета;
- INPUT: разрешить SSH только из списка доверенных IP;
- INPUT: запретить 8080/5432 с публичной стороны;
- INPUT или FORWARD: разрешить 8080/5432 только от IP proxy (или из приватной подсети приложения).
Если proxy и приватный сервис на одной VPS, «источник» может быть не внешний адрес, а интерфейс/loopback. Тут важно, чтобы приватный сервис слушал правильный адрес и чтобы вы не открывали порт на публичном интерфейсе.
Практический чек: listen-address и bind на интерфейс
Очень частая ошибка — сервис БД или внутреннего API случайно слушает 0.0.0.0. Тогда даже при правильном фаерволе вы повышаете риск ошибок при будущих правках.
Минимизация:
- БД слушает только приватный адрес (или вообще 127.0.0.1, если доступ только через локальный socket/туннель).
- внутренний API слушает только приватный адрес или интерфейс.
- proxy слушает публичный интерфейс, а к приватным портам подключается по приватному IP.
Когда эти слои согласованы, фаервол становится проще и надёжнее.
Проверка: прямые запросы должны падать, запросы через proxy — работать
После настройки сделайте две проверки:
- С публичного хоста попробуйте подключиться напрямую к приватному порту (8080/5432). Должно быть соединение отклонено или таймаут.
- Тот же функционал попробуйте через proxy: обращение к API через 80/443 должно пройти.
Если первый сценарий проходит, а второй тоже проходит — значит, приватный порт оказался доступен не так, как задумано. Тогда нужно возвращаться к правилам и проверять интерфейсы/цепочки.
Сценарий 1.2: приватные сервисы через VPN (WireGuard/OpenVPN)
Иногда нужен доступ к приватным сервисам не через web-proxy, а через VPN. Например, вы хотите админку или внутренний API отдавать только сотрудникам/системам, у которых есть ключи VPN.
Правило фаервола: разрешаем приватные порты только из VPN-интерфейса
С точки зрения фаервола это похоже на «allow только от proxy», только вместо IP proxy источником становится интерфейс VPN (wg0, tun0) или подсеть VPN клиентов.
Концептуально:
- INPUT: разрешить доступ к приватным портам только с vpn-интерфейса или vpn-подсети.
- INPUT: запретить эти порты на публичном интерфейсе.
- INPUT: SSH не обязательно должен быть открытым в интернет — его можно оставить доступным только из VPN или по отдельным доверенным IP.
Такая модель хорошо работает для администрирования: вы не зависите от статических IP сотрудников и можете отзывать доступ ключами.
Не смешивайте VPN-туннель и «внутреннюю сеть» без политики
Есть тонкость: VPN даёт сетевую связность, но это не значит, что все клиенты должны видеть все приватные сервисы. Поэтому:
- ограничивайте доступ не только к сервисам, но и между сегментами, если у вас несколько групп клиентов;
- если VPN clients получают доступ к подсетям приложений, правила фаервола всё равно должны оставаться минимальными.
VPN упрощает логистику доступа, но не заменяет сегментацию и правила.
Сценарий 2: микросервисы на одной VPS и сегментация внутри хоста
На одной VPS часто живут несколько приложений и БД. Даже без нескольких интерфейсов можно построить сегментацию на уровне сети/процессов: через контейнеры, отдельные namespaces или хотя бы через разные подсети контейнеров и правила для них.
Контейнеры и сети: ограничивайте доступ между подсетями
Если вы используете контейнеры, сеть контейнеров часто создаётся автоматически. Тогда фаервол должен понимать:
- какие подсети контейнеров считаются приложениями;
- где находится БД;
- с каких подсетей должны приходить соединения к БД.
Типичная ошибка — разрешить контейнерам «всё ко всем», потому что «так быстрее». Ускорение обычно быстро заканчивается инцидентом, когда один сервис становится точкой входа и получает доступ к внутренним данным.
Network namespaces и межсегментные правила
Если вы не ограничиваетесь контейнерами и используете Linux network namespaces, то сегментация становится ещё ближе к «настоящей сетевой архитектуре». Правила фаервола можно привязать к интерфейсам namespaces или к правилам на границе.
Тут важно не усложнить: начните с понятной схемы «одно направление — один набор правил». И только потом добавляйте более тонкие политики.
Если сервисы на одном хосте: не открывайте приватные порты наружу
Самая простая сегментация внутри VPS — это не публиковать сервисы на публичный интерфейс.
- БД и внутренние API слушают только приватный адрес.
- Внешний интерфейс (публичный) видит только proxy, web и, возможно, мониторинг с ограничениями.
Тогда даже при ошибках в правилах доступа вы получите «меньше поверхности атаки» изначально.
Порталы администрирования: SSH, панели и ограничение доступа
Администрирование — самая частая точка компрометации. Сегментация сети на VPS здесь особенно важна, потому что админка и SSH часто живут рядом с приложениями.
SSH: ограничьте источники и уберите лишнюю открытость
Практическая политика:
- открыть SSH только с доверенных IP или только из VPN;
- если нужен доступ с разных сетей — используйте VPN, а не «широкие allow from».
Также полезно:
- включать rate limiting на попытки подключения (на уровне SSH и/или фаервола);
- блокировать явный перебор (например, через fail2ban, если он у вас уже принят в операционном процессе).
Фаервол должен оставаться источником первичной фильтрации, а fail2ban — дополнительным слоем.
Панели мониторинга и управления: не делайте их “случайно публичными”
Инструменты вроде веб-панелей мониторинга или очередей нередко поднимаются «по умолчанию» на 0.0.0.0. Даже если это «для удобства», они почти всегда оказываются мишенью.
Если панель нужна только админам:
- не публикуйте порт наружу;
- разрешайте доступ только из management-зоны: доверенные адреса или VPN;
- если панель доступна через web (reverse proxy), ограничьте путь и источники на уровне proxy и фаервола.
Сочетание двух уровней делает ошибку менее критичной.
Как спроектировать правила фаервола: рабочий чек-лист
Ниже набор шагов, который помогает быстро собрать правильную модель и избежать типичных перекосов.
- Зафиксируйте список приватных сервисов
- порт, протокол (TCP/UDP), откуда должен приходить трафик (proxy, приложение, VPN-клиенты, batch-задачи).
- где слушает сервис: 127.0.0.1, приватный IP, публичный IP, 0.0.0.0.
- Определите сетевые зоны
- публичная зона (интернет/публичный интерфейс);
- приватная зона (подсети приложений, где живут клиенты приватных сервисов);
- management зона (VPN/доверенные IP).
- Настройте политики по умолчанию
- INPUT/FORWARD по умолчанию DROP.
- Разрешения только явными правилами.
- Добавьте stateful правила
- разрешите пакеты по существующим соединениям;
- новые соединения разрешайте точечно.
- Разведите правила для разных направлений
- INPUT на хост (доступ к сервисам, которые слушают на самой VPS);
- FORWARD для маршрутизируемого/проксируемого трафика между интерфейсами/сетями.
- Начните с минимального набора и только потом расширяйте
- сначала разрешите то, без чего система не поднимется: SSH по нужным источникам и web через proxy;
- затем добавьте приватные порты приложений и БД.
- Добавьте логирование для “лишних” попыток
- логируйте DROP на наиболее чувствительные порты (например, БД, очереди, admin endpoints) с лимитом по частоте.
- Проверьте с внешних и внутренних источников
- с публичной стороны: приватные порты должны быть недоступны;
- с приватной стороны: доступ должен работать;
- проверьте не только функциональность, но и базовые сетевые эффекты (таймауты vs явные отказы — это тоже диагностический сигнал).
Типичные ошибки при сегментации сети на VPS
Эти ошибки встречаются регулярно, потому что кажутся «мелочью», пока не становится поздно.
- Приватный сервис слушает 0.0.0.0
Даже лучший фаервол уязвим к ошибкам в будущих правках. Всегда согласуйте listen-адрес с моделью сегментации.
- Разрешили доступ к приватному порту “из приватной сети” слишком широко
Если в приватной сети много сущностей, вы фактически отдаёте доступ всему сегменту. Разрешайте конкретные адреса/подсети приложений.
- Упустили различие INPUT и FORWARD
Часть сервисов доступна через маршрутизацию, и вы настроили INPUT, но трафик проходит по FORWARD. Итог — правила вроде бы есть, но эффект отсутствует.
- Не учли интерфейсы и адреса источника
При proxy/VPN источником может быть адрес VPN, адрес прокси, или адрес внутреннего интерфейса. Если привязываться к “не тому” источнику, правило не срабатывает или, наоборот, открывает лишнее.
- Слишком агрессивные REJECT вместо DROP
REJECT может быстрее «разоблачать» сервис для сканеров и давать полезную информацию атакующему. DROP обычно тише. Выбор зависит от вашей операционной модели, но осознанно.
- Открыли SSH на интернет “временно”
Даже временное открытие часто живёт месяцами. Если нужен доступ — лучше VPN или строго ограниченные доверенные IP.
- Нет проверки после изменений
Самая дорогая ошибка — поменять фаервол и не протестировать снаружи. Делайте проверку “на два конца”: публичная сторона не должна видеть приватное, приватная — должна.
Проверка, логирование и эксплуатация: как убедиться, что приватные сервисы реально приватные
Сегментация — это не разовая настройка. Нужно закрепить её процессом: тестами, мониторингом и аккуратными обновлениями.
Базовые проверки после настройки правил
- Просмотрите активные правила
- убедитесь, что нужные цепочки не перезаписаны;
- проверьте порядок правил: в nftables/iptables порядок имеет значение, особенно для матчей.
- Тестируйте доступ по схеме “публично/приватно”
- публичный хост: приватные порты должны не отвечать или быть отклонены;
- приватный хост (с правильным источником): соединение должно устанавливаться.
- Тестируйте не только порты, но и протокол
Если сервис использует HTTP поверх TCP, достаточно проверить TCP-подключение и HTTP-ответ. Если UDP — убедитесь, что правила для UDP действительно включены.
Логирование как инструмент диагностики
Логирование полезно, когда оно:
- ограничено по частоте;
- направлено на ключевые политики;
- позволяет быстро понять источник и порт.
Например, если вы логируете DROP для приватного порта, вы увидите, что именно пытается достучаться. Часто это не атака, а кривой health-check или мониторинг с неправильной сети. Тогда проблема решается настройкой источника, а не “расширением доступа”.
Обновления: не сломайте правила при деплое
Самая частая причина поломок — обновления приложений и конфигурации сетевого слоя:
- приложение начинает слушать на 0.0.0.0 вместо приватного адреса;
- reverse proxy меняет Upstream на другой порт/адрес;
- добавляется новый контейнер в подсеть и ему внезапно нужны порты.
Чтобы это не превращалось в хаос:
- храните правила фаервола в конфиге или в инфраструктурном репозитории;
- перед релизом сверяйте сетевые зависимости: какие порты добавляются, откуда к ним должен идти трафик.
Итоги и план внедрения
Сегментация сети на VPS для приватных сервисов — это сочетание архитектуры и дисциплины правил фаервола. Архитектура задаёт границы зон, а фаервол фиксирует минимальные разрешения, чтобы приватные сервисы не становились доступными “по умолчанию”.
Практичный план на один день:
- Составьте список приватных сервисов и их портов, а также источники (proxy/VPN/подсети приложений).
- Проверьте listen-адреса: приватные сервисы не должны слушать публичный интерфейс.
- Включите default deny и stateful-подход.
- Добавьте точечные allow по источникам для приватных портов.
- Сделайте тесты “снаружи и изнутри” и добавьте ограниченное логирование на чувствительные DROP.
Если вы сейчас только начинаете, лучше начать с самой маленькой рабочей модели: один публичный вход через proxy и полностью приватная БД/внутренние API. Дальше расширяйте доступ только тогда, когда это действительно нужно, и фиксируйте изменения правилами фаервола, а не исключениями “на время”.