OpenVPN สองไคลเอนต์บนเกตเวย์ Linux เครื่องเดียว: แบ่งนโยบาย
อุโมงค์ทั้งสองสามารถขึ้นได้ในขณะที่ไคลเอนต์แต่ละรายใช้เพียงหนึ่ง ตัดสินใจตามต้นทาง ให้แต่ละกลุ่มมีตารางของตัวเอง จากนั้นอนุญาตและแปลบนอุปกรณ์ที่เลือก
ไดมอน OpenVPN ทั้งสองตัวสามารถรายงานว่าอุโมงค์สำเร็จได้พร้อมกัน ในขณะที่เกตเวย์ส่งไคลเอนต์ทุกรายผ่านตัวเดียวกัน ไม่มีสิ่งใดในการจับมือที่กำหนดว่าไคลเอนต์จะใช้อุโมงค์ใด เคอร์เนลเป็นผู้กำหนด ทีละแพ็กเก็ต โดยไล่ตามกฎนโยบายแล้วจึงไล่ตามตารางที่แต่ละกฎระบุชื่อ เมื่อมองแบบนั้น การตั้งค่าจึงไม่ใช่เรื่องตัวเลือกของ OpenVPN อีกต่อไป แต่กลายเป็นเมทริกซ์การกำหนดเส้นทางที่มีเจ้าของสองราย
เคอร์เนลเป็นผู้กำหนด ไม่ใช่ไดมอน
แพ็กเก็ตที่ถูกส่งต่อมาถึงอินเทอร์เฟซ LAN และโค้ดกำหนดเส้นทางจะประเมินรายการกฎตามลำดับความสำคัญ กฎแรกที่ตัวเลือกตรงกันจะระบุชื่อตาราง และเส้นทางในตารางนั้นเลือกอุปกรณ์ขาออก หากตารางไม่มีเส้นทางที่ตรงกัน การค้นหาจะต่อไปยังกฎถัดไป และรายละเอียดนี้เองทำให้การตั้งค่าที่ทำค้างไว้ล้มเหลวอย่างเงียบ ๆ ไม่ใช่เสียงดัง
กระบวนการอุโมงค์ไม่มีสิทธิ์พูดในการไล่ตามนั้น มันสร้างอินเทอร์เฟซและติดตั้งเส้นทางได้ แต่จะเข้าไปในอินเทอร์เฟซนั้นหรือไม่นั้นขึ้นอยู่กับตารางที่แพ็กเก็ตถูกส่งไปโดยสิ้นเชิง ดังนั้นอุโมงค์สองตัวที่มีเส้นทางนำเข้าเหมือนกันจึงแข่งขันกัน และตัวที่เขียนทีหลังชนะสำหรับทุกคน นี่คือเหตุผลที่การตั้งค่าอาจดูสมดุลในไฟล์คอนฟิกและยังคงส่งไคลเอนต์ทุกคนผ่านไดมอนตัวเดียว
ให้แต่ละอินสแตนซ์มีชุดทรัพยากรของตัวเอง
เริ่มจากชื่อ เพราะชื่อที่ใช้ซ้ำคือวิธีที่สองอินสแตนซ์จบลงด้วยการแชร์สถานะโดยไม่ตั้งใจ กำหนดอุปกรณ์อุโมงค์แยกกัน ไฟล์คอนฟิกแยกกัน ข้อมูลรับรองแยกกัน และยูนิตบริการแยกกัน บันทึกปลายทางภายนอกและที่อยู่อุโมงค์ของแต่ละอินสแตนซ์ไว้ในตารางเดียวกับเมทริกซ์นโยบาย เพื่อให้การเปลี่ยนแปลงภายหลังมีที่เดียวให้ดู
dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"
dev tun-lab
route-nopull
route-nopull เก็บเส้นทางที่เซิร์ฟเวอร์ดันออกมาไว้นอกตารางภายใน ซึ่งเป็นสิ่งที่ต้องการเมื่อตารางนโยบายควรชัดเจน ควรตรวจในคู่มือแทนการสันนิษฐานว่าเซิร์ฟเวอร์ที่กำหนดดันตัวเลือก redirect-gateway ด้วยหรือไม่ และเวอร์ชันไคลเอนต์ของคุณรองรับรูปแบบตัวกรองหรือไม่
เขียนเมทริกซ์: ต้นทาง ตาราง อุปกรณ์
สำหรับแต่ละกลุ่มไคลเอนต์ ให้เพิ่มกฎที่เลือกตารางตามที่อยู่ต้นทาง แล้วใส่เส้นทางที่ต้องการลงในตารางนั้น:
ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200
ตารางต้องมีเส้นทางปลายทางที่กลุ่มควรมี บวกข้อยกเว้นภายในหรือการจัดการที่ทำให้เกตเวย์ใช้งานได้ ตารางที่มีเพียงเส้นทางเริ่มต้นคือนโยบายอุโมงค์เต็มรูปแบบสำหรับกลุ่มนั้น ซึ่งอาจถูกต้องที่สุด แต่ควรเป็นการตัดสินใจไม่ใช่การละไว้
การรับส่งของอุโมงค์เองไม่ได้อยู่ในกลุ่มไคลเอนต์
แพ็กเก็ตที่เข้ารหัสของแต่ละไดมอนเกิดขึ้นบนเกตเวย์เอง โดยส่งถึงคู่หูภายนอก กฎที่ตรงกับคำนำหน้าต้นทางของไคลเอนต์เท่านั้นจะปล่อยแพ็กเก็ตเหล่านั้นไว้ นี่คือเหตุผลที่กฎจำกัดตามต้นทางปลอดภัยกว่ากฎที่ตรงกับทุกสิ่ง กฎที่ไม่มีตัวเลือกสามารถ ดักจับการรับส่งของอุโมงค์เอง และส่งกลับผ่านอุโมงค์ จากนั้นการเชื่อมต่อจะล้มเหลวในลักษณะที่ดูเหมือนปัญหาของผู้ให้บริการ
เก็บเซสชันการจัดการภายในและเส้นทางของชั้นล่างไว้นอกตารางนโยบายอย่างชัดเจน จดข้อยกเว้นเหล่านั้นไว้ข้างเมทริกซ์ เพราะเป็นส่วนหนึ่งของการออกแบบ ไม่ใช่ทางแก้ชั่วคราวที่ต้องค้นพบใหม่ระหว่างเหตุการณ์
การเลือกเส้นทางไม่ใช่การอนุญาต
การอนุญาตให้ส่งต่อเป็นการตัดสินใจที่สองซึ่งเกิดขึ้นภายหลังในเส้นทาง กฎไฟร์วอลล์ที่ยอมรับแพ็กเก็ตที่ออกผ่านอุโมงค์ที่สองไม่ได้ทำให้โค้ดกำหนดเส้นทางเลือกอุโมงค์นั้น และตารางที่ถูกต้องไม่ได้ให้สิทธิ์ในการส่งต่อ ทั้งสองอย่างต้องมี และการทดสอบที่พิสูจน์เพียงอย่างเดียวจะทำให้เข้าใจผิดเกี่ยวกับอีกอย่าง เมื่อกลุ่มหนึ่งทำงานและอีกกลุ่มไม่ ให้ตรวจสองขั้นตอนนี้แยกกันแทนการเขียนตารางใหม่
การแปลต้นทางเป็นการตัดสินใจที่สาม และควรจำกัดเฉพาะกลุ่มต้นทางกับอุปกรณ์อุโมงค์ที่รับส่งมันจริง ๆ เพิ่มเชนเฉพาะสำหรับสองอินสแตนซ์แทนการล้างเชน postrouting เพราะบริการที่ไม่เกี่ยวข้องอาจมีรายการอยู่ที่นั่นและการล้างจะลบออกอย่างเงียบ ๆ
เกิดอะไรขึ้นเมื่ออุโมงค์ตัวหนึ่งล้ม
ตัดสินใจพฤติกรรมเมื่อล้มเหลวล่วงหน้า เมื่อตารางอุโมงค์สูญเสียเส้นทาง การค้นหาจะตกไปยังกฎถัดไป และทราฟฟิกของกลุ่มจะดำเนินต่อผ่านอุโมงค์อีกตัวหรือลิงก์ขึ้นปกติโดยไม่มีข้อผิดพลาดใด ๆ หากยอมรับไม่ได้ ให้เพิ่มกฎสิ้นสุดที่หมายเลขลำดับความสำคัญต่ำกว่าซึ่งคืนผลลัพธ์ที่เข้าถึงไม่ได้สำหรับต้นทางนั้น เพื่อให้เห็นการสูญเสียแทนที่จะถูกกลืน
ส่งคำขอใหม่จากแต่ละกลุ่มต้นทางและบันทึกข้อเท็จจริงสี่ประการ คือ ตารางที่เลือก อุปกรณ์ขาออก ต้นทางที่แปลแล้ว และการตอบกลับกลับมาทางเดิมหรือไม่ จากนั้นลดอุโมงค์ลงหนึ่งตัวแล้วทำซ้ำ การรันครั้งที่สองที่มีอุโมงค์หายไปหนึ่งตัวคือสิ่งที่แสดงว่ากฎสำรองของคุณทำสิ่งที่ตั้งใจหรือไม่