Приватна кінцева точка, те саме ім'я сервера: рядки підключення Azure SQL

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, у якої власна модель підключення і немає рівноцінної історії з приватною кінцевою точкою. В обох випадках тримайте три речі позначеними окремо: ім'я, мережевий запис і облікові дані. Зміна того, куди йде підключення, ніколи не повинна змінювати те, з якою службою клієнт думає, що говорить.