Azure P2S VPN ei voi selvittää yksityisen päätepisteen nimeä

Yhdistät point-to-site-tunneliin, pingaat yksityistä osoitetta, avaat sovelluksen ja saat sen sijaan 403:n tai sertifikaattivirheen. Molemmat oireet viittaavat DNS:ään, mutta ne ovat eri vikoja: toinen tarkoittaa, että asiakas selvitti julkisen osoitteen, toinen, että se selvitti yksityisen osoitteen ja tarjosi sitten nimen, jota sertifikaatti ei kata. Käy alla olevat tarkistukset järjestyksessä ja pysähdy ensimmäiseen epäonnistumiseen, sillä hosts-merkintä tai välimuistiin jäänyt vastaus voi saada jokaisen myöhemmän tarkistuksen onnistumaan väärästä syystä. Pidän tätä järjestystä tekstitiedostossa VPN-profiilieni vieressä, koska korjaus ei muuta tunnelista mitään ja muuttaa kaiken siinä, mitä asiakas tietää.

Aloita osoitteesta, jonka asiakas todella saa

Kysy ratkaisijalta suoraan sen sijaan, että luottaisit sovellukseen. Windowsissa nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net näyttää, minkä näkymän asiakas sai. Julkinen vastaus tarkoittaa, ettei mikään alempana saavuta päätepistettä; päätepisteen yksityinen osoite tarkoittaa, että DNS on valmis ja seuraava tarkistus on itse yhteys.

Yksityinen päätepiste ei nimeä palvelua uudelleen. Tili tai sovellus säilyttää tavallisen täysin kvalifioidun nimensä, ja päätepiste muuttaa vain sitä osoitetta, johon nimi ratkeaa virtuaaliverkon sisäisille asiakkaille. Siksi sama isäntänimi ratkeaa yksityisesti verkon VM:stä ja julkisesti kannettavasta, jolle ei koskaan annettu yksityistä näkymää.

Tarkista vyöhyke, sen linkki ja tietue ennen tunnelia

Kolmen ehdon on täytyttävä yhtä aikaa: yksityinen vyöhyke on olemassa, se on linkitetty virtuaaliverkkoon, johon VPN-yhdyskäytävä ja asiakkaat tulevat Azureen, ja siinä on päätepisteen A-tietue, joka osoittaa yksityiseen osoitteeseen. Linkitä vyöhyke asiaankuulumattomaan verkkoon, ja yhdyskäytävä ratkaisee edelleen julkista tietuetta, kun taas tunnelin kaikki näyttää terveeltä.

Vyöhykkeiden nimet kuuluvat palveluille, eivät yleisesti yksityisille linkeille. App Service käyttää yleensä privatelink.azurewebsites.net:tä, tallennuksella ja SQL:llä on omat nimiavaruutensa, ja toisen palvelun vyöhykkeen lainaaminen tuottaa vyöhykkeen, joka on olemassa eikä vastaa mitään hyödyllistä.

Anna asiakkaalle ratkaisija, jonka se todella tavoittaa

168.63.129.16 vastaa Azuren virtuaalikoneista eikä ole DNS-palvelin point-to-site-tunnelin toisella puolella olevalle kannettavalle. Asiakas tarvitsee tunnelin kautta tavoitettavan ratkaisijan: Azure DNS Private Resolverin saapuvan päätepisteen, virtuaaliverkon sisäisen välittäjän tai VPN-asiakasprofiilissa kuljetettavat DNS-palvelinmerkinnät, jotta asiakas kysyy virtuaaliverkkoa suoraan.

Määritetty mutta tavoittamaton ratkaisija käyttäytyy täsmälleen kuin ratkaisijaa ei olisi, ja oire on aikakatkaisu eikä väärä vastaus, minkä vuoksi se luetaan virheellisesti palomuuriongelmaksi. Testaa sitä kyselyllä, jonka tunneli on tarkoitettu kuljettamaan, ei julkisella nimellä, joka olisi onnistunut paikallisen linkin kautta joka tapauksessa.

Jos välität etkä työnnä asetuksia, välitä nimiavaruus, jonka yksityinen vyöhyke omistaa, privatelink.azurewebsites.net eikä koko azurewebsites.net. Ehdollinen välittäjä, joka nielee koko ylätason suffiksin, lähettää jokaisen palvelun haun Azureen, mukaan lukien ne, joiden pitäisi pysyä paikallisina.

Käytä nimeä, jolle sertifikaatti myönnettiin

