Azure P2S VPN kan nie 'n privaat eindpunt se naam oplos nie

Jy verbind die point-to-site-tonnel, ping die privaat adres, maak die app oop en kry eerder 'n 403 of 'n sertifikaatfout. Albei simptome wys na DNS, maar dit is verskillende foute: die een beteken die kliënt het die publieke adres opgelos, die ander beteken hy het die privaat adres opgelos en toe 'n naam aangebied wat die sertifikaat nie dek nie. Werk die kontroles hieronder in volgorde deur en stop by die eerste fout, want 'n hosts-inskrywing of 'n gekasde antwoord kan elke latere kontrole om die verkeerde rede laat slaag. Ek hou hierdie volgorde in 'n tekslêer langs my VPN-profiele, want die regstelling verander niks aan die tonnel nie en alles aan wat die kliënt weet.

Begin by die adres wat die kliënt werklik kry

Vra die oplosser direk in plaas daarvan om die toepassing te vertrou. Op Windows wys nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net watter aansig die kliënt ontvang het. 'n Publieke antwoord beteken niks stroomaf sal die eindpunt bereik nie; die eindpunt se privaat adres beteken DNS is klaar en die volgende kontrole is die verbinding self.

'n Privaat eindpunt hernoem nie die diens nie. Die rekening of app behou sy gewone volledig gekwalifiseerde naam, en die eindpunt verander net die adres waarna daardie naam vir kliënte binne die virtuele netwerk oplos. Dis hoekom dieselfde hostnaam privaat oplos vanaf 'n VM in die netwerk en publiek vanaf 'n skootrekenaar wat nooit die privaat aansig gekry het nie.

Kontroleer die sone, sy skakel en die rekord voor die tonnel

Drie voorwaardes moet saam geld: die privaat sone bestaan, dit is aan die virtuele netwerk gekoppel waar die VPN-gateway en die kliënte Azure binnekom, en dit hou 'n A-rekord vir die eindpunt wat na die privaat adres wys. Koppel die sone aan 'n onverwante netwerk en die gateway bly die publieke rekord oplos terwyl alles aan die tonnel nog gesond lyk.

Sone-name behoort aan dienste, nie aan privaat skakels in die algemeen nie. App Service gebruik gewoonlik privatelink.azurewebsites.net, stoor en SQL het hul eie naamruimtes, en om 'n ander diens se sone te leen lewer 'n sone wat bestaan en niks nuttigs antwoord nie.

Gee die kliënt 'n oplosser wat hy werklik kan bereik

168.63.129.16 antwoord vanaf Azure virtuele masjiene en is nie 'n DNS-bediener vir 'n skootrekenaar aan die ander kant van 'n point-to-site-tonnel nie. Die kliënt het 'n oplosser nodig wat deur die tonnel bereikbaar is: 'n Azure DNS Private Resolver-inkompunt, 'n deurstuurder binne die virtuele netwerk, of DNS-bediener-inskrywings wat in die VPN-kliëntprofiel gedra word sodat die kliënt die virtuele netwerk direk vra.

'n Oplosser wat opgestel maar onbereikbaar is, gedra hom presies soos geen oplosser nie, en die simptoom is 'n tydsverloop eerder as 'n verkeerde antwoord, wat is hoekom dit as 'n firewallprobleem mislees word. Toets dit met 'n navraag wat die tonnel veronderstel is om te dra, nie met 'n publieke naam wat oor die plaaslike skakel tog sou slaag nie.

As jy deurstuur eerder as om instellings te stoot, stuur die naamruimte deur wat die privaat sone besit, privatelink.azurewebsites.net eerder as die hele azurewebsites.net. 'n Voorwaardelike deurstuurder wat die hele ouersuffiks insluk, stuur elke opsoeking vir die diens na Azure, insluitend die wat plaaslik moet bly.

Gebruik die naam waarvoor die sertifikaat uitgereik is

