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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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