Kun osoite on oikein, toinen vika tulee esiin. Tallennus ja App Service julkaisevat privatelink-aliaksen, eikä tämä alias ole välttämättä sertifikaatin nimi. AzCopy-lataus osoitteeseen privatelink.blob.core.windows.net ei läpäissyt validointia; sama lataus osoitteeseen <account>.blob.core.windows.net/<container> ratkesi yksityiseen osoitteeseen ja meni läpi, joten se pysyi yksityisellä polulla ilman ohitusta.

Sääntö pätee selaimessa ja myös App Servicessä: yhdistä isäntänimellä, jonka sertifikaatti kattaa, ja anna DNS:n tarjota yksityinen osoite. Älä turvaudu validoinnin ohitukseen, sillä se muuttaa nimeämisvirheen tietoturvaregressioksi. Onnistunut ping todistaa reitin eikä kerro mitään kättelyn sisäisestä nimestä, siksi nämä pysyvät erillisinä tarkistuksina.

Neljän vaiheen järjestys, joka eristää jokaisen kerroksen

1. Vahvista, että VPN-asiakkaalla on osoite point-to-site-altaasta ja reitti päätepisteen yksityiseen osoitteeseen.
2. Ratkaise täsmällinen nimi, jota sovellus käyttää, ja vertaa vastausta päätepisteen osoitteeseen.
3. Avaa TCP-yhteys päätepisteeseen palvelun portissa ja lue sitten kyseisessä yhteydessä esitetty sertifikaatin nimi.
4. Testaa valtuutus vasta nyt, sillä toimiva polku ja kelvollinen sertifikaatti eivät vielä anna pääsyä resurssiin.

Hylätty yhteys oikean osoitteen aikana viittaa verkon suojaustyhmään tai yksityisen päätepisteen yhteyden tilaan, ei DNS:ään, joten tarkista ne ennen kuin muokkaat ratkaisijan asetuksia uudelleen. TLS-nimen epäsuhta lähettää sinut takaisin URL:n isäntänimeen ja sertifikaatin subjectiin. Pidä ratkaisun tuloste, sertifikaatin nimi ja tarkka URL yhdessä; nämä kolme arvoa selittävät useimmat näistä tapauksista koskematta yhdyskäytävään.

Käytä virtuaaliverkon sisäistä VM:ää kontrollina. Jos nimi ratkeaa siellä yksityisesti ja tunnelista julkisesti, vyöhyke ja tietue ovat oikein ja ainoa ero on asiakkaan ratkaisijapolku, mikä vahvistetaan nopeammin kuin uusi kierros päätepisteen kokoonpanossa.

Asiakkaat myös välimuistittavat. Tietue, joka vastasi julkisesti kymmenen minuuttia sitten, vastaa edelleen, kun olet korjannut vyöhykkeen, joten tyhjennä välimuisti ennen uutta testiä. Windowsissa ipconfig /flushdns tyhjentää asiakkaan välimuistin; nimien ratkaisukäytännön säännöt säilyvät, päättävät mikä suffiksi menee millekin palvelimelle ja voivat lähettää nimiavaruuden edelleen juuri korvaamallesi ratkaisijalle.

Minne hosts-merkintä kuuluu

Päätepisteen osoitteen lisääminen hosts-tiedostoon on hyvä diagnoosi ja huono suunnittelu. Se todistaa, että nimen ja osoitteen yhdistäminen on puuttuva pala, ja antaa testata kaiken sen vaiheen jälkeen, mutta se on käyttäjillesi näkymätön, hajoaa kun päätepisteen osoite muuttuu, ja kätkee vyöhykkeen, jonka pitäisi vastata.

Jäljelle jäänyt testimerkintä on pahempi kuin vanhentunut välimuisti, koska se voi saada korjatun polun näyttämään rikkinäiseltä tai rikkinäisen polun korjatulta virheen suunnasta riippuen. Poista se ennen viimeistä kierrosta ja ratkaise vain tuotantoratkaisijalla.

Lyhyet nimet tarvitsevat hakuperäliitteen eivätkä täysin kvalifioidut nimet, joten testaa ensin täysin kvalifioitu nimi ja päätä sitten, tarvitseeko työnkulku asiakasprofiilin kautta työnnettävää suffiksia. Microsoft dokumentoi vyöhykkeiden nimet ja tietueiden muodot palvelukohtaisesti yksityisten päätepisteiden DNS-ohjeissaan; lue oman palvelusi merkintä sen sijaan, että kopioisit vyöhykkeen toisesta.