Сеть в облаке: частная сеть, подсети, файрвол и выход наружу

← назад к разделу

Базу подняли, машина её видит, а приложение с соседней машины — нет: «connection timed out». Порт открыт, база слушает, всё создано. Виноват файрвол на ресурсе, в котором нет разрешающего правила, — и это самая частая сетевая проблема в облаке. Вторая: машина без публичного адреса не может скачать обновления, потому что выходить в интернет ей просто не через что.

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

Своя сеть на проект

Облако не даёт проектам делить одну сеть. Каждый получает частную сеть — изолированное адресное пространство, в котором живут его машины, базы и балансировщики. Провайдеры называют её по-разному, суть одна: внутри ничего чужого, снаружи ничего не видно.

У сети есть диапазон адресов, например 10.0.0.0/16 — 65 тысяч адресов. Выбирать его надо заранее и не как у соседей: две сети с пересекающимися диапазонами потом невозможно соединить, потому что маршрутизатор не поймёт, куда слать пакет с адресом, который есть в обеих. Компании держат план адресов на все проекты, чтобы такого не случалось.

Подсети, зоны и два вида адресов

Сеть режут на подсети, и каждая подсеть привязана к одной зоне доступности. Хотите копии сервиса в трёх зонах — нужны подсети в трёх зонах. Подсети бывают двух видов, и различие в одном: есть ли у неё маршрут в интернет-шлюз. Публичная подсеть такой маршрут имеет, и её ресурсы могут получить публичный адрес; приватная — нет, и её ресурсы снаружи недостижимы в принципе.

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

Файрвол на ресурсе

Даже внутри своей сети трафик до ресурса фильтруют. Основной инструмент — группа безопасности: набор правил «кому и на какой порт можно», привязанный к машине, узлу или базе. У неё два свойства, которые надо знать. Она помнит соединения: разрешили входящее — ответ на него уйдёт сам, отдельного правила не нужно. И в ней только разрешающие правила: чего нет в списке, то запрещено, а пустая группа означает «запретить всё» — та самая «connection timed out» у только что созданной базы.

Правила пишут не адресами, а ссылками на другие группы: «база принимает трафик на порт 5432 от группы приложения». Адреса машин меняются, группы — нет, и правило продолжает работать после любого перезапуска.

Выход наружу и вход внутрь

Машина в приватной подсети должна скачать пакет или позвонить во внешний API, а публичного адреса у неё нет. Для этого в публичной подсети ставят NAT-шлюз: он выпускает исходящие соединения от имени своего публичного адреса и не пускает входящие. Шлюз сам по себе ничего не делает — в таблице маршрутов приватной подсети нужна запись «весь внешний трафик через NAT». Забытый маршрут — вторая по частоте причина «не выходит наружу».

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

Глубже: как соединить две сетирасширенное

Проект вырос, сервисов стало несколько, и у каждого своя сеть. Или база живёт в сети одной команды, а сервис — другой. Сети соединяют пирингом: две частные сети связывают напрямую, и ресурсы видят друг друга по внутренним адресам, как в одной сети. Условие одно — диапазоны не должны пересекаться, поэтому план адресов и заводят заранее.

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

Глубже: приватный доступ к сервисам провайдерарасширенное

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

Глубже: вход снаружи: DNS, сертификаты, сеть доставки и WAFрасширенное

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

DNS. Зону домена держат у провайдера (Route 53, Azure DNS, Cloud DNS) или у регистратора, и запись на балансировщик делают не адресом, а псевдонимом на его имя: адреса балансировщика меняются, псевдоним провайдер обновляет сам. Управляемый DNS умеет и переключение по проверке здоровья: пропал ответ от основной площадки, запись указывает на резервную, и это самый дешёвый слой восстановления после отказа региона, о котором говорит статья про отказоустойчивость. TTL записи держат коротким на время переездов и обычным в остальное время.

Сертификаты. TLS терминируется на балансировщике или на сети доставки, и сертификат выпускает сам провайдер (ACM, управляемые сертификаты у Azure и GCP) после подтверждения владения доменом через запись DNS; продление автоматическое, пока запись на месте. Внутрь, до приложения, трафик идёт по внутренней сети либо открытым, либо с внутренним сертификатом, и это решение про доверие к сети, а не про экономию.

Сеть доставки. Перед балансировщиком ставят CDN (CloudFront, Front Door, Cloud CDN): она отдаёт статику с узлов рядом с пользователем, кэширует ответы API по правилам из заголовков, снижает исходящий трафик из региона и принимает на себя первый удар. Источник закрывают от прямого доступа, чтобы ходить в него можно было только через CDN, иначе защита ниже обходится адресом балансировщика.

WAF и защита от атак. Атаки сетевого уровня (потоп пакетами) крупные провайдеры гасят сами, без настройки, это входит в цену балансировщика и CDN. Атаки прикладного уровня (миллион запросов к дорогой ручке, перебор паролей, инъекции) отсекает WAF на балансировщике или CDN: управляемые наборы правил по известным атакам, лимит запросов с адреса, блокировка по стране, правила против ботов. WAF стоит по правилам и по миллионам запросов и даёт ложные срабатывания, поэтому его включают сначала в режиме наблюдения. Он не заменяет ограничение частоты в приложении: WAF защищает вход, лимитер защищает бизнес-операции по пользователю, о чём статья про паттерны отказоустойчивости.

