Частная конечная точка, то же имя сервера: строки подключения Azure SQL
Private Link меняет место, где разрешается имя сервера, а не само имя. Сохраняйте логическое имя узла и давайте VPN-клиентам частный ответ DNS.
Private Link меняет то, куда приходит подключение, а не то, как называется подключение. Для Azure SQL Database это различие и есть весь дизайн: логический сервер сохраняет своё имя, а частная конечная точка предоставляет сетевую запись, в которую разрешается имя. Замена имени IP-адресом — единственное изменение, которое одновременно ломает TLS, учётные данные и инструменты. Две строки подключения могут выглядеть эквивалентными и вести себя совершенно по-разному.
Сохраните orders-db.database.windows.net и дайте клиенту частный ответ для него.
У имени и адреса разные задачи
Имя идентифицирует службу SQL, и именно этого ожидают сертификат и вход. Частный адрес предоставляет сетевую запись внутри подключённой виртуальной сети. Смешение одного с другим даёт подключение, которое до чего-то доходит и ни с чем не аутентифицируется.
Рекомендации Microsoft для Azure SQL требуют от клиентов обычного имени сервера. Прямой IP, как и имя с префиксом privatelink, не является взаимозаменяемой целью входа. Инструменты, принимающие IP, примут его и затем потерпят неудачу на TLS или при аутентификации, что скрывает настоящую ошибку. Эти сбои читаются как проблемы с учётными данными, пока не посмотришь на имя узла в сообщении об ошибке.
Что на самом деле меняет частная зона
Частная зона DNS записывает один адрес для сервера в пространстве имён privatelink, и зона связана с виртуальной сетью, которая должна её использовать. Разрешение перемещается; строка подключения — нет. Форма ниже — иллюстрация, а не запись для вставки в публичную зону.
Application name: orders-db.database.windows.net
Private DNS zone: privatelink.database.windows.net
Resolved private entry: the approved private endpoint address
Поддерживайте эту запись и её привязку к зоне как инфраструктуру, с владельцем и датой проверки.
Две зоны с одинаковым происхождением и разными ответами — нормальное конечное состояние, а не конфликт. Публичные клиенты сохраняют публичный ответ, а частные клиенты получают адрес конечной точки. Режим отказа, за которым нужно следить, — частичное распространение частного представления, когда одна подсеть разрешается приватно, а другая тихо нет.
Клиентам вне Azure нужен путь в эту зону
VPN-клиент находится вне распознавателя Azure, поэтому частная зона должна быть достижима с гибридного пути. Пересылающий DNS Azure или Azure DNS Private Resolver могут обслуживать запросы, приходящие через эту сеть. Рекомендация Microsoft — пересылать соответствующую публичную зону службы через такую схему, а не предполагать, что клиенты запрашивают имя privatelink напрямую. Клиенты, которые не могут разрешить частный ответ, тихо возвращаются к публичному.
Держите область пересылки осознанной, потому что замена используемой публичной зоны ломает имена, которых в замене нет.
Обеспечивайте в порядке, который сохраняет идентичность фиксированной
У шагов отдельные владельцы: создайте и утвердите конечную точку, обеспечьте маршрут VPN, интегрируйте частный DNS, затем настройте клиент с его обычным именем сервера. Выполнение DNS до маршрута даёт тайм-ауты, которые выглядят как сбои DNS. Выполнение клиента последним держит в движении одну переменную за раз. У каждого шага есть наблюдаемый результат, поэтому ни один не нужно проверять догадками.
Подключённый значок VPN сам по себе не выбирает частное назначение.
Что частная конечная точка не отключает
Создание частной конечной точки не отключает автоматически публичный доступ к логическому серверу. Это отдельное решение о развёртывании, и оно уместно после того, как предполагаемые частные клиенты подтверждены как работающие. Сохраняйте путь восстановления и учитывайте приложения, которые всё ещё используют публичный вход. Отключение публичного доступа первым — это способ, которым работающая служба превращается в сбой с аккуратным журналом аудита.
Проверьте также, какую политику подключений использует сервер.
Redirect отправляет клиента на порт на узле после начального подключения к шлюзу, что меняет то, что должна разрешать сеть клиента. Proxy удерживает трафик на шлюзе. Успешное рукопожатие TCP на одном порту — это не весь процесс входа.
Это Azure SQL Database, а не SQL Managed Instance, у которой своя модель подключения и нет аналогичной истории с частной конечной точкой. В обоих случаях держите три вещи помеченными отдельно: имя, сетевую запись и учётные данные. Изменение того, куда идёт подключение, никогда не должно менять то, с какой службой клиент думает, что говорит.