Сегментация сети для VPS: публичная и приватная зоны

Сегментация сети для VPS сводится к простой идее: разные части инфраструктуры должны иметь разный уровень доступности и разные правила обмена. Обычно это оформляют как разделение на публичные и приватные подсети. В публичную подсеть вы кладёте то, что должно отвечать из интернета, а в приватную — то, что не обязано “светиться” наружу.

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

Ниже разберём, как спроектировать публичные и приватные подсети, как настроить маршруты, правила доступа, DNS и выход в интернет. Также соберу типичные ошибки, из‑за которых сегментация “на бумаге” не работает.

Что такое публичная и приватная подсеть в контексте VPS

Публичная подсеть — это сегмент сети, в который направляется входящий трафик из интернета. Обычно экземпляры в публичной подсети имеют публичные IP (или размещаются за публичным балансировщиком). Часто там же держат reverse proxy, bastion-хост и сервисы, которые обязаны быть доступны пользователям.

Приватная подсеть — сегмент сети, доступный только изнутри (из других подсетей, по VPN или через прокси). В приватной подсети экземпляры обычно не имеют публичных адресов. Вход “снаружи” туда не маршрутизируется напрямую, а значит, снижается площадь атаки.

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

Когда нужна сегментация и какие угрозы она снижает

Сегментация особенно полезна, когда у вас есть разные классы систем: веб-интерфейс, внутренние сервисы, базы данных, очереди, кеши, администрирование. Без разделения любой компрометированный компонент легче “разносит” доступ дальше по сети.

Разделение на публичные и приватные подсети помогает снизить риск следующих сценариев:

• Прямое сканирование и атака на базы данных: сервис БД остаётся непубличным и недоступным для интернета.
• Боковое перемещение при компрометации: например, злоумышленник получает доступ к web, но не может подключиться к БД без явных правил.
• Ошибки в конфигурации: порт, который случайно “открыли” для всего мира, не окажется напрямую связан с приватными системами.

Также сегментация облегчает аудит. Когда каждый слой находится в своей подсети, легче собрать список “кто с кем общается” и проверить, что это соответствует требованиям.

Проектирование адресного плана: CIDR, диапазоны и отсутствие пересечений

Начните с адресного плана. Даже если ваш провайдер абстрагирует часть сети, концепция CIDR остаётся: каждой подсети нужен собственный диапазон адресов. Обычно это фиксируют при создании VPC/VNet или при настройке виртуальной сети внутри площадки.

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

Отдельная тема — отсутствие пересечений с другими сетями. Если вы подключаете VPN, роуминг между площадками или делаете site-to-site между облаками, пересечение CIDR может сломать маршрутизацию. Тогда трафик “уходит не туда” или просто не находит маршрут.

Что уточнить перед стартом:

• Сколько VPS потребуется в каждой зоне в ближайшие месяцы.
• Будет ли добавляться приватная подсеть для данных (DB/queue/cache).
• Планируется ли VPN или подключение к корпоративной сети.
• Нужно ли IPv6 или только IPv4.

Рекомендация: выделяйте диапазоны с запасом под рост. Лучше иметь небольшой свободный адресный пул, чем потом мигрировать подсеть и переподнимать правила firewall и маршруты.

Схема маршрутизации: как трафик ходит между публичной и приватной подсетями

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

Обычно схема выглядит так:

• В публичной подсети экземпляры получают маршрут “по умолчанию” к интернет-шлюзу провайдера (или работают через публичный NAT/балансировщик).
• В приватной подсети входящий маршрут из интернета отсутствует. Либо он запрещён правилами провайдера, либо нет подходящего маршрута/привязки.
• Для исходящего трафика из приватной подсети на интернет требуется NAT, egress-gateway или прокси. Иначе приватные узлы не смогут обновляться, скачивать пакеты или ходить к внешним API.

Когда вы настраиваете routing tables (или их эквиваленты у провайдера), держите в голове три направления:

1. Входящий трафик: от пользователя до публичного слоя.
2. Внутренний трафик: от публичного слоя к приватному (например, reverse proxy → app).
3. Исходящий трафик: из приватного слоя наружу через контролируемый выход.

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

