OpenVPN เซิร์ฟเวอร์และไคลเอนต์บนโฮสต์เดียว: ทำไมไคลเอนต์หลุด

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

เครื่องเดียว สองบทบาท และสองคำตอบที่เข้ากันไม่ได้ว่าการตอบกลับควรไปที่ใด

พูลเดียวกัน สองเซิร์ฟเวอร์: ใครชนะ

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

ระบุสิ่งที่ทำงานอยู่ก่อนแก้ไข: ip -4 addr show แสดงอุปกรณ์อุโมงค์ ss -lunp แสดงตัวรับฟัง และ systemctl list-units บอกชื่อยูนิต การมองที่อยู่อุโมงค์ครั้งเดียวก็ตัดสินได้ว่าพูลชนกันหรือไม่

โปรไฟล์ไคลเอนต์เพิ่มอะไรลงในตาราง

ครึ่งไคลเอนต์เขียนเส้นทางทันทีที่เชื่อมต่อ redirect-gateway def1 แยกเส้นทางเริ่มต้นเป็น 0.0.0.0/1 บวก 128.0.0.0/1 ทั้งคู่ถูกกำหนดเส้นทางผ่านอุปกรณ์ใหม่ พร้อมกับเส้นทางโฮสต์ไปยังเซิร์ฟเวอร์ระยะไกลที่ถูกปักหมุดไว้กับอินเทอร์เฟซกายภาพโดยเจตนา การปักหมุดนี้มีไว้เพื่อให้อุโมงค์ยังมีเส้นทางสำหรับการขนส่งของตัวเอง ทุกอย่างอื่น รวมถึงการตอบกลับที่เซิร์ฟเวอร์ภายในเป็นหนี้ไคลเอนต์ของตัวเอง ตอนนี้เป็นไปตามค่าเริ่มต้นใหม่และออกผ่านลิงก์ระยะไกล

ดังนั้นการชนกันที่สองไม่ใช่อุโมงค์ที่เสีย แต่เป็นอุโมงค์ที่ทำงานผิดตำแหน่งในตาราง

สามวิธีในการแยกบทบาทออกจากกัน

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

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

อินสแตนซ์ใดในสองตัวคือต้นเหตุ

หยุดอินสแตนซ์ไคลเอนต์แล้วทดสอบไคลเอนต์เดิมอีกครั้ง หากหายทันทีแสดงว่าเป็นการกำหนดเส้นทาง ไม่ใช่เซิร์ฟเวอร์ นำไคลเอนต์กลับมาและติดตามการตอบกลับหนึ่งรายการด้วย ip route get ที่ให้ทั้งที่อยู่ต้นทางและปลายทาง ซึ่งแสดงเส้นทางที่เคอร์เนลจะเลือก จากนั้นดูอินเทอร์เฟซที่แพ็กเก็ตใช้จริงด้วย tcpdump -ni any port 1194 ไฟล์สถานะของเซิร์ฟเวอร์ซึ่งเขียนทุกไม่กี่วินาทีผ่านไดเรกทีฟ status บรรจุรายการไคลเอนต์ที่เชื่อมต่อและตัวนับไบต์ทั้งสองทิศทาง

อ่านตัวนับเหล่านั้นเทียบกัน การรับส่งที่ออกไปแล้วไม่กลับมาคือคำตอบเรื่องการกำหนดเส้นทาง ไม่ใช่ปัญหาแฮนด์เชก