VPN شما به‌تنهایی Cosmos DB را خصوصی نمی‌کند
VPN لپ‌تاپ شما را به شبکه می‌آورد، نه به داخل پایگاه داده. ببینید نقطه پایانی خصوصی، ناحیه DNS، حالت اتصال و دسترسی حساب چه کاری باید انجام دهند.
لپ‌تاپ را از طریق VPN به VNet متصل می‌کنید، نشانی URL حساب Cosmos DB را باز می‌کنید و درخواست همچنان از اینترنت عمومی خارج می‌شود. تونل کار خود را انجام داد. کاری که نکرد این بود که نقطه پایانی خصوصی ایجاد کند، رکورد DNS خصوصی را منتشر کند یا دسترسی عمومی را خاموش کند، زیرا اینها سه تغییر جداگانه در حساب هستند، نه ویژگی‌های اتصال شبکه شما. این مثال از Azure Cosmos DB برای NoSQL، یک نقطه پایانی خصوصی در یک VNet و لپ‌تاپی استفاده می‌کند که از طریق VPN به آن VNet متصل است و نشانی برنامه را بدون تغییر نگه می‌دارد.
افسانه: بودن روی VPN پایگاه داده را خصوصی می‌کند
بودن روی VNet فقط یعنی بسته‌های شما می‌توانند به نشانی‌های خصوصی در آن VNet برسند. این هیچ چیزی درباره اینکه نام حساب کجا حل می‌شود نمی‌گوید و هیچ چیزی درباره اینکه حساب هنوز ترافیک عمومی را می‌پذیرد نمی‌گوید.
نقطه پایانی خصوصی یک منبع جداگانه با نشانی خودش، مرحله تأیید خودش و سیم‌کشی DNS خودش است. تا زمانی که وجود نداشته باشد و تأیید نشود، نام به نقطه پایانی عمومی حل می‌شود و ترافیک شما بدون توجه به تونل به آنجا می‌رود.
چه چیزی در واقع باعث حل خصوصی نام می‌شود
نقطه پایانی معمول حساب در SDK را نگه دارید، چیزی مانند https://ACCOUNT.documents.azure.com. DNS خصوصی باید آن نام را از طریق زنجیره Private Link به نشانی‌های خصوصی نقطه پایانی حل کند. آن را با یک URL عددی جایگزین نکنید و بررسی‌های گواهی را غیرفعال نکنید، زیرا این کار یک مشکل DNS را با یک مشکل امنیتی عوض می‌کند.
| Example choice | Value |
|---|---|
| Cosmos API | NoSQL |
| Private endpoint subresource | Sql |
| Private DNS zone | privatelink.documents.azure.com |
| SDK connection mode | Gateway |
آن مقادیر مخصوص API NoSQL هستند. دیگر APIهای Cosmos در همان مثال ورودی‌های قابل تعویض نیستند و کپی کردن نام زیرمنبع از یک API متفاوت نقطه پایانی‌ای تولید می‌کند که هرگز حل نمی‌شود.
نقطه پایانی را از طریق گردش کار مجاز Azure ایجاد و تأیید کنید، سپس از یکپارچگی گروه ناحیه DNS خصوصی آن استفاده کنید. لپ‌تاپ به یک حل‌کننده نیاز دارد که بتواند برای آن ناحیه پاسخ دهد، چه مستقیم و چه از طریق ارسال مجاز، و یک مسیر کلاینت VPN به هر نشانی مرتبط نقطه پایانی.
یک نقطه پایانی خصوصی می‌تواند بیش از یک نشانی داشته باشد، از جمله ورودی‌های جهانی و منطقه‌ای. وقتی مناطق حساب تغییر می‌کنند یکپارچگی DNS را حفظ کنید، به جای اینکه یک نشانی را در فایل hosts ثابت کنید، و به یاد داشته باشید که پاسخ یک حل‌کننده عمومی نامرتبط هیچ چیزی درباره مسیر خصوصی اثبات نمی‌کند. اگر DNS را از طریق یک هاب ارسال می‌کنید، پیش از عیب‌یابی کلاینت تأیید کنید که ارسال‌کننده پاسخ می‌دهد. یک ارسال‌کننده کهنه پاسخ عمومی را برمی‌گرداند، که دقیقاً مانند یک نقطه پایانی گمشده به نظر می‌رسد.
حالت Gateway و حالت Direct قابل تعویض نیستند
حالت Gateway درخواست‌های سرویس را از طریق HTTPS روی TCP 443 می‌فرستد. به همین دلیل یک سیاست فایروال فقط برای 443 با آن کار می‌کند و به همین دلیل این مثال آن را آگاهانه انتخاب می‌کند.
حالت Direct از طریق Private Link نیازمندی‌های اتصال متفاوتی دارد، از جمله محدوده گسترده‌تر پورت TCP که مستندات حساب فهرست می‌کند. سیاستی که برای حالت Gateway نوشته شده نباید بی‌صدا برای کلاینت حالت Direct دوباره استفاده شود، وگرنه SDK متصل می‌شود و سپس در نخستین عملیات داده معلق می‌ماند.
یک حالت را انتخاب کنید، آن را همراه حساب بنویسید و سیاست شبکه را با آن هماهنگ کنید. تیم‌هایی که هنگام عیب‌یابی حالت را عوض می‌کنند معمولاً به مجموعه قواعد فایروالی می‌رسند که هیچ‌کدام را برآورده نمی‌کند.
خاموش کردن دسترسی عمومی یک کلید جداگانه است
اگر حساب باید فقط خصوصی باشد، دسترسی شبکه عمومی را از طریق تنظیم پشتیبانی‌شده حساب غیرفعال کنید و نتیجه را بررسی کنید. وجود یک نقطه پایانی خصوصی را تصمیم کامل دسترسی ندانید، زیرا حسابی با نقطه پایانی خصوصی و دسترسی عمومی فعال همچنان در اینترنت پاسخ می‌دهد.
هم از بیرون VPN و هم از داخل بررسی کنید. درخواست از شبکه‌ای که باید کنار گذاشته شود، آزمونی است که اثبات می‌کند تنظیم اعمال شده است و همان آزمونی است که بیشتر پنجره‌های تغییر از آن صرف‌نظر می‌کنند.
دسترسی‌پذیری مجوز نیست
یک عملیات SDK مجاز از لپ‌تاپ VPN آزمون پذیرش است، با استفاده از URL معمول حساب و هویت مورد نظر. دسترسی‌پذیری VPN مجوزهای داده Cosmos را نمی‌دهد؛ لایه داده نقش‌ها یا کلیدهای خودش را بررسی می‌کند.
سپس ردها را اجرا کنید: هویتی متفاوت و مسیری شبکه که دیگر نباید به حساب برسد. اگر هر کدام موفق شود، مرزی که مستند کرده‌اید همان مرزی نیست که ساخته‌اید.
پس از پایان چهار واقعیت را بنویسید: نشانی‌های خصوصی نقطه پایانی، ناحیه‌ای از DNS که برای نام حساب پاسخ می‌دهد، حالت اتصال با نیازمندی‌های پورتش و اینکه آیا دسترسی عمومی غیرفعال است. این چهار مورد راه‌اندازی را برای نفر بعدی توضیح می‌دهند و هر یک به‌طور مستقل شکست می‌خورد.