Если вы используете VPN для админки или чтобы “поднять” доступ к приватным сервисам, маршрутизация VPN тоже относится к этой же логике. Часто именно там возникают конфликты CIDR, о которых говорили раньше.

Firewall и правила доступа: минимальные порты для веба, админки и БД

Сегментация в реальности держится на правилах допуска трафика. Нельзя ограничиться только тем, что БД находится в приватной подсети. Нужны чёткие inbound/outbound политики.

Хороший старт — модель “разрешаем только то, что нужно”. На практике это обычно означает:

• В публичной подсети открываете только порты для входящих сервисов (например, 80/443 на reverse proxy или load balancer).
• Админские порты (SSH, RDP) не делаете открытыми наружу. Их можно разрешить только с bastion-хоста или из VPN.
• Приватные сервисы принимают подключения строго от тех узлов/подсетей, которым они нужны.

Частый набор правил (примерно, без привязки к конкретной платформе):

• Reverse proxy в публичной подсети: вход 80/443 из интернета; исход на app в приватной подсети (обычно по HTTP/HTTPS или внутреннему порту приложения).
• Приложение в приватной подсети: вход только от reverse proxy; выход на БД по порту БД; при необходимости — до external services через контролируемый egress.
• База данных в приватной подсети: вход только от приложения (и, возможно, от миграционного/админского хоста); отказ всего остального.

Проверьте и egress. Многие архитектуры слабее на исходящем трафике: “вроде всё закрыто”, но приватная система может начать коннектиться куда угодно. Для серверов с доступом к данным разумно ограничивать исходящие соединения по доменам/сетям, если это поддерживается платформой или реализуется через прокси.

Ещё один момент — состояние соединений. Если firewall stateless, нужно помнить о правилах для return traffic. На типичных облачных firewall это обычно автоматически, но при кастомных сетевых агентах обратите внимание на то, как обрабатываются пакеты ответов.

Управление доступом администраторов: bastion, VPN и внутренние каналы

Самая “дорогая” ошибка — открыть SSH на все IP или разрешить доступ к админке из публичной подсети. Даже при сильной парольной политике это остаётся зоной постоянного сканирования и попыток взлома.

Распространённые схемы доступа:

• Bastion-хост (jump server) в публичной подсети
• SSH доступ к bastion ограничен вашим IP (или только по VPN).
• С bastion вы подключаетесь к приватным узлам по приватным адресам.
• На приватных узлах SSH разрешён только с адреса bastion или с подсети bastion.

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

• Туннель/проксирование
• Например, чтобы не открывать SSH напрямую, используете локальные туннели, а внутренние службы доступны через аккуратно настроенный proxy.

Если вы подключаете bastion, продумайте и хранение ключей. Ключи должны быть уникальными, а доступ к ним ограничен. На уровне командной практики полезно разделять роли: кто имеет доступ к production, а кто только к staging.

Мини-чеклист для админки:

• SSH/админские порты доступны только из bastion или VPN.
• На публичных узлах нет “общего” доступа к приватным подсетям без явных правил.
• Логи доступа сохраняются и проверяются (хотя бы на предмет неожиданных IP).

DNS и балансировка: как правильно публиковать сервисы и не раскрывать внутренности

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

Практический подход:

• Внешний DNS (публичная зона):
• A/AAAA записи на публичный балансировщик или reverse proxy.
• Никаких прямых записей на приватные IP (если у провайдера они вообще не маршрутизируются наружу, вы просто получите хаос с отладкой, а при некоторых конфигурациях можете случайно “светить” внутренние адреса).

• Внутренний DNS (private zone или internal naming):
• Имена сервисов приложения и БД резолвятся только внутри приватной сети.
• Reverse proxy и приложение используют внутренние имена, а не публичные.

Балансировка обычно делится по роли:

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

Обратите внимание на TLS. Частая ошибка — использовать сертификаты так, что приватные компоненты начинают проверять “не те” имена или ломается цепочка доверия. Обычно это решают так: внешний reverse proxy держит внешний сертификат, а внутренние сервисы либо используют внутренние сертификаты, либо общаются по внутренним HTTP/HTTPS с корректной проверкой.

