Azure P2S VPN не може да разреши име на частна крайна точка

Свързвате point-to-site тунела, пингвате частния адрес, отваряте приложението и вместо това получавате 403 или грешка със сертификата. И двата симптома сочат към DNS, но това са различни повреди: единият означава, че клиентът е разрешил публичния адрес, другият — че е разрешил частния адрес и после е предложил име, което сертификатът не покрива. Минавайте проверките по-долу по ред и спирайте при първия провал, защото запис в hosts или кеширан отговор може да накара всяка следваща проверка да мине по погрешна причина. Държа този ред в текстов файл до профилите си за VPN, защото поправката не променя нищо в тунела и всичко в това, което клиентът знае.

Започнете с адреса, който клиентът действително получава

Питайте резолвера директно, вместо да се доверявате на приложението. В Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net показва кой изглед е получил клиентът. Публичен отговор означава, че нищо надолу по веригата няма да стигне до крайната точка; частният адрес на крайната точка означава, че DNS е приключил и следващата проверка е самата връзка.

Частната крайна точка не преименува услугата. Акаунтът или приложението запазва обичайното си напълно квалифицирано име, а крайната точка променя само адреса, към който това име се разрешава за клиентите във виртуалната мрежа. Затова същото име на хост се разрешава частно от VM в мрежата и публично от лаптоп, на който никога не е даван частният изглед.

Проверете зоната, връзката ѝ и записа преди тунела

Три условия трябва да са налице заедно: частната зона съществува, свързана е с виртуалната мрежа, в която VPN шлюзът и клиентите влизат в Azure, и съдържа A запис за крайната точка, сочещ към частния адрес. Свържете зоната с несвързана мрежа и шлюзът ще продължи да разрешава публичния запис, докато всичко по тунела изглежда здраво.

Имената на зони принадлежат на услуги, не на частните връзки като цяло. App Service обикновено използва privatelink.azurewebsites.net, хранилището и SQL имат свои пространства от имена, а заемането на зона от друга услуга създава зона, която съществува и не отговаря с нищо полезно.

Дайте на клиента резолвер, до който наистина достига

168.63.129.16 отговаря от виртуалните машини на Azure и не е DNS сървър за лаптоп от другата страна на point-to-site тунел. На клиента му трябва резолвер, достъпен през тунела: входяща крайна точка на Azure DNS Private Resolver, форуърдър във виртуалната мрежа или записи за DNS сървър, пренесени в профила на VPN клиента, така че клиентът да пита виртуалната мрежа директно.

Конфигуриран, но недостъпен резолвер се държи точно като липсващ такъв и симптомът е изтичане на времето, а не грешен отговор, поради което се разчита като проблем с защитна стена. Тествайте го със заявка, която тунелът трябва да пренася, а не с публично име, което и без това ще мине през локалната връзка.

Ако препредавате, вместо да избутвате настройки, препредавайте пространството от имена, което частната зона притежава, privatelink.azurewebsites.net, а не цялото azurewebsites.net. Условен форуърдър, който поглъща целия родителски суфикс, изпраща всяко търсене на услугата към Azure, включително тези, които трябва да останат локални.

Използвайте името, за което е издаден сертификатът

Щом адресът е верен, се появява втората повреда. Хранилището и App Service публикуват псевдоним privatelink, а този псевдоним не е непременно името в сертификата. Качване с AzCopy към privatelink.blob.core.windows.net не премина валидацията; същото качване към <account>.blob.core.windows.net/<container> се разреши до частния адрес и мина, така че остана по частния път без заобикаляне.

Правилото важи в браузър и за App Service: свързвайте се с името на хоста, което сертификатът покрива, и оставете DNS да достави частния адрес. Не прибягвайте до заобикаляне на валидацията, защото то превръща грешка в именуването в регресия в сигурността. Успешният ping доказва маршрута и не казва нищо за името в ръкостискането, затова това остават отделни проверки.

Ред от четири стъпки, който изолира всеки слой

1. Потвърдете, че VPN клиентът има адрес от point-to-site пула и маршрут до частния адрес на крайната точка.
2. Разрешете точното име, което приложението използва, и сравнете отговора с адреса на крайната точка.
3. Отворете TCP връзка към крайната точка на порта на услугата, после прочетете името на сертификата, представен в тази връзка.
4. Едва сега тествайте оторизацията, защото работещ път и валиден сертификат все още не дават достъп до ресурса.

Отказана връзка при верен адрес сочи към групата за сигурност на мрежата или състоянието на връзката на частната крайна точка, а не към DNS, затова проверете тях, преди отново да редактирате настройките на резолвера. Несъответствие в името на TLS ви връща към името на хоста в URL и субекта на сертификата. Пазете изхода от разрешаването, името на сертификата и точния URL заедно; тези три стойности обясняват повечето от тези случаи, без да пипате шлюза.

Използвайте VM във виртуалната мрежа като контрола. Ако името там се разрешава частно, а от тунела публично, зоната и записът са верни и единствената разлика е пътят на резолвера на клиента, което се потвърждава по-бързо от още един преглед на конфигурацията на крайната точка.

Клиентите също кешират. Запис, който е отговорил публично преди десет минути, продължава да отговаря, след като поправите зоната, затова изчистете кеша преди повторния тест. В Windows ipconfig /flushdns изчиства кеша на клиента; правилата за политика на разрешаване на имена остават, решават кой суфикс към кой сървър отива и могат да продължат да изпращат пространството от имена към резолвера, който току-що заменихте.

Къде принадлежи запис в hosts

Добавянето на адреса на крайната точка във файл hosts е добра диагностика и лош дизайн. То доказва, че липсващото парче е съответствието между име и адрес, и ви позволява да тествате всичко след тази стъпка, но е невидимо за потребителите ви, чупи се, когато адресът на крайната точка се промени, и скрива зоната, която трябва да отговаря.

Останал тестов запис е по-лош от застоял кеш, защото може да представи поправения път като счупен или счупения път като поправен в зависимост от посоката на грешката. Премахнете го преди финалното пускане и разрешавайте само с продукционния резолвер.

Кратките имена изискват суфикс за търсене, а напълно квалифицираните не, затова тествайте първо напълно квалифицираното име, после решете дали работният процес се нуждае от суфикс, пренесен през профила на клиента. Microsoft документира имената на зоните и формите на записите за всяка услуга в указанията за DNS на частни крайни точки; прочетете записа за вашата услуга, вместо да копирате зона от друга.