Azure P2S VPN negali išspręsti privataus galinio taško pavadinimo

Prisijungiate prie point-to-site tunelio, pinginate privatų adresą, atidarote programą ir gaunate 403 arba sertifikato klaidą. Abu simptomai rodo į DNS, bet tai skirtingi gedimai: vienas reiškia, kad klientas išsprendė viešą adresą, kitas – kad išsprendė privatų adresą ir tada pasiūlė vardą, kurio sertifikatas neapima. Atlikite žemiau pateiktas patikras iš eilės ir sustokite ties pirmu gedimu, nes hosts įrašas arba podėlyje esantis atsakymas gali priversti kiekvieną vėlesnę patikrą praeiti dėl neteisingos priežasties. Šią tvarką laikau tekstiniame faile prie savo VPN profilių, nes pataisa nieko nekeičia tunelyje ir viską keičia tame, ką klientas žino.

Pradėkite nuo adreso, kurį klientas iš tikrųjų gauna

Klauskite resolverio tiesiogiai, o ne pasitikėkite programa. Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net parodo, kurį rodinį klientas gavo. Viešas atsakymas reiškia, kad niekas toliau nepasieks galinio taško; privatus galinio taško adresas reiškia, kad DNS baigtas ir kad kita patikra yra pats ryšys.

Privatus galinis taškas nepervardija paslaugos. Paskyra arba programa išlaiko įprastą visiškai kvalifikuotą vardą, o galinis taškas keičia tik adresą, į kurį tas vardas išsprendžiamas klientams virtualiame tinkle. Todėl tas pats pagrindinis vardas išsprendžiamas privačiai iš VM tinkle ir viešai iš nešiojamojo kompiuterio, kuriam niekada nebuvo suteiktas privatus rodinys.

Patikrinkite zoną, jos nuorodą ir įrašą prieš tunelį

Turi galioti trys sąlygos kartu: privati zona egzistuoja, ji susieta su virtualiu tinklu, kuriame VPN šliuzas ir klientai patenka į Azure, ir joje yra A įrašas galiniam taškui, rodantis į privatų adresą. Susiekite zoną su nesusijusiu tinklu ir šliuzas toliau spręs viešą įrašą, o tunelyje viskas atrodys sveika.

Zonų pavadinimai priklauso paslaugoms, o ne apskritai privatiems ryšiams. App Service paprastai naudoja privatelink.azurewebsites.net, saugykla ir SQL turi savo vardų erdves, o skolinantis kitos paslaugos zoną gaunama zona, kuri egzistuoja ir nieko naudingo neatsako.

Duokite klientui resolverį, kurį jis iš tikrųjų pasieks

168.63.129.16 atsako iš Azure virtualių mašinų ir nėra DNS serveris nešiojamajam kompiuteriui kitoje point-to-site tunelio pusėje. Klientui reikia per tunelį pasiekiamo resolverio: Azure DNS Private Resolver įeinančio galinio taško, persiųstuvo virtualiame tinkle arba DNS serverio įrašų, perkeliamų VPN kliento profilyje, kad klientas klaustų virtualaus tinklo tiesiogiai.

Sukonfigūruotas, bet nepasiekiamas resolveris elgiasi lygiai taip pat kaip jokio resolverio, o simptomas yra laiko limitas, o ne klaidingas atsakymas, todėl jis neteisingai skaitomas kaip ugniasienės problema. Išbandykite jį užklausa, kurią tunelis turi pernešti, o ne viešu vardu, kuris per vietinę nuorodą vis tiek būtų pavykęs.

Jei persiunčiate, o ne stumiate nustatymus, persiųskite vardų erdvę, kuri priklauso privačiai zonai, privatelink.azurewebsites.net, o ne visą azurewebsites.net. Sąlyginis persiuntėjas, kuris praryja visą pirminį galūnę, siunčia į Azure kiekvieną paslaugos paiešką, įskaitant tas, kurios turėtų likti vietinės.

Naudokite vardą, kuriam buvo išduotas sertifikatas