Если вы используете сервисы, завязанные на обратные прокси (например, определение реального IP пользователя), убедитесь, что заголовки (X-Forwarded-For и аналоги) прокидываются корректно и не подменяются злоумышленником.

Выход в интернет и egress-контроль: NAT, прокси, ограничения

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

Типовой вариант: NAT gateway или egress-gateway.

• Приватные узлы отправляют трафик в NAT.
• NAT выполняет маршрутизацию в интернет.
• На уровне NAT или правил firewall вы ограничиваете, куда именно разрешено ходить.

Если провайдер поддерживает доменные ограничения, allowlist по адресам назначения или логирование egress — используйте это. Если нет, добавьте хотя бы мониторинг исходящих соединений и алерты на аномалии.

Реальные примеры, где egress-контроль полезен:

• Базы данных и очереди не должны “гулять” по интернету.
• Приложения могут ходить в строго определённые домены (например, провайдеры оплаты или уведомлений), но не в произвольные.
• Админские хосты (если они в приватной зоне) ограничиваются только нужными репозиториями и системными эндпоинтами.

Ещё один практический момент — обновления. Многие команды разрешают приватным серверам свободный egress, чтобы пакеты обновлялись. Это удобно, но со временем превращается в “вечный обход правил”. Лучше заранее определить механизм обновлений и закрепить его: например, через прокси внутри периметра.

Частые ошибки при сегментации сети для VPS

Сегментация обычно ломается не из-за теории, а из-за мелких практических промахов. Ниже список ошибок, которые встречаются чаще всего.

1. База данных в приватной подсети, но inbound разрешён “из всего мира”

Проверьте правила firewall на БД. Иногда ошибка появляется из-за шаблонов политик, которые применили к группе или подсети целиком.

1. Открытый SSH в публичной подсети

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

1. Пересечение CIDR при подключении VPN или нескольких сетей

Симптомы: “не пингуется”, “маршрут не найден”, “коннект идёт только в одном направлении”. Лучше один раз тщательно проверить диапазоны перед подключением.

1. Путают направления трафика при правилах

Например, разрешили исходящий порт, но забыли inbound на принимающей стороне. Итог — соединения таймаутятся, а команда тратит время на поиск “плохого” сервиса.

1. Нет контроля исходящего трафика из приватных узлов

Компонент с доступом к данным может начать обращаться к внешним доменам и утекать. Сегментация снижает риск, но не заменяет нормальные политики egress.

1. Полагаются только на “приватность адреса”

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

1. Непроверенная связность после изменений

Добавили сервис — и забыли обновить firewall. Или изменили маршруты NAT — и приватная подсеть перестала скачивать обновления. Сегментация требует процедур проверки.

Пошаговый чек-лист внедрения

Если вы строите сегментацию с нуля, удобнее идти по шагам и фиксировать решения. Вот практичный чек-лист.

1. Определите доверительные границы

Разделите системы на роли: публичный фронт, внутреннее приложение, данные, администрирование, мониторинг.

1. Спроектируйте подсети и адресный план

Выберите CIDR для публичной и приватной подсети. Убедитесь, что диапазоны не пересекаются с VPN и другими сетями.

1. Настройте маршрутизацию

Проверьте, что приватная подсеть не получает прямого входа из интернета. Для исходящего трафика добавьте контролируемый путь (NAT/egress-gateway).

1. Разведите правила firewall по ролям

Открывайте публичные порты только на публичном слое. Для приватных сервисов разрешайте inbound только от конкретных источников (других подсетей или хостов).

1. Закройте администрирование

Выберите bastion или VPN. На приватных узлах разрешите доступ только от bastion/VPN.

1. Настройте DNS

Публичные имена ведите на балансировщик/reverse proxy. Внутренние имена — только в приватной сети.

1. Установите egress-ограничения или хотя бы наблюдение

Определите, какие домены/сети должны быть доступны. Минимум — логирование исходящих подключений.

1. Протестируйте связность в обе стороны

