Azure P2S VPN nuk arrin të zgjidhë emrin e një pike fundore private

Lidhni tunelin point-to-site, bëni ping në adresën private, hapni aplikacionin dhe merrni në vend të tij një 403 ose një gabim certifikate. Të dy simptomat tregojnë DNS, por janë defekte të ndryshme: njëri do të thotë që klienti zgjidhi adresën publike, tjetri që zgjidhi adresën private dhe më pas ofroi një emër që certifikata nuk e mbulon. Ndjekini kontrollet më poshtë me radhë dhe ndaloni në dështimin e parë, sepse një zë hosts ose një përgjigje e ruajtur në cache mund ta bëjnë çdo kontroll të mëvonshëm të kalojë për arsye të gabuar. Këtë rend e mbaj në një skedar teksti pranë profileve të mia VPN, sepse rregullimi nuk ndryshon asgjë në tunel dhe ndryshon gjithçka në atë që klienti di.

Filloni me adresën që klienti merr vërtet

Pyetni zgjidhësin drejtpërdrejt në vend që t'i besoni aplikacionit. Në Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net tregon cilën pamje mori klienti. Një përgjigje publike do të thotë që asgjë më poshtë nuk do të arrijë pikën fundore; adresa private e pikës fundore do të thotë që DNS ka mbaruar dhe kontrolli tjetër është vetë lidhja.

Një pikë fundore private nuk e riemërton shërbimin. Llogaria ose aplikacioni mban emrin e vet të zakonshëm të plotë, dhe pika fundore ndryshon vetëm adresën në të cilën ai emër zgjidhet për klientët brenda rrjetit virtual. Kjo është arsyeja pse i njëjti emër hosti zgjidhet privatisht nga një VM në rrjet dhe publikisht nga një laptop që nuk e ka marrë kurrë pamjen private.

Kontrolloni zonën, lidhjen e saj dhe regjistrimin përpara tunelit

Tre kushte duhet të plotësohen së bashku: zona private ekziston, është e lidhur me rrjetin virtual ku hyjnë në Azure porta VPN dhe klientët, dhe përmban një regjistrim A për pikën fundore që tregon adresën private. Lidhni zonën me një rrjet të palidhur dhe porta do të vazhdojë të zgjidhë regjistrimin publik, ndërsa gjithçka në tunel duket e shëndetshme.

Emrat e zonave u përkasin shërbimeve, jo lidhjeve private në përgjithësi. App Service zakonisht përdor privatelink.azurewebsites.net, ruajtja dhe SQL kanë hapësirat e tyre të emrave, dhe huazimi i zonës së një shërbimi tjetër prodhon një zonë që ekziston dhe nuk përgjigjet asgjë të dobishme.

Jepini klientit një zgjidhës që vërtet mund ta arrijë

168.63.129.16 përgjigjet nga makineritë virtuale të Azure dhe nuk është server DNS për një laptop në anën tjetër të një tuneli point-to-site. Klienti ka nevojë për një zgjidhës të arritshëm përmes tunelit: një pikë fundore hyrëse të Azure DNS Private Resolver, një përcjellës brenda rrjetit virtual, ose zëra serveri DNS të mbartura në profilin e klientit VPN, që klienti t'i pyesë rrjetin virtual drejtpërdrejt.

Një zgjidhës i konfiguruar por i paarritshëm sillet njësoj si asnjë zgjidhës, dhe simptoma është një skadim kohe dhe jo një përgjigje e gabuar, prandaj lexohet gabimisht si problem muri zjarri. Testojeni me një kërkesë që tuneli duhet të mbartë, jo me një emër publik që do të kishte kaluar gjithsesi përmes lidhjes lokale.

Nëse përcillni në vend që të shtyni cilësime, përcillni hapësirën e emrave që zotëron zona private, privatelink.azurewebsites.net në vend të të gjithë azurewebsites.net. Një përcjellës i kushtëzuar që gëlltit gjithë prapashtesën mëmë dërgon në Azure çdo kërkim të shërbimit, përfshirë ata që duhet të mbeten lokalë.

Përdorni emrin për të cilin është lëshuar certifikata

