Yksityinen päätepiste, sama palvelimen nimi: Azure SQL -yhteysmerkkijonot

Private Link muuttaa sitä, mihin yhteys saapuu, ei sitä, miksi yhteyttä kutsutaan. Azure SQL Databasen kohdalla tämä ero on koko suunnittelu: looginen palvelin säilyttää nimensä, ja yksityinen päätepiste tarjoaa verkkotietueen, johon nimi ratkaistaan. Nimen korvaaminen IP-osoitteella on ainoa muutos, joka rikkoo TLS:n, tunnistetiedot ja työkalut samalla kertaa. Kaksi yhteysmerkkijonoa voi näyttää samanlaiselta ja käyttäytyä täysin eri tavoin.

Säilytä orders-db.database.windows.net ja anna asiakkaalle yksityinen vastaus sitä varten.

Nimellä ja osoitteella on eri tehtävät

Nimi yksilöi SQL-palvelun, ja sitä sertifikaatti ja kirjautuminen odottavat. Yksityinen osoite tarjoaa verkkotietueen yhdistetyn virtuaaliverkon sisällä. Toisen sekoittaminen toiseen tuottaa yhteyden, joka saavuttaa jotain mutta ei todentaudu mihinkään.

Microsoftin Azure SQL -ohje edellyttää asiakkailta tavallista palvelimen nimeä. Suora IP ja samoin privatelink-etuliitteinen nimi ei ole vaihdettava kirjautumiskohde. Työkalut, jotka hyväksyvät IP:n, hyväksyvät sen ja epäonnistuvat sitten TLS:ssä tai todentamisessa, mikä peittää varsinaisen virheen. Nämä virheet luetaan tunnistetieto-ongelmiksi, kunnes katsot virheessä olevaa isäntänimeä.

Mitä yksityinen vyöhyke oikeastaan muuttaa

Yksityinen DNS-vyöhyke tallentaa yhden osoitteen palvelimelle privatelink-nimiavaruudessa, ja vyöhyke on linkitetty virtuaaliverkkoon, jonka sitä pitäisi käyttää. Ratkaisu siirtyy; yhteysmerkkijono ei. Alla oleva muoto on havainnollistus, ei tietue liitettäväksi julkiseen vyöhykkeeseen.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

Ylläpidä tätä tietuetta ja sen vyöhykelinkkiä infrastruktuurina, omistajan ja tarkistuspäivän kanssa.

Kaksi vyöhykettä, joilla on sama alkuperä ja eri vastaukset, on normaali lopputila, ei ristiriita. Julkiset asiakkaat pitävät julkisen vastauksen, ja yksityiset asiakkaat saavat päätepisteen osoitteen. Seurattava vikatila on yksityisen näkymän osittainen leviäminen, jossa yksi aliverkko ratkeaa yksityisesti ja toinen hiljaa ei.

Azure:n ulkopuoliset asiakkaat tarvitsevat reitin tälle vyöhykkeelle

VPN-asiakas istuu Azure:n ratkaisijan ulkopuolella, joten yksityisen vyöhykkeen on oltava saavutettavissa hybridireitiltä. Azure DNS -välittäjä tai Azure DNS Private Resolver voi palvella kyselyitä, jotka saapuvat tuon verkon kautta. Microsoftin ohje on välittää asianomainen julkinen palveluvyöhyke tuon järjestelyn kautta sen sijaan, että oletettaisiin asiakkaiden kysyvän nimeä privatelink suoraan. Asiakkaat, jotka eivät pysty ratkaisemaan yksityistä vastausta, putoavat hiljaa takaisin julkiseen.

Pidä välityksen laajuus tarkoituksellisena, koska käytössä olevan julkisen vyöhykkeen korvaaminen rikkoo nimiä, joita korvaava ei sisällä.

Tarjoa järjestyksessä, joka pitää identiteetin kiinteänä

Vaiheilla on erilliset omistajat: luo ja hyväksy päätepiste, tarjoa VPN-reitti, integroi yksityinen DNS ja määritä sitten asiakas sen tavallisella palvelinnimellä. DNS:n tekeminen ennen reittiä tuottaa aikakatkaisuja, jotka näyttävät DNS-virheiltä. Asiakkaan tekeminen viimeisenä pitää yhden muuttujan liikkeessä kerrallaan. Jokaisella vaiheella on havaittava tulos, joten yhtäkään ei tarvitse testata arvaamalla.

Yhdistetty VPN-kuvake ei valitse yksityistä kohdetta itsestään.

Mitä yksityinen päätepiste ei kytke pois

Yksityisen päätepisteen luominen ei automaattisesti poista julkista pääsyä loogiselle palvelimelle. Se on erillinen käyttöönottopäätös, ja se kuuluu sen jälkeen, kun aiottujen yksityisten asiakkaiden on vahvistettu toimivan. Pidä palautumisreitti ja ota huomioon sovellukset, jotka käyttävät yhä julkista sisäänkäyntiä. Julkisen pääsyn kytkeminen pois ensin on tapa, jolla toimiva palvelu muuttuu katkokseksi siistillä auditointijäljellä.

Tarkista myös, mitä yhteyskäytäntöä palvelin käyttää.

Redirect lähettää asiakkaan solmun porttiin yhdyskäytäväyhteyden jälkeen, mikä muuttaa sitä, mitä asiakasverkon on sallittava. Proxy pitää liikenteen yhdyskäytävällä. Onnistunut TCP-kättely yhdessä portissa ei ole koko kirjautumistyönkulku.

Tämä on Azure SQL Database, ei SQL Managed Instance, jolla on oma yhteysmallinsa eikä vastaavaa yksityisen päätepisteen tarinaa. Kummassakin tapauksessa pidä kolme asiaa erikseen merkittyinä: nimi, verkkotietue ja tunnistetieto. Sen muuttaminen, mihin yhteys matkustaa, ei saisi koskaan muuttaa sitä, minkä palvelun kanssa asiakas uskoo puhuvansa.