Сеть в Azure — это не «галочки где-то в портале», а то, что определяет главный вопрос: кто до кого может достучаться. От неё зависит и безопасность (не смотрит ли база наружу?), и работоспособность (видит ли приложение базу?). Хорошая новость: вся модель собирается из нескольких понятных кирпичиков. Если базовые понятия облака ещё не на руках, начните с основ Azure.

вход снаружи интернет Application Gateway, публичный IP приложение, внутренний IP база, приватная точка выход наружу приложение NAT Gateway интернет к сервису Azure приложение приватная зона DNS Private Link хранилище секретов

Три пути и у каждого свой узел: снаружи пускает только шлюз с публичным адресом, наружу выпускает NAT Gateway, а к сервисам Azure ходят по приватной точке, которая работает только вместе с приватной зоной DNS.

Обязательно

Virtual Network и подсети

Virtual Network (VNet) — ваша изолированная виртуальная сеть внутри Azure, что-то вроде арендованного этажа в дата-центре: чужой на него не попадёт, а вы решаете, какие двери открыть наружу. Аналог VPC в AWS. У VNet свой диапазон адресов — CIDR вида 10.0.0.0/16 (число после слэша говорит, сколько адресов: /16 — около 65 тысяч).

VNet разрезают на подсети (subnets) — куски адресного пространства под разные роли: подсеть под приложения, под базы, под шлюзы. В отличие от некоторых облаков, подсеть Azure не привязана к одной зоне: ресурсы внутри неё можно разместить в разных зонах доступности ради надёжности.

az network vnet create --name my-vnet --resource-group my-rg \
  --address-prefixes 10.0.0.0/16 --subnet-name app --subnet-prefixes 10.0.1.0/24

Ресурсы одной VNet видят друг друга по внутренним адресам. Разные VNet связывают через peering — прямое соединение (важно: оно не транзитивное, каждую пару соединяют отдельно).

Сколько адресов забирает Azure

Практическая арифметика, из-за которой подсеть иногда «не создаётся» или заканчивается раньше ожидаемого.

Из каждой подсети Azure забирает пять адресов: первый — адрес сети, следующие три — служебные (шлюз и внутренние нужды платформы), последний — широковещательный. То есть в подсети /24 (256 адресов) для ваших ресурсов остаётся 251, а не 254, как в обычной сети.

Минимальный размер подсети — /29 (восемь адресов, из которых полезны три). Практически это годится только для чего-то единичного; рабочий минимум — /28, а для подсети под узлы кластера или под интеграцию приложений берут с большим запасом.

Отсюда две типичные истории. Первая: кластер Kubernetes, где сетевой режим выдаёт адрес каждому поду, съедает /24 на несколько десятков узлов — размер подсети под такой кластер считают заранее по формуле «узлы × поды на узел». Вторая: подсети под специальные сервисы имеют свои требования к размеру (шлюз приложений, межсетевой экран, шлюз виртуальной сети), и их нельзя уменьшить потом — а расширить подсеть, в которой уже есть ресурсы, можно не всегда.

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

Публичный и внутренний IP

Деление на «доступно снаружи» и «только внутри» проходит по ресурсу — есть ли у него публичный IP.

  • Только внутренний IP — ресурс виден лишь внутри VNet. Сюда попадают приложения, базы, кэши: всё, до чего снаружи не должно быть доступа.
  • Публичный IP — ресурс доступен из интернета. Его выдают точкам входа: балансировщику, иногда bastion-хосту для входа.

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

NAT Gateway: выход в интернет

Часто внутреннему сервису нужен исходящий доступ — скачать обновление, дёрнуть чужой API. Входящий при этом не нужен. Для этого служит NAT Gateway: работает как односторонний турникет — изнутри наружу можно, снаружи внутрь по своей инициативе нельзя. Его привязывают к подсети, и ресурсы без публичного IP получают выход в интернет, оставаясь невидимыми снаружи.

Две вещи про него стоит знать заранее.

