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 прыватных канцавых кропак; чытайце запіс для свайго сэрвісу, а не капіруйце зону з іншага.