Via VPN ne mem faras Cosmos DB privata
VPN alportas vian tekkomputilon en la reton, ne en la datumbazon. Vidu, kion devas fari la privata finpunkto, la DNS-zono, la konekta reĝimo kaj la kontaliro.
Vi konektas la tekkomputilon al la VNet per VPN, malfermas la URL-on de la Cosmos DB-konto, kaj la peto ankoraŭ eliras tra la publika interreto. La tunelo faris sian taskon. Kion ĝi ne faris, estas krei privatan finpunkton, publikigi la privatan DNS-rikordon aŭ malŝalti publikan aliron, ĉar tiuj estas tri apartaj ŝanĝoj al la konto, ne ecoj de via reta konekto. Ĉi tiu ekzemplo uzas Azure Cosmos DB por NoSQL, privatan finpunkton en VNet kaj tekkomputilon konektitan al tiu VNet per VPN, kaj ĝi konservas la adreson de la aplikaĵo senŝanĝa.
La mito: esti en la VPN faras la datumbazon privata
Esti en la VNet nur signifas, ke viaj pakaĵoj povas atingi privatajn adresojn en tiu VNet. Ĝi diras nenion pri tio, kie la konto-nomo solviĝas, kaj ĝi diras nenion pri tio, ĉu la konto ankoraŭ akceptas publikan trafikon.
Privata finpunkto estas aparta rimedo kun propra adreso, propra aproba paŝo kaj propra DNS-kablado. Ĝis ĝi ekzistos kaj estos aprobita, la nomo solviĝas al la publika finpunkto kaj via trafiko iras tien sendepende de la tunelo.
Kio efektive igas la nomon solviĝi private
Konservu la normalan konto-finpunkton de la SDK, io kiel https://ACCOUNT.documents.azure.com. Privata DNS devus solvi tiun nomon tra la Private Link-ĉeno al la privataj adresoj de la finpunkto. Ne anstataŭigu ĝin per numera URL kaj ne malŝaltu atestilajn kontrolojn, ĉar tio interŝanĝas DNS-problemon kontraŭ sekurecproblemo.
| Example choice | Value |
|---|---|
| Cosmos API | NoSQL |
| Private endpoint subresource | Sql |
| Private DNS zone | privatelink.documents.azure.com |
| SDK connection mode | Gateway |
Tiuj valoroj estas specifaj por la NoSQL API. Aliaj Cosmos API-oj ne estas interŝanĝeblaj eroj en la sama ekzemplo, kaj kopii la subresursan nomon de malsama API produktas finpunkton, kiu neniam solviĝas.
Kreu kaj aprobu la finpunkton per la rajtigita Azure-laborfluo, poste uzu ĝian integriĝon kun privata DNS-zongrupo. La tekkomputilo bezonas solvilon, kiu povas respondi por tiu zono, ĉu rekte ĉu per aprobita plusendado, kaj VPN-klientan itineron al ĉiu koncerna finpunkta adreso.
Privata finpunkto povas havi pli ol unu adreson, inkluzive tutmondajn kaj regionajn erojn. Prizorgu la DNS-integriĝon kiam la regionoj de la konto ŝanĝiĝas anstataŭ fiksi unu adreson en hosts-dosiero, kaj memoru, ke respondo de nerilata publika solvilo pruvas nenion pri la privata vojo. Se vi plusendas DNS tra hubo, konfirmu, ke la plusendilo respondas antaŭ ol sencimigi la klienton. Malnova plusendilo redonas la publikan respondon, kio aspektas ĝuste kiel mankanta finpunkto.
La Gateway-reĝimo kaj la Direct-reĝimo ne estas interŝanĝeblaj
La Gateway-reĝimo sendas servopetojn per HTTPS sur TCP 443. Tial fajroŝirma politiko nur por 443 funkcias por ĝi kaj tial ĉi tiu ekzemplo elektas ĝin intence.
La Direct-reĝimo tra Private Link havas malsamajn konektajn postulojn, inkluzive pli larĝan TCP-pordan intervalon, kiun listigas la konta dokumentaro. Politiko skribita por la Gateway-reĝimo ne rajtas esti silente reuzata por kliento en Direct-reĝimo, alie la SDK konektiĝos kaj poste pendos ĉe la unua datuma operacio.
Elektu unu reĝimon, skribu ĝin kun la konto, kaj igi la retan politikon kongrui kun ĝi. Teamoj, kiuj ŝanĝas reĝimojn dum problemosolvado, kutime finas kun fajroŝirma regulkompleto, kiu kontentigas nek unu nek la alian.
Malŝalti publikan aliron estas aparta ŝaltilo
Se la konto devas esti nur privata, malŝaltu publikan retan aliron per la subtenata agordo de la konto kaj kontrolu la rezulton. Ne traktu la ekziston de privata finpunkto kiel la kompletan alirdokumenton, ĉar konto kun privata finpunkto kaj ŝaltita publika aliro ankoraŭ respondas en la interreto.
Kontrolu de ekster la VPN kaj ankaŭ de interne. Peto de reto, kiu devus esti ekskludita, estas la testo, kiu pruvas, ke la agordo efektiviĝis, kaj ĝi estas la testo, kiun plej multaj ŝanĝfenestroj preterlasas.
Atingeblo ne estas permeso
Permesita SDK-operacio de la VPN-tekkomputilo estas la akcepta testo, uzante la normalan konto-URL-on kaj la celitan identecon. VPN-atingeblo ne donas Cosmos-datumpermesojn; la datuma ebeno kontrolas siajn proprajn rolojn aŭ ŝlosilojn.
Poste rulu la rifuzojn: alian identecon kaj retan vojon, kiu ne plu devus atingi la konton. Se iu el ili sukcesas, la limo, kiun vi dokumentis, ne estas la limo, kiun vi konstruis.
Skribu kvar faktojn kiam vi finos: la privatajn adresojn de la finpunkto, la DNS-zonon, kiu respondas por la konto-nomo, la konektan reĝimon kun ĝiaj pordaj postuloj, kaj ĉu publika aliro estas malŝaltita. Tiuj kvar klarigas la agordon al la sekva persono, kaj ĉiu el ili malsukcesas sendepende.