Первая: раньше машина без публичного адреса всё равно как-то выходила в интернет — Azure давал выход «по умолчанию», без всякой настройки. Этот подарок Microsoft закрывает: с 30 сентября 2025 года новые машины его не получают, и выход наружу надо назначать явно — NAT Gateway, правило балансировщика или публичный адрес. Уже работающие машины не трогали, поэтому и бывают разговоры вида «у коллеги на старом стенде всё работало, а у меня зависает»: стенд просто старше этой даты.

Вторая: обычный NAT Gateway живёт в одной зоне доступности. Если сервис раскидан по зонам, а шлюз один, то падение его зоны уносит выход в интернет у всех — включая те зоны, которые сами живы. Поэтому в зональной схеме делают по подсети и по шлюзу на зону; в свежем поколении шлюза (SKU StandardV2) появилась и зонально устойчивая разновидность, которая размазана по всем зонам сразу.

Network Security Group

Машина поднята, приложение слушает порт, а снаружи connection timed out — почти всегда это правило NSG. Когда трафик доехал до ресурса, его фильтруют, и основной инструмент здесь — Network Security Group (NSG): набор правил «кто и на какой порт может подключиться». Особенности:

  • NSG stateful («с памятью»): разрешили входящее соединение — ответ уйдёт автоматически;
  • у каждого правила есть номер-приоритет от 100 до 4096, и правила перебираются от меньшего номера к большему: 100 раньше 200. Как только трафик совпал с правилом, перебор прекращается — остальные правила не смотрят вообще. Поэтому «запретить всё» с номером 200 не спасёт, если выше стоит разрешающее правило с номером 100;
  • NSG вешают на подсеть или на сетевой интерфейс конкретной машины.

В каждом NSG уже есть правила по умолчанию — их не видно в вашем списке, но они работают и объясняют многое. На входе: разрешено всё изнутри виртуальной сети, разрешён служебный трафик от балансировщика, а всё остальное запрещено. На выходе: разрешено в свою сеть и разрешено в интернет, остальное запрещено. У них самые большие номера (65000 и выше), то есть ваши правила всегда разбираются первыми. Отсюда и ответы на два вечных вопроса: «почему внутри сети всё видно, хотя я ничего не разрешал» — из-за входящего правила про виртуальную сеть; «почему наружу ходить можно, а снаружи ко мне нет» — из-за пары исходящее-разрешено / входящее-запрещено. Удалить эти правила нельзя, но можно перекрыть своими, с меньшим номером.

Хороший приём — вместо жёстких IP-адресов использовать теги сервисов (service tags) и группы безопасности приложений (application security groups), чтобы правило «приложению можно в базу на порт 5432» не ломалось при смене адресов.

az network nsg rule create --resource-group my-rg --nsg-name db-nsg \
  --name allow-app --priority 100 --access Allow --protocol Tcp \
  --destination-port-ranges 5432 --source-address-prefixes 10.0.1.0/24

Разрешение имён: почему приватная точка не работает

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

Разберём механику. Когда вы создаёте приватную точку входа (Private Endpoint) к базе, сервис получает внутренний адрес в вашей подсети. Но приложение обращается к базе по имени вида orders.postgres.database.azure.com, а это имя в публичной системе имён по-прежнему указывает на публичный адрес. Никто его не подменяет сам.

Подменяет его приватная зона DNS — служебная зона с особым именем, которое зависит от сервиса:

СервисИмя приватной зоны
PostgreSQL (гибкий сервер)privatelink.postgres.database.azure.com
Хранилище объектов (блобы)privatelink.blob.core.windows.net
Хранилище секретовprivatelink.vaultcore.azure.net
Реестр образовprivatelink.azurecr.io

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

az network private-dns zone create -g rg-net -n privatelink.postgres.database.azure.com
az network private-dns link vnet create -g rg-net -z privatelink.postgres.database.azure.com \
  -n link-vnet-app -v vnet-app -e false

Хорошая новость: при создании точки входа из портала эту зону предлагают создать и связать автоматически, и обычно так и делают. Плохая: при создании кодом это отдельные ресурсы, и их легко забыть — а симптом будет выглядеть как проблема сети.

