ทำไม VM ที่มีอุปกรณ์ VPN ใน Azure จึงทิ้งเส้นทางขากลับ
อุปกรณ์ VPN ใน VM ของ Azure ต้องให้ UDR ธงการส่งต่อของการ์ดเครือข่าย และนโยบายของผู้เยี่ยมชมสอดคล้องกัน ติดตามคำขอหนึ่งรายการจากสาขาผ่านทั้งสามส่วน
VM ของ Azure ที่รันอุปกรณ์ VPN อยู่ภายในระบบตัดสินใจสองระบบที่เป็นอิสระต่อกัน Azure ตัดสินใจว่าแพ็กเก็ตออกจากซับเน็ตใด โดยใช้ตารางเส้นทางและการตั้งค่าการส่งต่อของการ์ดเครือข่าย ระบบปฏิบัติการของอุปกรณ์เองตัดสินใจว่าจะส่งต่อแพ็กเก็ตที่ถอดรหัสแล้วต่อไปหรือไม่ อุโมงค์ที่ขึ้นได้อย่างสมบูรณ์แบบก็ยังล้มเหลวในระบบที่สองได้ และนั่นคือจุดที่การติดตั้งส่วนใหญ่หยุดอยู่
สามเจ้าของของเส้นทางเดียว
ยกเครือข่ายสาขา 192.168.50.0/24 และซับเน็ตของงานเวิร์กโหลด 10.0.10.0/24โดยอุปกรณ์อยู่ที่ 10.0.0.4 ในซับเน็ตของตัวเอง คำขอเดียวแตะการกำหนดค่าสามส่วนที่แยกจากกัน
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
ในองค์กรส่วนใหญ่แต่ละแถวเป็นของทีมที่ต่างกัน นั่นคือเหตุผลที่ความล้มเหลวนี้มักมาในรูปของตั๋วสามใบแทนที่จะเป็นใบเดียว
เส้นทางที่ชี้ไปยังอุปกรณ์
เชื่อมตารางเส้นทางกับซับเน็ตของงานเวิร์กโหลด และให้คำนำหน้าของสาขามีฮอปถัดไปชนิด Virtual appliance ด้วย 10.0.0.4 เป็นที่อยู่ ใช้ที่อยู่ส่วนตัวที่เข้าถึงได้ของอุปกรณ์ ไม่เคยใช้ จุดเข้าใช้งาน VPN สาธารณะของอุปกรณ์ฮอปถัดไปต้องเป็นที่อยู่ที่ซับเน็ตของงานเวิร์กโหลดเข้าถึงได้อยู่แล้ว ปล่อยส่วนที่เหลือของการกำหนดเส้นทางของงานเวิร์กโหลดไว้ตามเดิม เว้นแต่คุณจะตัดสินใจแทนที่เส้นทางเริ่มต้นอย่างตั้งใจ
เก็บอุปกรณ์ไว้ในซับเน็ตของตัวเอง และตรวจสอบว่าเส้นทางที่ส่งทราฟฟิกของสาขาไปยังอุปกรณ์ไม่ได้ดักเส้นทางออกของอุปกรณ์เองด้วย ลูปแบบนี้ดูเหมือนอุโมงค์ที่สมบูรณ์โดยไม่มีคำตอบเลย และเป็นการดีบักที่ทรมานมากเวลา 2 นาฬิกาของคืน
ธงของการ์ดเครือข่ายที่ทุกคนลืม
Azure มีการตั้งค่าการส่งต่อ IP ต่อการ์ดเครือข่ายหนึ่งใบ และปิดไว้เป็นค่าเริ่มต้น มีอยู่เพราะการ์ดที่ส่งต่อจะได้รับแพ็กเก็ตที่ส่งถึงสิ่งอื่น และการทิ้งแพ็กเก็ตเหล่านั้นอย่างเงียบ ๆ คือค่าเริ่มต้นที่ปลอดภัยสำหรับทุกคนอื่น
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true เปิดใช้งานสำหรับอินเทอร์เฟซหนึ่งรายการ คำแนะนำของ Microsoft เกี่ยวกับ การส่งต่อบนการ์ดเครือข่าย กำหนดให้ต้องตั้งค่านี้บนการ์ดที่เชื่อมต่อทุกใบที่ส่งต่อทราฟฟิก ดังนั้นอุปกรณ์ที่มีการ์ดใบเดียวก็ยังต้องตั้งค่านี้บนการ์ดใบนั้น
ธงนี้ไม่ใช่เส้นทางและไม่ใช่กฎไฟร์วอลล์ การเปิดใช้งานให้เพียงสิทธิ์เท่านั้น
ผู้เยี่ยมชมทำอะไรกับแพ็กเก็ตที่ถอดรหัสแล้ว
เมื่ออุโมงค์สิ้นสุดลง สแตกของอุปกรณ์เองจะตัดสินใจขั้นถัดไป บนผู้เยี่ยมชม Linux การส่งต่อ IPv4 เป็นการตั้งค่าเวลารัน และ sysctl -w net.ipv4.ip_forward=1 อยู่ได้ถึงการบูตครั้งถัดไป บันทึกไว้ในไฟล์ภายใต้ /etc/sysctl.d/ แทน อุปกรณ์ของผู้ขายมีสิ่งที่เทียบเท่าของตัวเอง และคำแนะนำ Linux ที่วางลงในแพลตฟอร์มของผู้ขายมักไม่ทำอะไรเลย
นโยบายไฟร์วอลล์ของผู้เยี่ยมชมแยกออกไปอีก เช่นเดียวกับกลุ่มความปลอดภัยเครือข่ายของงานเวิร์กโหลด การอนุญาต UDP 500 และ 4500 ไปยังที่อยู่สาธารณะของ VM ปกป้องอุโมงค์ แต่ไม่ได้บอกอะไรเลยว่าคำขอจากสาขาที่ถอดรหัสแล้วจะไปถึงพอร์ตของงานเวิร์กโหลดได้หรือไม่
ติดตามคำขอหนึ่งรายการและคำตอบของมัน
เลือกโฟลว์ที่ได้รับอนุญาตหนึ่งรายการและติดตามตั้งแต่ต้นจนจบ สาขาต้องการเส้นทางสำหรับ 10.0.10.0/24 ผ่านการเชื่อมต่อไซต์ อุปกรณ์ต้องการเส้นทางส่งมอบไปยังซับเน็ตของงานเวิร์กโหลด และซับเน็ตของงานเวิร์กโหลดต้องการเส้นทางขากลับไปยังสาขา
ตัดสินใจตั้งแต่เนิ่น ๆ ว่าการออกแบบรักษาที่อยู่ต้นทางของสาขาหรือแปลที่อยู่ NAT เปลี่ยนสิ่งที่งานเวิร์กโหลดมองเห็น กฎการเข้าถึงจึงควรอธิบายแบบจำลองที่คุณเลือกจริง ไม่ใช่ที่อยู่เกตเวย์ที่เดาเอา
การจับมือที่สำเร็จพิสูจน์เพียงข้อต่อหนึ่งของโซ่นั้น เส้นทางจะสมบูรณ์เมื่อคำตอบกลับมาผ่านอุปกรณ์เดียวกันและนโยบายของงานเวิร์กโหลดเองอนุญาต