Проверьте сценарии: пользователь → reverse proxy → приложение → БД. Затем проверьте, что “лишние” подключения не работают.

1. Документируйте правила

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

1. Введите регламент изменений

Любое добавление сервиса сопровождайте обновлением firewall, DNS и тестом connectivity.

Практический пример: двухуровневое приложение с базой в приватной подсети

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

Компоненты:

• Reverse proxy / load balancer в публичной подсети.
• App server в приватной подсети.
• Database server в приватной подсети.
• Bastion или VPN для администрирования.

План размещения:

• Reverse proxy: публичная подсеть, публичный IP.
• App: приватная подсеть, только внутренние адреса.
• DB: приватная подсеть, только внутренние адреса.
• Bastion: публичная подсеть, доступ только с вашего IP/VPN.

Правила доступа по потокам:

• Из интернета разрешены только 80/443 на reverse proxy.
• Reverse proxy → App: разрешён порт приложения (например, 8080 или внутренний HTTPS).
• App → DB: разрешён порт БД (например, 5432 для PostgreSQL или 3306 для MySQL).
• Вход на App разрешён только от reverse proxy (или от приватного балансировщика).
• Вход на DB разрешён только от App и, если нужно, от миграционного хоста.

Администрирование:

• SSH на bastion: разрешён только с вашего IP или из VPN.
• SSH на App/DB: разрешён только с bastion (по приватному адресу) или из VPN.
• Обновления системы и сервисов делаются с приватных узлов через контролируемый egress.

Выход в интернет:

• Приватным узлам (App и DB, если требуется) доступен только нужный egress. Если DB не должна ходить наружу, egress для неё можно запретить полностью.
• App ходит наружу только к репозиториям пакетов и внешним API, которые нужны приложению.

Как это тестировать:

• Проверить, что попытка подключения к DB с внешнего IP не проходит.
• Проверить, что приложение открывает соединение к DB.
• Проверить, что inbound на App/DB недоступен с публичного интернета.
• Проверить, что исходящие запросы из приватного слоя идут через NAT/egress-gateway и логируются.

Такой каркас масштабируется. Если вы добавите очередь, кеш или отдельный сервис аналитики, вы просто расширяете приватную зону и снова прописываете “кто с кем” по минимальным портам.

Как проверить результат и поддерживать сегментацию со временем

Сегментация — это не разовая настройка. Инфраструктура меняется: появляются новые сервисы, меняются порты, обновляются сертификаты, подключаются интеграции. Без проверки сегментация со временем “дрейфует” в сторону хаоса.

Минимальный набор регулярных проверок:

• Периодическая проверка правил firewall

Убедитесь, что новые security group/ACL не начали допускать лишний трафик.

• Проверка исходящего трафика с приватных узлов

Смотрите, какие назначения появляются в логах. Если БД вдруг начинает ходить наружу, это сигнал.

• Тестирование связности при релизах

После деплоя проверьте end-to-end: внешний запрос до UI, дальше до приложения и до БД.

• Проверка DNS-регистраций

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

• Инвентаризация портов и зависимостей

Составьте список “открыто на вход” и “разрешено между подсетями”. Это сильно ускоряет аудит.

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

Если у вас несколько VPS и разные подсети живут на одной площадке, внимательно смотрите на то, как провайдер реализует security groups, route tables и приватные интерфейсы. У разных платформ детали отличаются, но принципы одинаковые: граница доверия, минимальные порты, контролируемый egress и непрямой доступ к данным.

Итог: как сделать сегментацию сети для VPS рабочей, а не декоративной

Сегментация сети для VPS с публичные и приватные подсети становится эффективной, когда соблюдены четыре условия: адресный план понятен и без пересечений, маршрутизация не даёт приватной зоне “входить” снаружи, firewall разрешает только нужные потоки, а администрирование вынесено через bastion или VPN.

Если сейчас у вас все сервисы в одной зоне, начните с малого: перенесите БД и внутренние сервисы в приватную подсеть и оставьте наружу только reverse proxy. После этого проверьте, что доступ ломается именно там, где вы его ожидаете, и что приложение продолжает работать.

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