VPN ของคุณไม่ได้ทำให้ Cosmos DB เป็นส่วนตัวโดยลำพัง

คุณเชื่อมต่อแล็ปท็อปเข้ากับ VNet ผ่าน VPN เปิด URL ของบัญชี Cosmos DB และคำขอยังคงออกผ่านอินเทอร์เน็ตสาธารณะ อุโมงค์ทำหน้าที่ของมันแล้ว สิ่งที่มันไม่ได้ทำคือสร้างปลายทางส่วนตัว เผยแพร่ระเบียน DNS ส่วนตัว หรือปิดการเข้าถึงสาธารณะ เพราะสิ่งเหล่านี้คือการเปลี่ยนแปลงสามอย่างแยกกันบนบัญชี ไม่ใช่คุณสมบัติของการเชื่อมต่อเครือข่ายของคุณ ตัวอย่างนี้ใช้ Azure Cosmos DB สำหรับ NoSQL ปลายทางส่วนตัวใน VNet และแล็ปท็อปที่เชื่อมต่อกับ VNet นั้นผ่าน VPN และรักษาที่อยู่ของแอปพลิเคชันไว้ไม่เปลี่ยนแปลง

ความเชื่อผิด: การอยู่ใน VPN ทำให้ฐานข้อมูลเป็นส่วนตัว

การอยู่ใน VNet หมายความเพียงว่าแพ็กเก็ตของคุณสามารถไปถึงที่อยู่ส่วนตัวใน VNet นั้นได้ ไม่ได้บอกอะไรเกี่ยวกับตำแหน่งที่ชื่อบัญชีถูกแปลง และไม่ได้บอกอะไรเกี่ยวกับว่าบัญชียังคงรับทราฟฟิกสาธารณะหรือไม่

ปลายทางส่วนตัวเป็นทรัพยากรแยกต่างหากที่มีที่อยู่ของตัวเอง ขั้นตอนการอนุมัติของตัวเอง และการเดินสาย DNS ของตัวเอง จนกว่ามันจะมีอยู่และได้รับการอนุมัติ ชื่อจะถูกแปลงไปยังปลายทางสาธารณะและทราฟฟิกของคุณจะไปที่นั่นโดยไม่คำนึงถึงอุโมงค์

อะไรที่ทำให้ชื่อถูกแปลงเป็นส่วนตัวจริง ๆ

เก็บปลายทางบัญชีปกติของ SDK ไว้ เช่น https://ACCOUNT.documents.azure.com DNS ส่วนตัวควรแปลงชื่อนั้นผ่านห่วงโซ่ Private Link ไปยังที่อยู่ส่วนตัวของปลายทาง อย่าแทนที่ด้วย URL แบบตัวเลขและอย่าปิดการตรวจสอบใบรับรอง เพราะนั่นแลกปัญห DNS กับปัญหาความปลอดภัย

ค่าเหล่านั้นเฉพาะเจาะจงกับ NoSQL API 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 ที่ตอบสำหรับชื่อบัญชี โหมดการเชื่อมต่อพร้อมข้อกำหนดพอร์ต และการเข้าถึงสาธารณะถูกปิดหรือไม่ สี่ข้อนี้อธิบายการตั้งค่าให้คนถัดไป และแต่ละข้อล้มเหลวอย่างอิสระ