VPN องค์กรซ้อนใน WireGuard: ชั้นไหนมาก่อน

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

การเริ่มไคลเอนต์สองตัวในลำดับใดก็ไม่ให้ผลนั้น การกำหนดเส้นทางต่างหากที่ให้ผล

เปรียบเทียบลำดับที่เป็นไปได้สองแบบ

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

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

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

ให้ AllowedIPs ระบุเฉพาะช่วงขององค์กร

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

ชั้นนอกแบบอุโมงค์เต็มรูปแบบต้องใช้ 0.0.0.0/0 หักช่วงท้องถิ่น รูปแบบไม่สามารถแสดงการยกเว้นได้ ดังนั้นส่วนเติมเต็มจึงต้องคำนวณและวางลงไป

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

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

ลำดับ เมตริก และอะแดปเตอร์ตัวที่สอง

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

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

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

ไคลเอนต์ที่สร้างบน OpenVPN 2.6 เพิ่มกับดักของตัวเอง เมื่ออะแดปเตอร์ถ่ายโอนช่องข้อมูลถูกใช้อยู่แล้ว อินสแตนซ์ที่สองก็จะปฏิเสธที่จะเริ่ม การเพิ่ม disable-dco ลงในโปรไฟล์จะกลับไปใช้เส้นทาง TAP แบบเก่า แล้วทั้งสองก็ทำงานเคียงข้างกัน

จุดที่เส้นทางซ้อนกันแตก

การตัดการเชื่อมต่ออุโมงค์ชั้นนอกจะฆ่าชั้นใน การเชื่อมต่อเฉพาะไคลเอนต์ชั้นในใหม่มักส่งมันตรงไปยังอินเทอร์เน็ตและถอดการซ้อนออกอย่างเงียบ ๆ ทดสอบลำดับตั้งแต่ต้นทุกครั้ง โดยหยุดทั้งสองอุโมงค์

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

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