การเพียร์ VNet และปลายทางบริการ

ทรัพยากรใน VNet ของ Azure ที่แตกต่างกันไม่สามารถสื่อสารกันได้ตามค่าเริ่มต้น แม้จะอยู่ในภูมิภาค Azure เดียวกันก็ตาม อย่างไรก็ตาม องค์กรขนาดใหญ่มักมี VNet หลายตัว เช่น VNet แยกสำหรับการพัฒนา การจัดเตรียมระบบ และการใช้งานจริง หรือ VNet แยกสำหรับแต่ละแผนก VNet Peering เชื่อมต่อ VNet สองตัวโดยตรงผ่านเครือข่ายแกนหลักส่วนตัวของ Microsoft ทำให้ทรัพยากรใน VNet ทั้งสองสามารถสื่อสารกันเสมือนอยู่ในเครือข่ายเดียวกัน โดยไม่มีการรับส่งข้อมูลผ่านอินเทอร์เน็ตสาธารณะและไม่ต้องใช้เกตเวย์ VPN

VNet Peering เป็นการเชื่อมต่อแบบไม่ส่งต่อเป็นทอด ๆ หาก VNet A ทำเพียริงกับ VNet B และ VNet B ทำเพียริงกับ VNet C, VNet A จะไม่สามารถสื่อสารกับ VNet C ได้จนกว่าคุณจะสร้างเพียริงแยกระหว่าง A กับ C ลิงก์เพียริงเป็นแบบสองทิศทาง แต่ต้องกำหนดค่าทั้งสองฝั่ง การสร้างเพียริงจาก A ไปยัง B จะไม่สร้างเพียริงจาก B ไปยัง A โดยอัตโนมัติ เมื่อกำหนดค่าทั้งสองฝั่งแล้ว การรับส่งข้อมูลระหว่าง VNet ที่ทำเพียริงจะใช้เครือข่ายแกนหลักของ Azure ซึ่งมีความหน่วงต่ำและแบนด์วิดท์สูง ใกล้เคียงกับการสื่อสารระหว่างซับเน็ตภายใน VNet เดียว

VNet Peering มีตัวเลือกขอบเขตสองแบบ ได้แก่ Local VNet Peering ซึ่งเชื่อมต่อ VNet สองเครือข่ายในภูมิภาค Azure เดียวกัน การรับส่งข้อมูลจะอยู่ภายในภูมิภาคนั้นและมีค่าธรรมเนียมการถ่ายโอนเล็กน้อยต่อ GB ส่วน Global VNet Peering เชื่อมต่อ VNet สองเครือข่ายในภูมิภาค Azure ที่แตกต่างกัน โดยกำหนดเส้นทางผ่านโครงข่ายแกนกลางทั่วโลกของ Microsoft ทำให้ทรัพยากรใน East US สามารถสื่อสารแบบส่วนตัวกับทรัพยากรใน West Europe ได้โดยไม่ต้องผ่านอินเทอร์เน็ตสาธารณะ เพียริงข้ามภูมิภาคมีค่าใช้จ่ายการถ่ายโอนสูงกว่าเพียริงภายในภูมิภาคเล็กน้อย แต่ยังคงถูกกว่าและมีความน่าเชื่อถือมากกว่าการกำหนดเส้นทางผ่าน VPN อย่างมีนัยสำคัญ

รูปแบบที่ใช้กันทั่วไปในองค์กรคือการใช้ VNet Peering เพื่อสร้าง โทโพโลยีแบบฮับและสโปก โดย VNet ฮับ ส่วนกลางจะโฮสต์บริการที่ใช้ร่วมกัน เช่น Azure Firewall, VPN Gateway, เซิร์ฟเวอร์ DNS และระบบตรวจสอบ หลาย VNet แบบ สโปก ซึ่งแต่ละเครือข่ายอาจแทนสภาพแวดล้อมหรือภาระงานหนึ่งรายการ จะทำเพียริงกับฮับ การกำหนดเส้นทางให้การรับส่งข้อมูลจากสโปกทั้งหมดผ่านไฟร์วอลล์ของฮับช่วยให้องค์กรตรวจสอบความปลอดภัยจากส่วนกลางได้ โดยไม่ต้องจัดการ NSG ที่ซับซ้อนในสโปกแต่ละแห่ง เนื่องจากเพียริงไม่ส่งต่อเป็นทอด ๆ ไฟร์วอลล์ของฮับจึงใช้ เส้นทางที่ผู้ใช้กำหนด (UDRs) เพื่อกำหนดเส้นทางการรับส่งข้อมูลระหว่างสโปก

