Hindi ginagawang pribado ng VPN mo ang Cosmos DB nang mag-isa

Ikinokonekta mo ang laptop sa VNet sa pamamagitan ng VPN, binubuksan ang URL ng account ng Cosmos DB, at lumalabas pa rin ang kahilingan sa pampublikong internet. Nagawa ng tunnel ang trabaho nito. Ang hindi nito nagawa ay lumikha ng pribadong endpoint, maglathala ng pribadong DNS record o patayin ang pampublikong access, dahil tatlong hiwalay na pagbabago sa account ang mga iyon, hindi mga katangian ng iyong koneksyon sa network. Gumagamit ang halimbawang ito ng Azure Cosmos DB para sa NoSQL, pribadong endpoint sa isang VNet at laptop na konektado sa VNet na iyon sa pamamagitan ng VPN, at pinapanatili nitong hindi nagbabago ang address ng application.

Ang mito: ang pagiging nasa VPN ay ginagawang pribado ang database

Ang pagiging nasa VNet ay nangangahulugan lamang na maaabot ng iyong mga packet ang mga pribadong address sa VNet na iyon. Wala itong sinasabi tungkol sa kung saan nire-resolve ang pangalan ng account, at wala rin itong sinasabi tungkol sa kung tumatanggap pa ang account ng pampublikong trapiko.

Ang pribadong endpoint ay isang hiwalay na resource na may sariling address, sariling hakbang sa pag-apruba at sariling DNS wiring. Hanggang sa umiral ito at maaprubahan, nire-resolve ang pangalan sa pampublikong endpoint at pumupunta doon ang trapiko mo anuman ang tunnel.

Ano ba talaga ang nagpaparesolve ng pangalan nang pribado

Panatilihin ang normal na account endpoint ng SDK, tulad ng https://ACCOUNT.documents.azure.com. Dapat i-resolve ng pribadong DNS ang pangalang iyon sa pamamagitan ng Private Link chain patungo sa mga pribadong address ng endpoint. Huwag itong palitan ng numeric na URL at huwag patayin ang mga pagsusuri ng certificate, dahil ipinagpapalit nito ang problema sa DNS sa problema sa seguridad.

Ang mga halagang iyon ay partikular sa NoSQL API. Ang iba pang Cosmos API ay hindi mapagpapalit na entry sa parehong halimbawa, at ang pagkopya ng pangalan ng subresource mula sa ibang API ay gumagawa ng endpoint na hindi kailanman nire-resolve.

Lumikha at aprubahan ang endpoint sa pamamagitan ng awtorisadong Azure workflow, pagkatapos ay gamitin ang integrasyon nito sa pribadong DNS zone group. Kailangan ng laptop ng resolver na makakasagot para sa zone na iyon, nang direkta o sa pamamagitan ng aprubadong forwarding, at ruta ng VPN client patungo sa bawat kaugnay na address ng endpoint.

Ang pribadong endpoint ay maaaring may higit sa isang address, kabilang ang global at regional na entry. Panatilihin ang integrasyon ng DNS kapag nagbago ang mga rehiyon ng account sa halip na i-pin ang isang address sa hosts file, at tandaan na ang sagot mula sa walang kaugnayang pampublikong resolver ay walang pinapatunayan tungkol sa pribadong landas. Kung nagfo-forward ka ng DNS sa pamamagitan ng hub, kumpirmahin na sumasagot ang forwarder bago i-debug ang client. Ang lumang forwarder ay nagbabalik ng pampublikong sagot, na eksaktong mukhang nawawalang endpoint.

Ang Gateway mode at Direct mode ay hindi mapagpapalit

Ang Gateway mode ay nagpapadala ng mga kahilingan sa serbisyo sa HTTPS sa TCP 443. Iyon ang dahilan kung bakit gumagana rito ang patakaran ng firewall para sa 443 lamang at iyon ang dahilan kung bakit sinasadya itong pinipili ng halimbawang ito.

Ang Direct mode sa Private Link ay may iba't ibang pangangailangan sa konektibidad, kabilang ang mas malawak na hanay ng TCP port na nakalista sa dokumentasyon ng account. Ang patakarang isinulat para sa Gateway mode ay hindi dapat tahimik na gamitin muli para sa client na nasa Direct mode, kung hindi ay kokonekta ang SDK at pagkatapos ay mag-hang sa unang operasyon ng data.

Pumili ng isang mode, isulat ito kasama ng account, at gawing tugma ang patakaran ng network. Ang mga team na nagpapalit ng mode habang nag-aayos ng problema ay karaniwang nauuwi sa set ng firewall rule na hindi nakakasapat sa alinman.

Ang pagpatay ng pampublikong access ay hiwalay na switch

Kung dapat na pribado lamang ang account, patayin ang pampublikong network access sa pamamagitan ng sinusuportahang setting ng account at i-verify ang resulta. Huwag ituring ang pagkakaroon ng pribadong endpoint bilang kumpletong desisyon sa access, dahil ang account na may pribadong endpoint at naka-enable na pampublikong access ay sumasagot pa rin sa internet.

I-verify mula sa labas ng VPN gayundin mula sa loob. Ang kahilingan mula sa network na dapat na hindi kasama ay ang pagsubok na nagpapatunay na nagkabisa ang setting, at ito ang pagsubok na nilalaktawan ng karamihan sa mga window ng pagbabago.

Ang maabot ay hindi pahintulot

Ang pinapayagang operasyon ng SDK mula sa VPN laptop ay ang acceptance test, gamit ang normal na URL ng account at ang inaasahang pagkakakilanlan. Ang maabot sa pamamagitan ng VPN ay hindi nagbibigay ng mga pahintulot sa data ng Cosmos; sinusuri ng data plane ang sarili nitong mga role o key.

Pagkatapos ay patakbuhin ang mga pagtanggi: ibang pagkakakilanlan, at landas ng network na hindi na dapat umabot sa account. Kung magtagumpay ang alinman, ang hangganang idinokumento mo ay hindi ang hangganang itinayo mo.

Isulat ang apat na katotohanan kapag tapos ka na: ang mga pribadong address ng endpoint, ang DNS zone na sumasagot para sa pangalan ng account, ang mode ng koneksyon kasama ang mga pangangailangan nito sa port at kung patay ang pampublikong access. Ipinapaliwanag ng apat na ito ang setup sa susunod na tao, at bawat isa sa kanila ay nabigo nang mag-isa.