Azure P2S VPN не може да го реши името на приватен краен пункт

Го поврзувате point-to-site тунелот, пингувате приватната адреса, ја отворате апликацијата и добивате 403 или грешка со сертификатот. Двата симптома упатуваат на DNS, но тоа се различни дефекти: едниот значи дека клиентот ја решил јавната адреса, другиот дека ја решил приватната адреса и потоа понудил име што сертификатот не го покрива. Поминете ги проверките подолу по ред и застанете на првиот неуспех, бидејќи внес во hosts или зачуван одговор може да направи секоја наредна проверка да помине од погрешна причина. Овој ред го држам во текстуална датотека покрај моите VPN профили, бидејќи поправката не менува ништо во тунелот, а сè во она што клиентот го знае.

Започнете со адресата што клиентот навистина ја добива

Прашајте го resolver-от директно наместо да и верувате на апликацијата. На Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net покажува кој поглед го добил клиентот. Јавен одговор значи дека ништо понатаму нема да стигне до крајниот пункт; приватната адреса на крајниот пункт значи дека DNS е завршен и дека следната проверка е самата врска.

Приватниот крајен пункт не го преименува сервисот. Сметката или апликацијата го задржуваат своето вообичаено целосно квалификувано име, а крајниот пункт ја менува само адресата на која тоа име се решава за клиентите во виртуелната мрежа. Затоа истото име на домаќин се решава приватно од VM во мрежата и јавно од преносен сметач на кој никогаш не му бил даден приватниот поглед.

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

Три услови мора да важат заедно: приватната зона постои, поврзана е со виртуелната мрежа во која VPN портата и клиентите влегуваат во Azure и содржи A запис за крајниот пункт што покажува на приватната адреса. Поврзете ја зоната со не поврзана мрежа и портата продолжува да го решава јавниот запис, додека сè во тунелот изгледа здраво.

Имињата на зоните им припаѓаат на сервисите, не на приватните врски општо. App Service обично користи privatelink.azurewebsites.net, складиштето и SQL имаат свои именски простори, а позајмувањето зона од друг сервис создава зона што постои и не одговара ништо корисно.

Дајте му на клиентот resolver што навистина може да го достигне

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

Конфигуриран но недостапен resolver се однесува исто како никаков resolver, а симптомот е истек на време, а не погрешен одговор, поради што се чита погрешно како проблем со огнено ѕид. Тестирајте го со барање што тунелот треба да го носи, а не со јавно име што и онака би поминало преку локалната врска.

Ако препраќате наместо да ги туркате поставките, препратете го именскиот простор што го поседува приватната зона, 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, затоа проверете ги пред повторно да ги уредувате поставките на resolver-от. Несовпаѓање на TLS името ве враќа на името на домаќинот во URL-то и на subject на сертификатот. Држете заедно излезот од решавањето, името на сертификатот и точниот URL; тие три вредности ги објаснуваат повеќето од овие случаи без допирање на портата.

Користете VM во виртуелната мрежа како контрола. Ако името таму се решава приватно, а од тунелот јавно, зоната и записот се точни и единствената разлика е патеката на resolver-от кај клиентот, што се потврдува побрзо од уште еден преглед на конфигурацијата на крајниот пункт.

Клиентите исто така кешираат. Запис што одговорил јавно пред десет минути продолжува да одговара и откако ќе ја поправите зоната, затоа исчистете го кешот пред повторно тестирање. На Windows ipconfig /flushdns го чисти кешот на клиентот; правилата за политика на решавање имиња остануваат, одредуваат кој суфикс оди на кој сервер и можат да продолжат да го праќаат именскиот простор до resolver-от што штотуку го заменивте.

Каде припаѓа внесот во hosts

Додавањето на адресата на крајниот пункт во датотека hosts е добра дијагностика и лош дизајн. Тоа докажува дека совпаѓањето име-адреса е делот што недостасува и ви овозможува да тестирате сè по тој чекор, но е невидливо за вашите корисници, се расипува кога адресата на крајниот пункт се менува и ја крие зоната што треба да одговори.

Заостанат пробен внес е полош од застарена кеш меморија, бидејќи може да направи поправената патека да изгледа расипана или расипаната патека да изгледа поправена, зависно од насоката на грешката. Отстранете го пред последното поминување и решавајте само со продукцискиот resolver.

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