Pribadong endpoint, parehong pangalan ng server: mga string ng koneksyon sa Azure SQL

Binabago ng Private Link kung saan dumarating ang isang koneksyon, hindi kung ano ang tawag sa koneksyon. Para sa Azure SQL Database, ang pagkakaibang iyon ang buong disenyo: pinapanatili ng lohikal na server ang pangalan nito, at ang pribadong endpoint ay nagbibigay ng network entry kung saan nire-resolve ang pangalan. Ang pagpapalit ng pangalan ng isang IP address ay ang tanging pagbabago na sabay na sumisira sa TLS, mga kredensyal at mga tool. Dalawang string ng koneksyon ay maaaring magmukhang katumbas at kumilos nang lubos na naiiba.

Panatilihin ang orders-db.database.windows.net at bigyan ang kliyente ng pribadong sagot para dito.

Magkaiba ang trabaho ng pangalan at address

Kinikilala ng pangalan ang serbisyo ng SQL, at iyon ang inaasahan ng sertipiko at pag-login. Ang pribadong address ay nagbibigay ng network entry sa loob ng konektadong virtual network. Ang paghahalo ng isa sa isa pa ay lumilikha ng koneksyon na umabot sa isang bagay at hindi nagpapatunay laban sa anuman.

Ang patnubay ng Microsoft para sa Azure SQL ay nangangailangan ng normal na pangalan ng server mula sa mga kliyente. Ang direktang IP, at gayundin ang pangalan na may prefix na privatelink, ay hindi mapagpapalit na target ng pag-login. Ang mga tool na tumatanggap ng IP ay tatanggapin ito at pagkatapos ay mabibigo sa TLS o sa pagpapatunay, na nagtatago ng tunay na pagkakamali. Ang mga pagkabigong iyon ay binabasa na parang mga problema sa kredensyal hanggang sa tingnan mo ang hostname sa error.

Ano ang talagang binabago ng pribadong zone

Ang pribadong DNS zone ay nagtatala ng isang address para sa server sa loob ng namespace na privatelink, at ang zone ay naka-link sa virtual network na dapat gumamit nito. Gumagalaw ang resolution; ang string ng koneksyon ay hindi. Ang hugis sa ibaba ay isang ilustrasyon, hindi isang record na ididikit sa pampublikong zone.

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

Panatilihin ang record na iyon at ang link ng zone nito bilang imprastraktura, may may-ari at petsa ng pagsusuri.

Dalawang zone na may parehong pinagmulan at magkaibang sagot ay normal na huling estado, hindi salungatan. Pinapanatili ng mga pampublikong kliyente ang pampublikong sagot, at ang mga pribadong kliyente ay nakakakuha ng address ng endpoint. Ang failure mode na dapat bantayan ay ang bahagyang pagkalat ng pribadong view, kung saan ang isang subnet ay nire-resolve nang pribado at ang isa ay tahimik na hindi.

Kailangan ng mga kliyente sa labas ng Azure ng landas papunta sa zone na iyon

Ang isang kliyente ng VPN ay nakaupo sa labas ng resolver ng Azure, kaya dapat maabot ang pribadong zone mula sa hybrid na landas. Ang isang Azure DNS forwarder o Azure DNS Private Resolver ay makapaglilingkod sa mga query na dumarating sa network na iyon. Ang patnubay ng Microsoft ay ipasa ang kaugnay na pampublikong service zone sa pamamagitan ng kaayusang iyon sa halip na ipagpalagay na direktang nagtatanong ang mga kliyente sa pangalang privatelink. Ang mga kliyenteng hindi ma-resolve ang pribadong sagot ay tahimik na bumabalik sa pampubliko.

Panatilihing sinadya ang saklaw ng pagpasa, dahil ang pagpapalit ng pampublikong zone na ginagamit ay sumisira sa mga pangalang wala sa kapalit.

Maglaan sa isang pagkakasunod-sunod na nagpapanatili ng pagkakakilanlan

May magkakaibang may-ari ang mga hakbang: likhain at aprubahan ang endpoint, ibigay ang ruta ng VPN, isama ang pribadong DNS, pagkatapos ay i-configure ang kliyente gamit ang normal nitong pangalan ng server. Ang paggawa ng DNS bago ang ruta ay lumilikha ng mga timeout na mukhang pagkabigo ng DNS. Ang paggawa ng kliyente sa huli ay nagpapanatili ng isang variable na gumagalaw sa isang pagkakataon. May sinusunod na resulta ang bawat hakbang, kaya wala sa mga ito ang kailangang subukan sa pamamagitan ng paghula.

Ang konektadong icon ng VPN ay hindi pumipili ng pribadong destinasyon nang mag-isa.

Ano ang hindi pinapatay ng pribadong endpoint

Ang paglikha ng pribadong endpoint ay hindi awtomatikong nagpapahinto sa pampublikong access sa lohikal na server. Iyon ay hiwalay na desisyon sa deployment, at dumarating ito pagkatapos makumpirma na gumagana ang mga inilaan na pribadong kliyente. Panatilihin ang landas ng pagbawi at isaalang-alang ang mga application na gumagamit pa rin ng pampublikong pasukan. Ang pagpapatay muna ng pampublikong access ay ang paraan kung paano nagiging pagkagambala ang isang gumaganang serbisyo na may maayos na audit trail.

Tingnan din kung anong patakaran ng koneksyon ang ginagamit ng server.

Ipinapadala ng Redirect ang kliyente sa isang port sa node pagkatapos ng paunang koneksyon sa gateway, na nagbabago sa dapat pahintulutan ng network ng kliyente. Pinapanatili ng Proxy ang trapiko sa gateway. Ang matagumpay na TCP handshake sa isang port ay hindi ang buong daloy ng pag-login.

Ito ay Azure SQL Database, hindi SQL Managed Instance, na may sariling modelo ng konektibidad at walang katumbas na kuwento ng pribadong endpoint. Sa parehong kaso, panatilihing may magkakaibang label ang tatlong bagay: ang pangalan, ang network entry at ang kredensyal. Ang pagbabago kung saan naglalakbay ang isang koneksyon ay hindi dapat kailanman baguhin kung aling serbisyo ang inaakala ng kliyente na kausap nito.