Ваш VPN сам по себе не делает Cosmos DB приватной

Вы подключаете ноутбук к VNet через VPN, открываете URL учётной записи Cosmos DB, и запрос всё равно уходит через публичный интернет. Туннель выполнил свою работу. Чего он не сделал — не создал частную конечную точку, не опубликовал частную запись DNS и не отключил публичный доступ, потому что это три отдельные изменения учётной записи, а не свойства вашего сетевого подключения. В этом примере используются Azure Cosmos DB для NoSQL, частная конечная точка в VNet и ноутбук, подключённый к этой VNet через VPN, и адрес приложения остаётся неизменным.

Миф: нахождение в VPN делает базу данных частной

Нахождение в VNet означает лишь то, что ваши пакеты могут достигать частных адресов в этой VNet. Это ничего не говорит о том, где разрешается имя учётной записи, и ничего не говорит о том, принимает ли учётная запись публичный трафик.

Частная конечная точка — это отдельный ресурс со своим адресом, своим этапом утверждения и своей DNS-разводкой. Пока её нет и она не утверждена, имя разрешается в публичную конечную точку, и ваш трафик идёт туда независимо от туннеля.

Что на самом деле заставляет имя разрешаться приватно

Сохраните обычную конечную точку учётной записи из SDK, что-то вроде https://ACCOUNT.documents.azure.com. Частный DNS должен разрешать это имя через цепочку Private Link в частные адреса конечной точки. Не заменяйте её числовым URL и не отключайте проверки сертификатов, потому что это меняет проблему DNS на проблему безопасности.

Эти значения специфичны для API NoSQL. Другие API Cosmos не являются взаимозаменяемыми записями в том же примере, а копирование имени дочернего ресурса из другого API создаёт конечную точку, которая никогда не разрешается.

Создайте и утвердите конечную точку через авторизованный рабочий процесс Azure, затем используйте её интеграцию с группой частных зон DNS. Ноутбуку нужен распознаватель, который может отвечать за эту зону, напрямую или через утверждённую пересылку, и маршрут VPN-клиента к каждому соответствующему адресу конечной точки.

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

Режим Gateway и режим Direct не взаимозаменяемы

Режим Gateway отправляет запросы к службе по HTTPS на TCP 443. Поэтому для него работает политика брандмауэра только для 443, и поэтому этот пример выбирает его намеренно.

Режим Direct через Private Link имеет другие требования к подключению, включая более широкий диапазон портов TCP, который перечислен в документации учётной записи. Политику, написанную для режима Gateway, нельзя молча повторно использовать для клиента в режиме Direct, иначе SDK подключится и затем зависнет на первой операции с данными.

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

Отключение публичного доступа — отдельный переключатель

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

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

Доступность — не разрешение

Разрешённая операция SDK с ноутбука в VPN — это приёмочный тест, с обычным URL учётной записи и предполагаемой идентичностью. Доступность через VPN не даёт прав на данные Cosmos; уровень данных проверяет свои собственные роли или ключи.

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

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