Kai adresas teisingas, pasirodo antrasis gedimas. Saugykla ir App Service skelbia privatelink slapyvardį, ir tas slapyvardis nebūtinai yra sertifikate esantis vardas. AzCopy įkėlimas į privatelink.blob.core.windows.net nepraėjo validacijos; tas pats įkėlimas į <account>.blob.core.windows.net/<container> išsisprendė į privatų adresą ir praėjo, todėl liko privačiame kelyje be jokio apėjimo.

Taisyklė galioja naršyklėje ir App Service: junkitės su pagrindiniu vardu, kurį sertifikatas apima, ir leiskite DNS pateikti privatų adresą. Nesinaudokite validacijos apėjimu, nes jis pavadinimo klaidą paverčia saugumo regresija. Sėkmingas ping įrodo maršrutą ir nieko nesako apie vardą rankos paspaudimo viduje, todėl tai lieka atskiros patikros.

Keturių žingsnių tvarka, kuri izoliuoja kiekvieną sluoksnį

1. Patvirtinkite, kad VPN klientas turi adresą iš point-to-site baseino ir maršrutą į privatų galinio taško adresą.
2. Išspręskite tikslų vardą, kurį naudoja programa, ir palyginkite atsakymą su galinio taško adresu.
3. Atidarykite TCP ryšį su galiniu tašku paslaugos prievade, tada perskaitykite tame ryšyje pateiktą sertifikato vardą.
4. Autorizaciją tikrinkite tik dabar, nes veikiantis kelias ir galiojantis sertifikatas dar nesuteikia prieigos prie ištekliaus.

Atmestas ryšys, kai adresas teisingas, rodo tinklo saugos grupę arba privataus galinio taško ryšio būseną, o ne DNS, todėl patikrinkite juos prieš vėl redaguodami resolverio nustatymus. TLS vardo neatitikimas grąžina jus prie URL pagrindinio vardo ir sertifikato subject. Laikykite kartu sprendimo išvestį, sertifikato vardą ir tikslų URL; šios trys reikšmės paaiškina daugumą tokių atvejų neliečiant šliuzo.

Naudokite VM virtualiame tinkle kaip kontrolę. Jei vardas ten išsprendžiamas privačiai, o iš tunelio viešai, zona ir įrašas teisingi, o vienintelis skirtumas yra kliento resolverio kelias, kurį patvirtinti greičiau nei dar vieną galinio taško konfigūracijos peržiūrą.

Klientai taip pat podėlyje laiko. Įrašas, kuris viešai atsakė prieš dešimt minučių, atsakinėja ir pataisius zoną, todėl prieš pakartotinį testą išvalykite podėlį. Windows ipconfig /flushdns išvalo kliento podėlį; vardų sprendimo strategijos taisyklės išlieka, nusprendžia, kuri galūnė į kurį serverį eina, ir gali toliau siųsti vardų erdvę resolveriui, kurį ką tik pakeitėte.

Kur turi būti hosts įrašas

Galinio taško adreso įtraukimas į hosts failą yra gera diagnostika ir blogas dizainas. Tai įrodo, kad vardo ir adreso atitikimas yra trūkstama dalis, ir leidžia išbandyti viską po to žingsnio, bet tai nematoma jūsų naudotojams, sugenda pasikeitus galinio taško adresui ir paslepia zoną, kuri turėtų atsakyti.

Likutinis bandymo įrašas yra blogiau nei pasenęs podėlis, nes priklausomai nuo klaidos krypties gali parodyti pataisytą kelią kaip sugedusį arba sugedusį kelią kaip pataisytą. Pašalinkite jį prieš paskutinį paleidimą ir spręskite tik produkcijos resolveriu.

Trumpiems vardams reikia paieškos galūnės, o visiškai kvalifikuotiems ne, todėl pirmiausia patikrinkite visiškai kvalifikuotą vardą, tada nuspręskite, ar darbo eigai reikia galūnės, perduodamos per kliento profilį. Microsoft dokumentuoja zonų pavadinimus ir įrašų formas pagal paslaugą savo privačių galinių taškų DNS rekomendacijose; skaitykite savo paslaugos įrašą, o ne kopijuokite zoną iš kitos.