Azure IP VPN แบบส่วนตัวบน ExpressRoute โดยไม่ต้องมี NVA

ความเชื่อผิดคือการเข้ารหัสทราฟฟิกผ่าน peering ส่วนตัวของ ExpressRoute ต้องใช้อุปกรณ์เครือข่ายเสมือน ไม่ต้องใช้ Azure รองรับ Site-to-Site VPN Gateway ที่ปลายอุโมงค์เป็นที่อยู่ส่วนตัว RFC1918 ซึ่งขนส่งผ่านวงจร และอุปกรณ์เป็นทางเลือกไม่ใช่โครงสร้าง สิ่งที่ความเชื่อเรื่องอุปกรณ์ปิดบังคือส่วนที่เจ็บจริง: การเปิดใช้งานปลายทางส่วนตัวบนออบเจกต์เดียวแทนที่จะเป็นสอง และการปล่อยให้เส้นทาง peering โดยตรงชนะเส้นทางที่เข้ารหัสอย่างเงียบ ๆ

ความเชื่อนี้มาจากไหน

ข้อกล่าวอ้างนี้มีที่มาที่น่าเคารพ เป็นเวลาหลายปีสูตรปฏิบัติสำหรับ IPsec บน peering ส่วนตัวคือ NVA เพราะเกตเวย์ที่จัดการได้เปิดเผยเฉพาะปลายทางสาธารณะ สิ่งนั้นเปลี่ยนไป และคำตอบที่เขียนไว้ก่อนการเปลี่ยนแปลงยังถูกอ้างถึงในกระทู้ที่ไม่มีใครตรวจสอบวันที่ การแก้ไขนั้นแคบ: มีเกตเวย์ VPN ที่ใช้ที่อยู่ส่วนตัวอยู่จริง และมันเปลี่ยนปลายทาง ไม่ใช่ตรรกะการกำหนดเส้นทางรอบ ๆ

ไม่มีสิ่งใดในนี้ทำให้ NVA เกษียณ มันทำให้สมมติฐานที่ว่าอุปกรณ์เป็นหนทางเดียวสู่ข้อกำหนดเกษียณ

เปิดใช้งานปลายทางส่วนตัวในทั้งสองระดับ

เริ่มจากการเชื่อมต่อ peering ส่วนตัวของ ExpressRoute ที่ทำงานอยู่และเชื่อมโยงกับ VNet ที่มีเกตเวย์ VPN ฝั่งองค์กรต้องเข้าถึงที่อยู่ส่วนตัวที่เกี่ยวข้องผ่านวงจรนั้นอยู่แล้ว เพราะอุโมงค์จะใช้ที่อยู่เหล่านั้นเป็นTransport จากนั้นข้อกำหนดเบื้องต้นของเกตเวย์: ขั้นตอนของ Microsoft สำหรับ VPN ที่ใช้ IP ส่วนตัวต้องใช้ เกตเวย์ที่สร้างบนทรัพยากร IP สาธารณะระดับ Standard การกำหนดที่อยู่แบบส่วนตัวของอุโมงค์ไม่ได้ลบข้อกำหนดนั้น ซึ่งทำให้ผู้ที่คิดว่า «ส่วนตัว» หมายถึง «ไม่มี IP สาธารณะที่ไหนเลย» ประหลาดใจ

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

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

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

ความเชื่อที่สอง: อุโมงค์ที่สร้างแล้วจะเข้ารหัสทราฟฟิกของคุณ

ตอนนี้มีสองเส้นทางไปถึงเครือข่ายแอปพลิเคชัน: เส้นทาง peering ส่วนตัวโดยตรงและเส้นทางผ่าน VPN ทั้งสองทำงาน มีเพียงหนึ่งเดียวที่ใช้ชั้น IPsec นี้ Microsoft ระบุว่าเมื่อมีการประกาศพรีฟิกซ์เดียวกันผ่าน ExpressRoute และผ่าน VPN Azure จะเลือกเส้นทาง ExpressRoute โดยตรง ดังนั้นอุโมงค์ที่สุขภาพดีพร้อมตัวนับที่สุขภาพดีไม่ได้พิสูจน์อะไรเกี่ยวกับเส้นทางที่แพ็กเก็ตแอปพลิเคชันไป

วิธีการกำหนดเส้นทางที่ระบุไว้คือช่วงที่ครอบคลุมบน ExpressRoute กับช่วงที่ได้รับการป้องกันเฉพาะเจาะจงกว่าบน VPN หรือพรีฟิกซ์ที่ไม่ทับซ้อนกันบนสองเส้นทาง ตัวอย่างเช่น peering ส่วนตัวอาจขนส่ง 10.40.0.0/16 ขณะที่ VPN ประกาศ 10.40.12.0/24 พรีฟิกซ์ที่เฉพาะเจาะจงกว่าจะชนะและช่วงที่เหลือยังคงเป็นเส้นทางตรง

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

ทำการตรวจสอบเดียวกันในทิศทางฝั่งองค์กร เพราะการตั้งค่าของเราเตอร์ของคุณเป็นตัวกำหนดว่าทราฟฟิกขาออกจะออกทางใด และเก็บการขนส่งของอุโมงค์ไว้บนเส้นทาง ExpressRoute เส้นทางที่ดึงปลายทางส่วนตัวของเกตเวย์เข้าไปในอุโมงค์จะทำให้อุโมงค์พึ่งพาตัวเอง

ตัดสินใจว่าเกิดอะไรขึ้นเมื่ออุโมงค์ล่ม

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

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

กรอบนั้นยังช่วยให้คุณประเมิน NVA ตามคุณสมบัติจริง เช่น อุโมงค์หลายเส้น ปริมาณงาน หรือการตรวจสอบจากผู้จำหน่าย แทนที่จะซื้อเพราะปลายทางเป็นส่วนตัว