Þú tengir point-to-site göngin, pingar einkavistfangið, opnar forritið og færð í staðinn 403 eða villu í vottorði. Bæði einkennin benda á DNS, en þetta eru mismunandi bilanir: önnur þýðir að biðlarinn leysti opinbera vistfangið, hin að hann leysti einkavistfangið og bauð síðan nafn sem vottorðið nær ekki yfir. Farðu í gegnum prófanirnar hér fyrir neðan í röð og stoppaðu við fyrstu bilun, því hosts-færsla eða svarsýn í skyndiminni getur látið hverja síðari prófun standast af rangri ástæðu. Ég geymi þessa röð í textaskrá við hliðina á VPN-sniðunum mínum, því lagfæringin breytir engu um göngin og öllu um það sem biðlarinn veit.

Byrjaðu á vistfanginu sem biðlarinn fær í raun

Spurðu leysinn beint í stað þess að treysta forritinu. Í Windows sýnir nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net hvaða sýn biðlarinn fékk. Opinbert svar þýðir að ekkert neðar mun ná endapunktinum; einkavistfang endapunktsins þýðir að DNS er búið og að næsta prófun er tengingin sjálf.

Einkanlegur endapunktur endurnefnir ekki þjónustuna. Reikningurinn eða forritið heldur venjulegu fullu nafni sínu, og endapunkturinn breytir aðeins vistfanginu sem það nafn leysist í fyrir biðlara innan sýndarnetsins. Þess vegna leysist sama hýsilnafn einkanlega frá VM í netinu og opinberlega frá fartölvu sem fékk aldrei einkasýnina.

Athugaðu svæðið, tengingu þess og færsluna fyrir göngin

Þrjú skilyrði verða að gilda saman: einkasvæðið er til, það er tengt sýndarnetinu sem VPN-gáttin og biðlararnir fara inn í Azure um, og það inniheldur A-færslu fyrir endapunktinn sem bendir á einkavistfangið. Tenging svæðisins við óskyldu neti gerir það að verkum að gáttin heldur áfram að leysa opinberu færsluna á meðan allt við göngin virðist heilbrigt.

Svæðisnöfn tilheyra þjónustum, ekki einkatengingum almennt. App Service notar venjulega privatelink.azurewebsites.net, geymslan og SQL hafa sín eigin nafnrými, og að fá lánað svæði annarrar þjónustu býr til svæði sem er til og svarar engu nytsamlegu.

Gefðu biðlaranum leysi sem hann nær í raun

168.63.129.16 svarar frá sýndarvélum Azure og er ekki DNS-þjónn fyrir fartölvu hinum megin við point-to-site göng. Biðlarinn þarf leysi sem er aðgengilegur gegnum göngin: inngönguendapunkt Azure DNS Private Resolver, áframsendingu innan sýndarnetsins, eða DNS-þjónsfærslur sem bornar eru í VPN-biðlarasniðinu svo biðlarinn spyrji sýndarnetið beint.

Leysir sem er stilltur en óaðgengilegur hagar sér nákvæmlega eins og enginn leysir, og einkennið er tímanút en ekki rangt svar, og þess vegna er það lesið rangt sem eldveggsvandamál. Prófaðu hann með fyrirspurn sem göngin eiga að bera, ekki með opinberu nafni sem hefði gengið upp um staðtengingu hvort sem er.

Ef þú framsendir í stað þess að ýta stillingum, framsendu nafnrýmið sem einkasvæðið á, privatelink.azurewebsites.net í stað alls azurewebsites.net. Skilyrt framsending sem gleypir allt foreldraviðskeytið sendir hverja leit þjónustunnar til Azure, þar á meðal þær sem ættu að vera staðbundnar.

Notaðu nafnið sem vottorðið var gefið út fyrir

