UDR ของ Azure ไปยังเกตเวย์ VPN: ปลายทางเดียว ไม่ใช่ทุกทราฟฟิกขาออก

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

ฮอปถัดไปคือเกตเวย์ ไม่ใช่ IP ของอุปกรณ์

UDR ส่งคำนำหน้าที่ตรงกันไปยังประเภทของฮอปถัดไป และ VirtualNetworkGateway เป็นประเภท ไม่ใช่ที่อยู่ ผู้คนวาง IP ส่วนตัวของเกตเวย์ลงในเส้นทาง VirtualAppliance แล้วสงสัยว่าทำไมไม่มีอะไรตรงกัน เพราะประเภทนั้นคาดหวัง NIC หรือตัวกระจายโหลดภายในแทน เอกสารการกำหนดเส้นทางของ Microsoft ยังจำกัดฮอปถัดไปของเกตเวย์ไว้ที่เครือข่ายเสมือนที่มีเกตเวย์เป็นเกตเวย์ VPN ส่วน ExpressRoute, Route Server และฮับ Virtual WAN ไม่ได้รับการระบุด้วยตัวเลือกนั้น

ตรวจสอบว่าเครือข่ายเสมือนมีอะไรจริง ๆ ก่อนเขียนเส้นทาง ถ้าการออกแบบกำหนดเส้นทางผ่านฮับ เส้นทางนั้นเป็นของการกำหนดเส้นทางของฮับ ไม่ใช่ของสโป๊กที่คุณกำลังแก้ไข

อ่านเส้นทางที่มีผลก่อนเปลี่ยนอะไร

Azure รวมเส้นทางระบบ คำนำหน้าที่เรียนรู้ผ่าน BGP และ UDR ไว้ในตารางเส้นทางที่มีผลต่อ NIC และคำนำหน้าที่ตรงกันยาวที่สุดชนะไม่ว่ามันจะมาจากไหน สำหรับคำนำหน้าเดียวกัน UDR ชนะเส้นทาง BGP ลำดับนี้คือเหตุผลที่ UDR เก่าจากการทดลองก่อนหน้าสามารถเขียนทับคำนำหน้าที่คุณเพิ่งเรียนรู้ผ่านอุโมงค์ได้อย่างเงียบ ๆ

ดูตารางที่มีผลก่อน แล้วตัดสินว่าคุณกำลังเพิ่มเส้นทางหรือแทนที่เส้นทางหนึ่ง:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

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

เขียนเส้นทางตามคำนำหน้าและซับเน็ตจริง

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

สร้างเส้นทาง แล้วผูกตารางกับซับเน็ตที่โฮสต์งานเวิร์กโหลด:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

การเผยแพร่ก็สำคัญ เมื่อเปิดการเผยแพร่ BGP บนตารางนั้น คำนำหน้าที่เรียนรู้จะปรากฏข้าง ๆ คำนำหน้าที่คุณเขียน และคำนำหน้าที่เรียนรู้ที่เจาะจงกว่าสามารถชนะ UDR ที่กว้างกว่าได้ ปิดการเผยแพร่เฉพาะเมื่อคุณต้องการให้ชุด UDR เป็นตัวกำหนดสำหรับซับเน็ตนั้น

ทำครึ่งฝั่งภายในให้เสร็จ ไม่อย่างนั้นการไหลจะตายตรงนั้น

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

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

ตัวเลือกและรายการที่อนุญาตแยกจากทั้งหมดนี้ การเลือกฮอปถัดไปของ Azure ไม่ได้ขยายตัวเลือกทราฟฟิกของ VPN และไม่เปลี่ยนรายการต้นทางที่อนุญาตของบริการภายนอก

ตรวจสอบด้วยต้นทางที่ปลายทางสังเกตเห็น

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

การส่งผ่านด้วยคำนำหน้าที่เลือกนั้นเป็นการเปลี่ยนแปลงที่แคบกว่าการอุโมงค์แบบบังคับมาก รักษาให้แคบไว้ แล้วการย้อนกลับคือการลบเส้นทางหนึ่งรายการ