VNet Peering มีข้อกำหนดสำคัญประการหนึ่งคือ พื้นที่ที่อยู่ของ VNet ที่ทำเพียริงกันต้องไม่ทับซ้อนกัน หาก VNet A ใช้ 10.0.0.0/16 และ VNet B ก็ใช้ 10.0.0.0/16 เช่นกัน การทำเพียริงจะล้มเหลว เนื่องจาก Azure ไม่สามารถกำหนดเส้นทางการรับส่งข้อมูลระหว่างช่วงที่อยู่เดียวกันได้ ดังนั้นการวางแผนช่วง CIDR ที่ไม่ทับซ้อนกันสำหรับ VNet ทั้งหมด รวมถึงเครือข่ายภายในองค์กร ก่อนเริ่มใช้งานจึงมีความสำคัญอย่างยิ่ง หากต้องการเปลี่ยนพื้นที่ที่อยู่ของ VNet หลังจากนำทรัพยากรไปใช้งานแล้ว จะต้องสร้าง VNet ใหม่ หรือใช้ฟีเจอร์เพิ่มหรือนำพื้นที่ที่อยู่ซึ่งมีข้อจำกัดออก

Service Endpoints ขยายข้อมูลระบุตัวตนของ VNet ไปยังบริการ PaaS ของ Azure เช่น Azure Storage, Azure SQL Database, Azure Key Vault และ Cosmos DB เมื่อคุณเปิดใช้ service endpoint บนซับเน็ต การรับส่งข้อมูลจากทรัพยากรในซับเน็ตนั้นไปยังบริการ Azure ที่ระบุจะถูกกำหนดเส้นทาง ผ่านโครงข่ายแกนกลางของ Azure แทนอินเทอร์เน็ตสาธารณะ แม้ว่าจะใช้ที่อยู่ IP สาธารณะของบริการก็ตาม จากนั้นบริการจะจำกัดการเข้าถึงให้เหลือเฉพาะทรัพยากรใน VNet ที่เปิดใช้ service endpoint ซึ่งช่วยเพิ่มความปลอดภัยได้อย่างมากเมื่อเทียบกับจุดปลายทางที่เข้าถึงได้ผ่านอินเทอร์เน็ต

Service Endpoints และ Private Endpoints ต่างก็ให้การเข้าถึงบริการ PaaS ของ Azure อย่างปลอดภัย แต่ทำงานแตกต่างกันดังนี้: Service Endpoint — กำหนดเส้นทางการรับส่งข้อมูลผ่านโครงข่ายแกนกลางของ Azure แต่ยังใช้ที่อยู่ IP สาธารณะของบริการ โดย service endpoint จะมีอยู่ในระดับซับเน็ต ส่วน Private Endpoint — กำหนดที่อยู่ IP ส่วนตัวจาก VNet ของคุณให้กับบริการ และสามารถปิดใช้งานจุดปลายทางสาธารณะได้ทั้งหมด ทำให้บริการเป็นส่วนตัวอย่างแท้จริง Private Endpoints ให้การแยกเครือข่ายที่เข้มงวดกว่า และยังสามารถเข้าถึงได้จากเครือข่ายภายในองค์กรผ่าน VPN/ExpressRoute สำหรับความปลอดภัยระดับสูงสุด ขอแนะนำให้ใช้ Private Endpoints ส่วน Service Endpoints เป็นทางเลือกที่เรียบง่ายและมีค่าใช้จ่ายต่ำกว่า

หลังจากเปิดใช้ Service Endpoint บนซับเน็ตแล้ว คุณต้องกำหนดค่าบริการ Azure ให้ ยอมรับการเชื่อมต่อจากซับเน็ตนั้นเท่านั้น สำหรับบัญชี Storage หมายถึงการเพิ่มกฎ VNet ในการตั้งค่าไฟร์วอลล์ของบัญชี Storage หลังจากเปลี่ยนแปลงนี้ เฉพาะ VM ในซับเน็ตที่ระบุเท่านั้นที่จะเข้าถึงบัญชี Storage ได้ ส่วนการรับส่งข้อมูลทางอินเทอร์เน็ตอื่น ๆ จะถูกปฏิเสธ วิธีนี้เป็นแนวทางที่รวดเร็วและไม่มีค่าใช้จ่ายในการเพิ่มความปลอดภัยให้บัญชี Storage ได้อย่างมาก เมื่อเทียบกับการเปิดให้รับการรับส่งข้อมูลจากอินเทอร์เน็ตทั้งหมด โดยเฉพาะบัญชีที่เก็บข้อมูลแอปพลิเคชันที่มีความละเอียดอ่อน

