IP สาธารณะสองรายการบน Azure VPN VM เครื่องเดียว: อันไหนทำอะไร

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

การตัดสินใจ 1: ทันเนลสิ้นสุดที่ใด

IP สาธารณะของ Azure ผูกกับคอนฟิกูเรชัน IP ส่วนตัวบน NIC ไม่ใช่ที่อยู่ที่คุณเพิ่มภายในระบบปฏิบัติการของเกสต์ อ่านการแมปแทนการสันนิษฐาน: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}' ที่อยู่ส่วนตัวใดก็ตามที่คำสั่งนั้นคืนมาคือที่อยู่ที่เกสต์ต้องมีจริง

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

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

การตัดสินใจ 2: ไคลเอนต์ที่ส่งต่อไปใช้แหล่งใด

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

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

การตัดสินใจ 3: วิธีออกของ Azure ใดชนะ

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

แยกการตั้งค่าการส่งต่อของ NIC Azureออกจากกันกับการส่งต่อใน Linux แฟล็กคลาวด์อนุญาตแพ็กเก็ตที่ต้นทางหรือปลายทางไม่ได้กำหนดให้ NIC ซึ่งไม่ได้เปิดใช้ net.ipv4.ip_forward และการตั้งค่าในเกสต์ไม่ได้ให้สิทธิ์ของคลาวด์

ซ็อกเก็ตของทันเนลมีการตัดสินใจเรื่องแหล่งของตัวเอง

Address ของ WireGuard ภายใต้ wg-quick กำหนดที่อยู่ให้อินเทอร์เฟซ WireGuard ไม่ใช่คำสั่งผูก UDP ภายนอก แหล่งของซ็อกเก็ตที่เข้ารหัสเป็นไปตามตารางเส้นทาง เส้นทางนโยบายหรือเส้นทางเริ่มต้นที่สองจึงย้ายมันได้โดยไม่แตะที่อยู่ของอินเทอร์เฟซOpenVPN: ตัวเลือก local และ UDP multihome มีพฤติกรรมเหมือนกัน คือเกี่ยวกับผู้รับฟังและคำตอบ ไม่เกี่ยวกับแหล่งอินเทอร์เน็ตของไคลเอนต์ที่ส่งต่อไปแต่ละราย

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

จะยอมรับอะไร และตามลำดับใด

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

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