Þegar vistfangið er rétt kemur önnur bilanin í ljós. Geymslan og App Service birta privatelink samheiti, og það samheiti er ekki endilega nafnið í vottorðinu. AzCopy-hleðsla sem var beint á privatelink.blob.core.windows.net féll á sannprófun; sama hleðsla á <account>.blob.core.windows.net/<container> leystist í einkavistfangið og gekk, svo hún var áfram á einkanlegu leiðinni án undanþágu.

Reglan gildir í vafra og fyrir App Service líka: tengdu með hýsilnafninu sem vottorðið nær yfir og láttu DNS sjá um einkavistfangið. Ekki grípa til þess að komast fram hjá sannprófun, því það gerir nafngreiningarmistök að öryggisafari. Árangursríkt ping sannar leiðina og segir ekkert um nafnið inni í handabandinu, þess vegna eru þetta áfram aðskildar prófanir.

Röð í fjórum skrefum sem einangrar hvert lag

  1. Staðfestu að VPN-biðlarinn hafi vistfang úr point-to-site lauginni og leið að einkavistfangi endapunktsins.
  2. Leystu nákvæmlega það nafn sem forritið notar og berðu svarið saman við vistfang endapunktsins.
  3. Opnaðu TCP-tengingu við endapunktinn á þjónustuhliðinu og lestu síðan vottorðsnafnið sem birt er á þeirri tengingu.
  4. Prófaðu heimildina fyrst núna, því virk leið og gilt vottorð veita enn ekki aðgang að tilfanginu.

Hafnað tenging þegar vistfangið er rétt bendir á netöryggishópinn eða stöðu einkatengingar endapunktsins, ekki á DNS, svo athugaðu það áður en þú breytir stillingum leysisins aftur. Ósamræmi í TLS-nafni sendir þig aftur í hýsilnaf slóðarinnar og subject vottorðsins. Haltu úttaki leysingarinnar, vottorðsnafninu og nákvæmu slóðinni saman; þessi þrjú gildi skýra flest þessara tilvika án þess að snerta gáttina.

Notaðu VM innan sýndarnetsins sem viðmiðun. Ef nafnið leysist þar einkanlega og opinberlega frá göngunum eru svæðið og færslan rétt og eini munurinn er leið leysisins hjá biðlaranum, sem er fljótlegra að staðfesta en enn ein yfirferð yfir stillingar endapunktsins.

Biðlarar skyndiminnið líka. Færsla sem svaraði opinberlega fyrir tíu mínútum svarar áfram eftir að þú lagar svæðið, svo tæmdu skyndiminnið áður en þú prófar aftur. Í Windows hreinsar ipconfig /flushdns skyndiminni biðlarans; reglur um stefnu nafnaleysingar vara við, ákveða hvaða viðskeyti fer í hvaða þjón og geta haldið áfram að senda nafnrýmið til leysisins sem þú varst að skipta út.

Hvar hosts-færsla á heima

Að bæta vistfangi endapunktsins í hosts-skrá er góð greining og léleg hönnun. Það sannar að varpanir nafns á vistfang sé skorturinn og leyfir þér að prófa allt eftir það skref, en það er ósýnilegt fyrir notendum þínum, brotnar þegar vistfang endapunktsins breytist og felur svæðið sem ætti að svara.

Eftirskilin prófunarfærsla er verri en úrelt skyndiminni, því hún getur látið lagfærðu leiðina líta brotna út eða brotnu leiðina líta lagfærða út eftir stefnu villunnar. Fjarlægðu hana fyrir síðustu umferð og leystu aðeins með framleiðsluleysinum.

Stutt nöfn þurfa leitarviðskeyti og fullnöfn gera það ekki, svo prófaðu fullnafnið fyrst og ákveddu síðan hvort vinnuflæðið þurfi viðskeyti sem ýtt er í gegnum biðlarasniðið. Microsoft skjalfestir svæðisnöfn og færsluform fyrir hverja þjónustu í leiðbeiningum sínum um DNS fyrir einkendapunkta; lestu færsluna fyrir þína þjónustu í stað þess að afrita svæði frá annarri.

Tengdir greinar