Порядок разбора, когда приватное подключение не работает:

  1. Что возвращает имя изнутри сети (nslookup из машины в этой сети): публичный адрес — дело в зоне; внутренний — идём дальше.
  2. Связана ли зона с вашей сетью — одна зона может обслуживать несколько сетей, и связь надо создать с каждой.
  3. Есть ли запись для вашей точки в зоне.
  4. Разрешает ли группа безопасности трафик до внутреннего адреса на нужный порт.
  5. Не закрыт ли публичный доступ там, где приложение всё-таки ходит публично (например, из конвейера).

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

Private Link (приватные эндпоинты) позволяют дотянуться до сервисов Azure — базы, Blob Storage, Key Vault — по приватной сети, не выходя в интернет вообще. Трафик не покидает сеть Azure. Это почти всегда правильный ответ на вопрос «как внутреннему сервису безопасно достучаться до управляемого сервиса».

Рядом живёт похожий механизм, с которым Private Link постоянно путают, — конечные точки служб (service endpoints). Задача та же, решение другое: приватный эндпоинт даёт сервису адрес внутри вашей подсети, и обращаются к нему как к своему ресурсу; конечная точка службы адреса не даёт, она лишь заворачивает трафик к публичному адресу сервиса по внутренней магистрали и позволяет сервису пустить только вашу подсеть. Практическая разница проста: приватные эндпоинты тарифицируются (за сам эндпоинт и за трафик), конечные точки служб бесплатны; зато приватный эндпоинт виден и из связанных сетей — например, из офисной через VPN, — а конечная точка работает только из своей подсети.

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

  • Load Balancer — распределяет на уровне соединений (L4), быстрый и простой;
  • Application Gateway — работает на уровне HTTP (L7): маршрутизация по путям и хостам, терминация TLS, проверки здоровья; часто он и стоит публичной точкой входа, а приложения прячутся во внутренней сети.

Где это применяется

Сеть — фундамент, на котором стоит всё остальное. Балансировщик с публичным IP, приложение и база с внутренними адресами, NAT Gateway для исходящих вызовов, NSG, описывающие «кто до кого» — эту схему вы встретите почти в любом боевом развёртывании, продублированную по зонам доступности.

Типичные ошибки новичков:

  • дают базе публичный IP — она доступна из интернета, прямая дыра;
  • ждут выхода наружу без NAT Gateway — исходящие вызовы зависают;
  • путают приоритеты правил NSG — более общее правило перекрывает частное;
  • прописывают IP-адреса вместо тегов и групп — правила ломаются при смене адресов.
Дополнительно: при первом чтении можно пропустить

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

Связывание двух виртуальных сетей (peering) настраивается двумя кликами и упирается в одно требование, которое нельзя обойти: адресные пространства не должны пересекаться. Две сети 10.0.0.0/16 связать нельзя вообще никак — маршрутизатор не сможет решить, куда отправлять пакет. Сообщение об ошибке при этом внятное, а вот переразметка уже работающей сети — это переезд всех ресурсов.

Отсюда практика, которую стоит завести до первой сети: план адресов на всю компанию. Один диапазон на каждую среду и регион, записанный в общем документе: скажем, 10.10.0.0/16 для боевого контура в Европе, 10.20.0.0/16 для тестового, 10.30.0.0/16 для второго региона. Это десять минут работы один раз и снятая проблема на годы.

Второе свойство связывания, о котором узнают позже: оно не транзитивно. Сеть A видит B, B видит C — A не видит C. Для трёх сетей это ещё терпимо, дальше растёт паутина связей, и появляется схема «звезда»: центральная сеть с общими сервисами и связи от неё к остальным, а транзит через центр включают отдельно (маршрутами и межсетевым экраном).

Связь с собственной инфраструктурой

Отдельная задача: соединить сеть в облаке с сетью в офисе или в своём дата-центре. Способов два.

Шлюз виртуальной сети (VPN Gateway) — зашифрованный туннель через интернет. Два вида: «сеть к сети» (постоянный туннель до вашего оборудования) и «точка к сети» (подключение с ноутбука отдельного сотрудника). Шлюз — это отдельный ресурс, он живёт в специальной подсети GatewaySubnet, тарифицируется почасово и имеет разные уровни по пропускной способности. Плюс: включается за час, работает поверх обычного интернета. Минус: задержка и пропускная способность зависят от интернета, и это чувствуется на обмене с базой.

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

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

