สองอุโมงค์ OpenVPN บนโฮสต์ Linux เครื่องเดียว: เส้นทางเป็นของใคร

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

เริ่มจากงานที่ลิงก์ที่สองต้องทำ

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

พูลที่ทับซ้อนกันพังก่อนการกำหนดเส้นทาง

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

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

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

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

ให้แต่ละโปรไฟล์มียูนิตของตัวเองและแต่ละพรีฟิกซ์มีเจ้าของ

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

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

มาร์กเก็บการตอบกลับไว้บนอินเทอร์เฟซที่มันมาจาก

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

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

พิสูจน์การแยกโดยหยุดลิงก์หนึ่ง

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

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

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