การผสานรวม VNet ซึ่งแตกต่างจาก VNet Peering ช่วยให้แอปพลิเคชัน Azure App Service เรียกใช้ทรัพยากรภายใน VNet ได้ในทิศทางขาออก หากไม่มีการผสานรวม VNet การรับส่งข้อมูลขาออกจาก App Service จะออกผ่านอินเทอร์เน็ตสาธารณะเสมอ แม้จะเรียกใช้ทรัพยากรอย่าง Azure SQL หรือ Azure Cache for Redis ที่อยู่ใน VNet เดียวกันก็ตาม เมื่อเปิดใช้การผสานรวม VNet การรับส่งข้อมูลขาออกของแอปจะถูกกำหนดเส้นทางเข้าสู่ VNet และสามารถเข้าถึงทรัพยากรส่วนตัวได้ โดยต้องมี ซับเน็ตที่มอบหมายโดยเฉพาะใน VNet ซึ่งมีพื้นที่ที่อยู่อย่างน้อย /28

เนื่องจาก VNet Peering ไม่ส่งต่อเป็นทอด ๆ การเชื่อมต่อ VNet มากกว่าสองเครือข่ายจึงต้องใช้การทำเพียริงโดยตรงระหว่างทุกคู่ ซึ่งมีความซับซ้อน O(n²) หรือใช้ ฮับกำหนดเส้นทางส่วนกลาง ในรูปแบบฮับและสโปก VNet ฮับจะมี Network Virtual Appliance (NVA) หรือ Azure Firewall ทำหน้าที่เป็น เราเตอร์ส่งต่อระหว่าง VNet แบบสโปก แต่ละสโปกจะเพิ่ม UDR ที่ชี้การรับส่งข้อมูลทั้งหมด (0.0.0.0/0 หรือ CIDR ของสโปกที่ระบุ) ไปยัง IP ของ NVA ในฮับ จากนั้น NVA จะส่งต่อการรับส่งข้อมูลไปยังสโปกปลายทางที่ถูกต้อง ทำให้เกิดการเชื่อมต่อแบบส่งต่อเป็นทอดผ่านฮับได้อย่างมีประสิทธิภาพ

ข้อจำกัดสำคัญของ VNet Peering ได้แก่ ต้องใช้พื้นที่ที่อยู่ที่ไม่ทับซ้อนกัน — วางแผนช่วง CIDR อย่างรอบคอบก่อนสร้าง VNet ไม่ส่งต่อเป็นทอด ๆ — การทำเพียริงระหว่าง A-B และ B-C ไม่ได้เชื่อมต่อ A-C ไม่สามารถปรับขนาดพื้นที่ที่อยู่ของ VNet ได้ หากมีเพียริงที่ใช้งานอยู่ เว้นแต่จะลบเพียริงเหล่านั้นชั่วคราว การส่งต่อผ่านเกตเวย์ — VNet แบบสโปกสามารถใช้เกตเวย์ VPN หรือ ExpressRoute ใน VNet ฮับได้โดยเปิดใช้ 'Use Remote Gateways' ในการตั้งค่าเพียริง แต่ต้องสร้างเกตเวย์ของฮับก่อน การทำความเข้าใจข้อจำกัดเหล่านี้มีความสำคัญต่อการออกแบบสถาปัตยกรรมที่มีหลาย VNet ซึ่งรองรับการขยายระบบและดูแลรักษาได้

ทดสอบความเข้าใจแนวคิด Microsoft Azure Fundamentals (AZ-900) จากบทเรียนนี้

ในบทเรียนนี้ คุณได้เรียนรู้ว่า VNet Peering เชื่อมต่อ VNet สองเครือข่ายผ่านโครงข่ายแกนกลางของ Microsoft เพื่อการสื่อสารแบบส่วนตัวที่มีความหน่วงต่ำโดยไม่ต้องใช้ VPN แต่เพียริงไม่ส่งต่อเป็นทอด ๆ service endpoints กำหนดเส้นทางการรับส่งข้อมูลจากซับเน็ตไปยังบริการ PaaS ของ Azure ผ่านโครงข่ายแกนกลางโดยไม่เปิดเผยบริการต่ออินเทอร์เน็ตสาธารณะ และ private endpoints เป็นทางเลือกที่ปลอดภัยกว่า โดยกำหนด IP ส่วนตัวให้บริการ PaaS ทำให้สามารถปิดจุดปลายทางสาธารณะได้ทั้งหมด ต่อไปเราจะเรียนรู้พื้นฐานของ Azure DNS และ Load Balancer