Private Link muudab seda, kuhu ühendus jõuab, mitte seda, kuidas ühendust nimetatakse. Azure SQL Database'i puhul on see erinevus kogu disain: loogiline server säilitab oma nime ja privaatne lõpp-punkt pakub võrgukirje, millele nimi lahendatakse. Nime asendamine IP-aadressiga on ainus muudatus, mis rikub korraga TLS-i, volitused ja tööriistad. Kaks ühendusstringi võivad tunduda samaväärsed ja käituda täiesti erinevalt.

Hoidke orders-db.database.windows.net alles ja andke kliendile selle jaoks privaatne vastus.

Nimel ja aadressil on erinevad tööd

Nimi identifitseerib SQL-teenuse ja seda ootavad sertifikaat ning sisselogimine. Privaatne aadress pakub võrgukirje ühendatud virtuaalvõrgu sees. Ühe segamine teisega annab ühenduse, mis jõuab millenigi ja ei autendi millegi vastu.

Microsofti Azure SQL-i juhis nõuab klientidelt tavalist serverinime. Otsene IP, samuti privatelink eesliitega nimi, ei ole vahetatav sisselogimissihtmärk. Tööriistad, mis IP-d aktsepteerivad, võtavad selle vastu ja ebaõnnestuvad seejärel TLS-i või autentimise juures, mis varjab tegeliku vea. Need tõrked loetakse volituste probleemidena, kuni vaatate veas olevat hostinime.

Mida privaatne tsoon tegelikult muudab

Privaatne DNS-tsoon salvestab serverile ühe aadressi nimeruumis privatelink ja tsoon on lingitud virtuaalvõrguga, mis peaks seda kasutama. Lahendamine liigub; ühendusstring mitte. Allpool olev kuju on illustratsioon, mitte kirje, mida avalikku tsooni kleepida.

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

Hoidke seda kirjet ja selle tsooni-linki infrastruktuurina, omaniku ja ülevaatamiskuupäevaga.

Kaks sama päritoluga ja erinevate vastustega tsooni on normaalne lõppseisund, mitte konflikt. Avalikud kliendid hoiavad avalikku vastust ja privaatsed kliendid saavad lõpp-punkti aadressi. Tõrkerežiim, mida jälgida, on privaatse vaate osaline levik, kus üks alavõrk lahendatakse privaatselt ja teine vaikselt mitte.

Azure'ist väljaspool olevad kliendid vajavad pääsu sellesse tsooni

VPN-klient asub Azure'i lahendajast väljaspool, seega peab privaatne tsoon olema hübriidteelt kättesaadav. Azure DNS-i edastaja või Azure DNS Private Resolver saab teenindada päringuid, mis saabuvad läbi selle võrgu. Microsofti juhis on edastada asjakohane avalik teenusetsoon selle korralduse kaudu, mitte eeldada, et kliendid päriselt küsivad nime privatelink. Kliendid, kes ei suuda privaatset vastust lahendada, langevad vaikselt tagasi avalikule.

Hoidke edastamise ulatus teadlikult, sest kasutusel oleva avaliku tsooni asendamine rikub nimesid, mida asendus ei sisalda.

Varustage järjekorras, mis hoiab identiteedi paigal

Sammudel on eraldi omanikud: looge ja kinnitage lõpp-punkt, tagage VPN-marsruut, integreerige privaatne DNS ja seejärel seadistage klient oma tavalise serverinimega. DNS-i tegemine enne marsruuti tekitab ajalõppe, mis näevad välja nagu DNS-i tõrked. Kliendi tegemine viimasena hoiab korraga liikumas ühe muutuja. Igal sammul on vaadeldav tulemus, seega ei pea ühtki neist oletustega testima.

Ühendatud VPN-i ikoon ei vali iseenesest privaatset sihtmärki.

Mida privaatne lõpp-punkt välja ei lülita

Privaatse lõpp-punkti loomine ei keela automaatselt avalikku juurdepääsu loogilisele serverile. See on eraldi juurutamisotsus ja see kuulub pärast seda, kui kavandatud privaatsed kliendid on kinnitatud töötavatena. Hoidke taastamistee ja arvestage rakendustega, mis kasutavad endiselt avalikku sissepääsu. Avaliku juurdepääsu esimesena väljalülitamine on viis, kuidas töötav teenus muutub korraliku auditijäljega katkestuseks.

Kontrollige ka, millist ühenduspoliitikat server kasutab.

Redirect saadab kliendi pärast esialgset lüüsiühendust sõlme pordile, mis muudab seda, mida kliendivõrk peab lubama. Proxy hoiab liiklust lüüsil. Ühe pordi õnnestunud TCP käepigistus ei ole kogu sisselogimisvoog.

See on Azure SQL Database, mitte SQL Managed Instance, millel on oma ühenduvusmudel ja millel pole samaväärset privaatse lõpp-punkti lugu. Mõlemal juhul hoidke kolme asja eraldi märgistatuna: nimi, võrgukirje ja volitus. Muutmine, kuhu ühendus liigub, ei tohiks kunagi muuta seda, millise teenusega klient arvab rääkivat.

Seotud artiklid