Sodra die adres reg is, kom die tweede fout na vore. Stoor en App Service publiseer 'n privatelink-alias, en daardie alias is nie noodwendig die naam in die sertifikaat nie. 'n AzCopy-oplaai wat na privatelink.blob.core.windows.net geadresseer is, het die validering gefaal; dieselfde oplaai na <account>.blob.core.windows.net/<container> het na die privaat adres opgelos en geslaag, so dit het op die privaat pad gebly sonder 'n oorheersing.

Die reël geld in 'n blaaier en ook vir App Service: verbind met die hostnaam wat die sertifikaat dek en laat DNS die privaat adres verskaf. Moenie na 'n validering-omseiling gryp nie, want dit maak 'n naamfout in 'n sekuriteitsagteruitgang. 'n Suksesvolle ping bewys die roete en sê niks oor die naam binne die handskud nie, wat is hoekom hierdie aparte kontroles bly.

'n Orde van vier stappe wat elke laag isoleer

1. Bevestig die VPN-kliënt het 'n adres uit die point-to-site-poel en het 'n roete na die eindpunt se privaat adres.
2. Los die presiese naam op wat die toepassing gebruik en vergelyk die antwoord met die eindpunt se adres.
3. Maak 'n TCP-verbinding na die eindpunt op die dienspoort oop en lees dan die sertifikaatnaam wat op daardie verbinding aangebied word.
4. Toets eers nou magtiging, want 'n werkende pad en 'n geldige sertifikaat verleen steeds nie toegang tot die hulpbron nie.

'n Verbinding wat geweier word terwyl die adres reg is, wys na die netwerksekuriteitsgroep of die privaat eindpunt se verbindingstatus, nie na DNS nie, so kontroleer dit voordat jy weer oplosser-instellings wysig. 'n TLS-naamwanverhouding stuur jou terug na die hostnaam in die URL en die sertifikaat se onderwerp. Hou die oplossingsuitset, die sertifikaatnaam en die presiese URL saam; daardie drie waardes verduidelik die meeste van hierdie gevalle sonder om aan die gateway te raak.

Gebruik 'n VM binne die virtuele netwerk as 'n kontrole. As die naam daar privaat oplos en publiek vanaf die tonnel, is die sone en die rekord korrek en is die enigste verskil die kliënt se oplosserpad, wat vinniger bevestig word as nog 'n deurloop van die eindpunt-konfigurasie.

Kliënte kas ook. 'n Rekord wat tien minute gelede publiek geantwoord het, bly antwoord nadat jy die sone reggemaak het, so spoel voor jy weer toets. Op Windows maak ipconfig /flushdns die kliëntkas skoon; naamoplossing-beleidsreëls bly egter, besluit watter suffiks na watter bediener gaan, en kan die naamruimte aanhou stuur na die oplosser wat jy pas vervang het.

Waar 'n hosts-inskrywing hoort

Om die eindpunt se adres by 'n hosts-lêer te voeg, is 'n goeie diagnostiese middel en 'n swak ontwerp. Dit bewys die naam-tot-adres-kartering is die ontbrekende stuk en laat jou alles daarna toets, maar dit is onsigbaar vir jou gebruikers, breek wanneer die eindpunt se adres verander, en verberg die sone wat behoort te antwoord.

'n Oorblywende toetsinskrywing is erger as 'n verouderde kas, want dit kan die reggemaakte pad laat lyk of dit stukkend is, of die stukkende pad laat lyk of dit reg is, afhangend van die rigting van die fout. Verwyder dit voor die finale lopie en los op met net die produksie-oplosser.

Kort name benodig 'n soeksuffiks en volledig gekwalifiseerde name nie, so toets eers die volledig gekwalifiseerde naam en besluit dan of die werkvloei 'n suffiks nodig het wat deur die kliëntprofiel gestuur word. Microsoft dokumenteer die per-diens sone-name en rekordvorms in sy privaat eindpunt DNS-riglyne; lees die inskrywing vir jou diens eerder as om 'n sone van 'n ander een te kopieer.