Hindi maresolba ng Azure P2S VPN ang pangalan ng pribadong endpoint

Kinokonekta mo ang point-to-site tunnel, nagpi-ping sa pribadong address, binubuksan ang app at nakakakuha ka ng 403 o error sa certificate. Pareho ang tinutukoy ng dalawang sintomas sa DNS, ngunit magkaibang fault sila: ang isa ay nangangahulugang naresolba ng kliyente ang pampublikong address, ang isa ay nangangahulugang naresolba niya ang pribadong address at pagkatapos ay nag-alok ng pangalan na hindi sakop ng certificate. Sundin ang mga pagsusuri sa ibaba sa pagkakasunod-sunod at huminto sa unang pagkabigo, dahil ang entry sa hosts o naka-cache na sagot ay makakapagpagawa sa bawat susunod na pagsusuri na pumasa sa maling dahilan. Itinatago ko ang pagkakasunod-sunod na ito sa isang text file sa tabi ng aking mga profile ng VPN, dahil walang binabago ang pagwawasto sa tunnel at binabago ang lahat sa nalalaman ng kliyente.

Simulan sa address na aktwal na natatanggap ng kliyente

Tanungin ang resolver nang direkta sa halip na magtiwala sa application. Sa Windows, ipinapakita ng nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net kung aling view ang natanggap ng kliyente. Ang pampublikong sagot ay nangangahulugang walang makakarating sa endpoint sa ibaba; ang pribadong address ng endpoint ay nangangahulugang tapos na ang DNS at ang susunod na pagsusuri ay ang koneksyon mismo.

Ang pribadong endpoint hindi pinapalitan ang pangalan ng serbisyo. Pinapanatili ng account o app ang karaniwang ganap na kwalipikadong pangalan nito, at binabago lamang ng endpoint ang address kung saan nare-resolve ang pangalang iyon para sa mga kliyente sa loob ng virtual network. Kaya nare-resolve ang parehong hostname nang pribado mula sa isang VM sa network at pampubliko mula sa laptop na hindi kailanman nabigyan ng pribadong view.

Suriin ang zone, ang link nito at ang record bago ang tunnel

Tatlong kondisyon ang dapat matugunan nang sabay: umiiral ang pribadong zone, naka-link ito sa virtual network kung saan pumapasok sa Azure ang VPN gateway at ang mga kliyente, at mayroon itong A record para sa endpoint na tumuturo sa pribadong address. I-link ang zone sa hindi kaugnay na network at patuloy na ire-resolve ng gateway ang pampublikong record habang mukhang malusog ang lahat sa tunnel.

Ang mga pangalan ng zone ay pag-aari ng mga serbisyo, hindi ng mga pribadong link sa pangkalahatan. Karaniwang gumagamit ang App Service ng privatelink.azurewebsites.net, may sariling namespace ang storage at SQL, at ang paghiram ng zone ng ibang serbisyo ay gumagawa ng zone na umiiral ngunit walang kapaki-pakinabang na sinasagot.

Bigyan ang kliyente ng resolver na talagang maabot niya

Sumasagot ang 168.63.129.16 mula sa mga virtual machine ng Azure at hindi ito DNS server para sa laptop sa kabilang panig ng point-to-site tunnel. Kailangan ng kliyente ng resolver na maabot sa pamamagitan ng tunnel: isang inbound endpoint ng Azure DNS Private Resolver, isang forwarder sa loob ng virtual network, o mga entry ng DNS server na dala sa profile ng kliyente ng VPN upang direktang magtanong ang kliyente sa virtual network.

Ang resolver na naka-configure ngunit hindi maabot ay kumikilos na parang walang resolver, at ang sintomas ay timeout sa halip na maling sagot, kaya nababasa ito nang mali bilang problema sa firewall. Subukan ito gamit ang query na dapat dalhin ng tunnel, hindi gamit ang pampublikong pangalan na papasa pa rin sa lokal na link.

Kung nagfo-forward ka sa halip na nagtutulak ng settings, i-forward ang namespace na pag-aari ng pribadong zone, privatelink.azurewebsites.net sa halip na buong azurewebsites.net. Ang conditional forwarder na lumalamon sa buong parent suffix ay nagpapadala sa Azure ng bawat paghahanap para sa serbisyo, kasama ang mga dapat manatiling lokal.

Gamitin ang pangalang inilabas ng certificate