Kur adresa është e saktë, shfaqet defekti i dytë. Ruajtja dhe App Service publikojnë një pseudonim privatelink, dhe ky pseudonim nuk është domosdoshmërisht emri në certifikatë. Një ngarkim AzCopy drejt privatelink.blob.core.windows.net dështoi validimin; i njëjti ngarkim drejt <account>.blob.core.windows.net/<container> u zgjidh në adresën private dhe kaloi, prandaj mbeti në rrugën private pa asnjë anashkalim.

Rregulli vlen në shfletues dhe edhe për App Service: lidhuni me emrin e hostit që mbulon certifikata dhe lërini DNS t'i japë adresën private. Mos shkoni drejt anashkalimit të validimit, sepse ai e kthen një gabim emërtimi në regres sigurie. Një ping i suksesshëm provon rrugën dhe nuk thotë asgjë për emrin brenda shtrëngimit të duarve, prandaj këto mbeten kontrolle të veçanta.

Një rend me katër hapa që izolon çdo shtresë

1. Konfirmoni që klienti VPN ka një adresë nga grupi point-to-site dhe një rrugë drejt adresës private të pikës fundore.
2. Zgjidhni emrin e saktë që përdor aplikacioni dhe krahasoni përgjigjen me adresën e pikës fundore.
3. Hapni një lidhje TCP drejt pikës fundore në portën e shërbimit, më pas lexoni emrin e certifikatës që paraqitet në atë lidhje.
4. Vetëm tani provoni autorizimin, sepse një rrugë që funksionon dhe një certifikatë e vlefshme nuk japin ende akses në burim.

Një lidhje e refuzuar ndërsa adresa është e saktë tregon grupin e sigurisë së rrjetit ose gjendjen e lidhjes së pikës fundore private, jo DNS, prandaj kontrolloni ato përpara se të redaktoni përsëri cilësimet e zgjidhësit. Një mospërputhje e emrit TLS ju kthen te emri i hostit në URL dhe te subject i certifikatës. Mbani së bashku daljen e zgjidhjes, emrin e certifikatës dhe URL-në e saktë; këto tre vlera shpjegojnë shumicën e këtyre rasteve pa prekur portën.

Përdorni një VM brenda rrjetit virtual si kontroll. Nëse emri zgjidhet atje privatisht dhe publikisht nga tuneli, zona dhe regjistrimi janë të sakta dhe i vetmi ndryshim është rruga e zgjidhësit të klientit, e cila konfirmohet më shpejt sesa një tjetër kalim në konfigurimin e pikës fundore.

Klientët gjithashtu mbajnë cache. Një regjistrim që u përgjigj publikisht dhjetë minuta më parë vazhdon të përgjigjet edhe pasi të rregulloni zonën, prandaj zbrazni cache-in përpara se të ritestoni. Në Windows, ipconfig /flushdns pastron cache-in e klientit; rregullat e politikës së zgjidhjes së emrave mbeten, vendosin cila prapashtesë shkon në cilin server dhe mund të vazhdojnë ta dërgojnë hapësirën e emrave te zgjidhësi që sapo zëvendësuat.

Ku i takon një zë hosts

Shtimi i adresës së pikës fundore në një skedar hosts është diagnostikim i mirë dhe dizajn i keq. Provon që hartëzimi emër-në-adresë është pjesa që mungon dhe ju lejon të testoni gjithçka pas atij hapi, por është i padukshëm për përdoruesit tuaj, prishet kur ndryshon adresa e pikës fundore dhe fsheh zonën që duhet të përgjigjet.

Një zë testues i mbetur është më keq se një cache i vjetruar, sepse mund ta bëjë rrugën e rregulluar të duket e thyer ose rrugën e thyer të duket e rregulluar, në varësi të drejtimit të gabimit. Hiqeni përpara kalimit përfundimtar dhe zgjidhni vetëm me zgjidhësin e prodhimit.

Emrat e shkurtër kanë nevojë për një prapashtesë kërkimi dhe emrat e plotë jo, prandaj testoni fillimisht emrin e plotë dhe më pas vendosni nëse rrjedha e punës ka nevojë për një prapashtesë të shtyrë përmes profilit të klientit. Microsoft dokumenton emrat e zonave dhe format e regjistrimeve për çdo shërbim në udhëzimet e tij të DNS-së për pikat fundore private; lexoni zërin për shërbimin tuaj në vend që të kopjoni një zonë nga një tjetër.