ข้อความ "File exists" ของ OpenVPN บนเส้นทางไม่ใช่ปัญหาไฟล์

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

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

สิ่งที่ไคลเอนต์ขอจริง ๆ

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

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

อ่านเส้นทางที่มีอยู่ ไม่ใช่แค่ที่อยู่

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

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

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

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

สี่ผู้ครอบครองที่คำนำหน้าอาจมี

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

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

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

block-local ตอบคำถามอื่น

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

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

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

ปิดวงจร: ลบรายการซ้ำที่ต้นทางของมัน

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

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

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

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