Kapag tama na ang address, lumalabas ang pangalawang fault. Naglalathala ang storage at App Service ng alias na privatelink, at ang alias na iyon ay hindi kinakailangang ang pangalan sa certificate. Nabigo sa validation ang isang pag-upload ng AzCopy na nakadirekta sa privatelink.blob.core.windows.net; ang parehong pag-upload sa <account>.blob.core.windows.net/<container> ay nare-resolve sa pribadong address at pumasa, kaya nanatili ito sa pribadong landas nang walang anumang pag-iwas.

Gumagana ang tuntunin sa browser at sa App Service: kumonekta gamit ang hostname na sakop ng certificate at hayaang ang DNS ang magbigay ng pribadong address. Huwag kang gumawa ng paraan upang laktawan ang validation, dahil ginagawa nitong security regression ang isang pagkakamali sa pagpapangalan. Ang matagumpay na ping ay nagpapatunay ng ruta at walang sinasabi tungkol sa pangalan sa loob ng handshake, kaya nananatili silang magkahiwalay na pagsusuri.

Isang pagkakasunod-sunod ng apat na hakbang na naghihiwalay sa bawat layer

1. Tiyakin na ang kliyente ng VPN ay may address mula sa point-to-site pool at ruta patungo sa pribadong address ng endpoint.
2. I-resolve ang eksaktong pangalang ginagamit ng app at ihambing ang sagot sa address ng endpoint.
3. Magbukas ng TCP connection sa endpoint sa port ng serbisyo, pagkatapos ay basahin ang pangalan ng certificate na iniharap sa koneksyong iyon.
4. Ngayon lang subukan ang awtorisasyon, dahil ang gumaganang landas at valid na certificate ay hindi pa nagbibigay ng access sa resource.

Ang tinanggihang koneksyon habang tama ang address ay tumutukoy sa network security group o sa estado ng koneksyon ng pribadong endpoint, hindi sa DNS, kaya suriin ang mga iyon bago muling i-edit ang mga setting ng resolver. Ang hindi pagtutugma ng pangalan sa TLS ay nagbabalik sa iyo sa hostname sa URL at sa subject ng certificate. Itago nang sabay ang output ng resolution, ang pangalan ng certificate at ang eksaktong URL; ang tatlong halagang iyon ang nagpapaliwanag sa karamihan ng mga kasong ito nang hindi hinahawakan ang gateway.

Gumamit ng VM sa loob ng virtual network bilang kontrol. Kung nare-resolve ang pangalan nang pribado doon at pampubliko mula sa tunnel, tama ang zone at record at ang tanging pagkakaiba ay ang landas ng resolver ng kliyente, na mas mabilis kumpirmahin kaysa sa isa pang pagdaan sa configuration ng endpoint.

Nagca-cache din ang mga kliyente. Ang record na sumagot nang pampubliko sampung minuto ang nakalipas ay patuloy na sumasagot pagkatapos mong ayusin ang zone, kaya i-flush ang cache bago muling subukan. Sa Windows, nililinis ng ipconfig /flushdns ang cache ng kliyente; nananatili ang mga tuntunin ng patakaran sa resolution ng pangalan, nagpapasya kung aling suffix ang pupunta sa aling server, at maaaring patuloy na ipadala ang namespace sa resolver na kalilipat mo lang.

Saan nababagay ang entry sa hosts

Ang pagdaragdag ng address ng endpoint sa hosts file ay mabuting diagnosis at masamang disenyo. Pinatutunayan nito na ang pagmamapa ng pangalan-sa-address ang nawawalang piraso at hinahayaan kang subukan ang lahat pagkatapos ng hakbang na iyon, ngunit hindi ito nakikita ng iyong mga user, nasisira kapag nagbago ang address ng endpoint, at itinatago ang zone na dapat sumagot.

Ang natirang test entry ay mas malala kaysa sa lumang cache, dahil maaari nitong gawing parang sira ang naayos na landas o parang naayos ang sirang landas depende sa direksyon ng error. Alisin ito bago ang huling pagtakbo at mag-resolve lamang gamit ang production resolver.

Ang maiikling pangalan ay nangangailangan ng search suffix at ang ganap na kwalipikadong pangalan ay hindi, kaya subukan muna ang ganap na kwalipikadong pangalan, pagkatapos ay magpasya kung ang workflow ay nangangailangan ng suffix na itinutulak sa pamamagitan ng profile ng kliyente. Idinodokumento ng Microsoft ang mga pangalan ng zone at hugis ng record bawat serbisyo sa mga patnubay nito sa DNS para sa mga pribadong endpoint; basahin ang entry para sa iyong serbisyo sa halip na kopyahin ang zone mula sa iba.