Цепочка в итоге: DNS с псевдонимом → CDN с WAF и сертификатом → балансировщик с закрытым источником → приложение по внутренним адресам. Каждое звено это отдельная строка в счёте и отдельная настройка в коде инфраструктуры.

Глубже: связь со своей инфраструктурой: VPN и выделенное подключениерасширенное

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

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

Выделенное подключение. Физическая линия от вашего дата-центра до точки присутствия провайдера (Direct Connect, ExpressRoute, Interconnect): гигабиты, стабильная задержка, трафик дешевле, чем через интернет, зато недели на подключение и сотни долларов в месяц за порт. Берут, когда через границу идут терабайты или когда задержка между базой в дата-центре и сервисом в облаке определяет отклик продукта. VPN при этом оставляют как запасной путь.

Что общего у обоих: диапазоны адресов не должны пересекаться (та же грабля, что у пиринга), маршруты в обе стороны нужно объявить, файрволы с обеих сторон должны пропускать, а DNS должен уметь разрешать имена соседней стороны, иначе сеть связана, а по именам никто никого не находит. И гибридный сценарий это временное состояние с датой окончания или осознанная архитектура с двумя площадками; без решения он превращается в самое дорогое из обоих миров.

Глубже: «не соединяется» и «нет доступа»: порядок проверкирасширенное

Списки типичных ошибок полезны, когда уже знаешь, где искать. Когда сервис в облаке «не видит базу» или отвечает «нет прав», нужен порядок, и он у всех провайдеров одинаковый: сеть, потом права, потом приложение. В обратном порядке теряют часы.

Сеть, шесть вопросов подряд. Разрешается ли имя, и в какой адрес: внутренний или публичный. Есть ли маршрут из подсети источника к подсети цели, включая маршрут через NAT для выхода наружу и через пиринг для соседней сети. Пропускает ли файрвол на цели входящий трафик с адреса или группы источника на этот порт, и пропускает ли файрвол источника исходящий (у части провайдеров исходящий закрыт по умолчанию). Слушает ли процесс на цели на всех интерфейсах, а не только на localhost, и на том ли порту. Есть ли у цели сетевой список доступа на уровне подсети, о котором забывают, потому что он редко нужен. И журнал потоков сети (Flow Logs и их аналоги), который показывает, дошёл ли пакет и кто его отверг; у провайдеров есть и анализаторы достижимости, которые проходят эти шесть вопросов за вас по описанию «от A к B на порт N».

Права, по тексту отказа. Сообщение об отказе называет три вещи: кто просил (и это часто не тот, кого вы думали: другой сервисный аккаунт, роль по умолчанию, ключ разработчика), какое действие и на каком ресурсе. Проверяют по порядку: у субъекта есть роль с этим действием; на ресурсе нет политики, которая запрещает; выше нет ограничений организации или границ прав, которые режут всё; для ключа шифрования есть отдельное разрешение на ключ. Журнал действий (CloudTrail и аналоги) хранит каждый отказ с полным контекстом, и по нему видно настоящего субъекта; изменения прав применяются с задержкой в минуты, и повтор через минуту это тоже шаг проверки.

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

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

Коротко

• У каждого проекта своя изолированная частная сеть со своим диапазоном адресов; трафик между двумя сетями не ходит, пока это не разрешили.
• Сеть нарезают на подсети, и подсеть привязана к зоне доступности; публичная подсеть смотрит в интернет через шлюз, приватная — нет.
• Публичный адрес получают только точки входа; приложение и база живут по внутренним адресам.
• Файрвол стоит на каждом ресурсе, помнит соединения и содержит только разрешающие правила: всё, что не разрешено, запрещено.
• Машины без публичного адреса выходят в интернет через NAT-шлюз, для которого нужен маршрут в таблице подсети.
• Диапазон адресов выбирают заранее и без пересечений: две сети с одним диапазоном потом не соединить.
• Вход снаружи это цепочка: DNS с псевдонимом и переключением по здоровью, управляемый сертификат на балансировщике или CDN, сеть доставки с закрытым источником, WAF сначала в режиме наблюдения.
• Со своим дата-центром облако соединяют VPN-шлюзом за час или выделенной линией за недели; в обоих случаях непересекающиеся диапазоны, маршруты, файрволы и DNS в обе стороны.
• «Не соединяется» разбирают по порядку: сеть (имя, маршрут, файрволы, кто слушает, журнал потоков), права (кто, какое действие, на каком ресурсе, по тексту отказа и журналу), приложение последним.

Что почитать дальше

• Регионы и зоны — почему подсеть привязана к зоне и что из этого следует.
• Сеть в AWS — та же модель с командами и разбором security groups.
• Сетевой фундамент — IP, порты и DNS, на которых всё это стоит.