Глубже: межсетевой экран и группы безопасности: в чём разницарасширенное

Группы безопасности (NSG) закрывают базовую задачу — «кто до кого может дотянуться по адресу и порту». Есть второй инструмент, Azure Firewall, и его роль стоит развести с группами, иначе непонятно, зачем платить за отдельный сервис.

Группа безопасности — это список правил на подсети или сетевой карте: адрес, порт, протокол, разрешить или запретить. Она бесплатна, работает на уровне платформы и помнит состояние соединения (ответ на разрешённый запрос проходит автоматически). Чего она не умеет: фильтровать по именам (разрешить github.com и запретить остальное), разбирать содержимое, вести журнал попыток в удобном виде, работать как единая точка выхода для нескольких сетей.

Межсетевой экран — отдельный управляемый сервис в своей подсети (AzureFirewallSubnet, минимум /26). Он умеет:

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

Цена — почасовая плата за сам сервис плюс плата за обработанный трафик, и она заметна: это не то, что включают «на всякий случай» в маленьком проекте.

Практическая раскладка: группы безопасности — всегда (это базовая гигиена, и они бесплатны). Межсетевой экран — когда появляется требование «наружу только к разрешённым именам», когда сетей несколько и нужна единая точка выхода, или когда журнал сетевых решений требует аудит. Для одного приложения с базой достаточно групп безопасности плюс приватных точек входа, чтобы трафик к сервисам Azure вообще не выходил в интернет.

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

О шлюзе приложений (Application Gateway) стоит сказать две вещи, которые выясняются при первом создании.

Ему нужна своя подсеть. Не общая с приложением, а отдельная, и только для него: платформа разворачивает там свои экземпляры. Размер — минимум /28, а с запасом на масштабирование берут /26. Это первое, обо что спотыкается развёртывание из кода: подсети нет, и создание падает.

Фильтр веб-запросов — отдельная возможность. Защита от типовых атак на приложение (внедрение запросов, межсайтовые сценарии) включается выбором уровня с этим фильтром (WAF v2), и это другая цена. То есть «у нас есть шлюз приложений» не означает «у нас есть защита приложения» — это два разных решения, и второе принимают осознанно.

Рядом полезно помнить, что балансировщиков в Azure несколько и они для разного: обычный балансировщик работает на уровне соединений (быстрый, дешёвый, не понимает HTTP), шлюз приложений — на уровне запросов (маршрутизация по пути и имени, завершение шифрования, фильтр), а глобальный распределитель трафика (Front Door) стоит перед всем этим на границе сети Azure и раздаёт трафик между регионами.

Коротко

  • VNet это ваш этаж в дата-центре с непересекающимся диапазоном; подсеть не привязана к зоне, а peering между сетями не транзитивен.
  • Azure забирает пять адресов из каждой подсети, минимум /29, рабочий /28; кластер с адресом на каждый под съедает /24 быстро, поэтому сеть берут /16 и оставляют зазоры между подсетями.
  • Доступ снаружи определяется публичным IP: он есть только у балансировщика и точек входа, приложения и базы живут с внутренними адресами.
  • Наружу приватные ресурсы ходят через NAT Gateway: с осени 2025 выхода «по умолчанию» у новых машин нет, а зональный шлюз ставят по одному на зону.
  • NSG с памятью, правила перебираются от меньшего приоритета к большему до первого совпадения, правила по умолчанию невидимы, но действуют; вместо адресов пишут теги сервисов и группы безопасности приложений.
  • Приватная точка не работает без приватной зоны DNS: имя изнутри сети должно возвращать внутренний адрес; разбирают по порядку nslookup, связь зоны с сетью, запись, NSG, публичный доступ.
  • Private Link даёт сервису адрес в вашей подсети, конечные точки служб только пускают подсеть к публичному адресу; Load Balancer работает на соединениях, Application Gateway на HTTP и требует свою подсеть.
  • Peering требует плана адресов на всю компанию и схемы «звезда» при росте; с офисом соединяют VPN Gateway, а ExpressRoute берут, когда туннеля не хватает.
  • NSG всегда и бесплатно, Azure Firewall за деньги ради правил по именам и единой точки выхода; WAF у шлюза приложений это отдельный уровень и цена.

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