OpenVPN ยังดันเส้นทางเก่าอยู่หรือ? ตรวจสอบว่ามันโหลดอะไรไป

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

การเปรียบเทียบด้านล่างเริ่มจากโปรเซสออกไปข้างนอก เพราะมีเพียงโปรเซสเท่านั้นที่รู้ว่าไฟล์ใดมีผล

ไฟล์ที่คุณแก้ไขกับไฟล์ที่โปรเซสอ่าน

เริ่มจาก unit และบรรทัดคำสั่งที่มันสร้างขึ้น บนโฮสต์ systemd นั้น systemctl cat openvpn@server พิมพ์บรรทัด ExecStart และ instance unit มักอนุมานเส้นทางคอนฟิกจากชื่อ instance ดังนั้นเดมอนที่เริ่มด้วยชื่อ openvpn@office จะอ่านไฟล์ต่างจากที่เริ่มด้วยชื่อ openvpn@server เปรียบเทียบกับ argv ของโปรเซสที่กำลังทำงาน เครื่องมือจัดการคอนฟิกเพิ่มอีกทางที่ทำให้การเปลี่ยนแปลงหายไป: มันอาจเขียนไฟล์ที่ถูกต้องลงในตำแหน่งที่ unit ไม่เคยกล่าวถึง แล้วการดีพลอยที่ขึ้นเขียวก็ดูเหมือนไม่ได้ทำอะไร

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

สิ่งที่เซิร์ฟเวอร์ดันไปกับสิ่งที่ไคลเอนต์ติดตั้ง

เส้นทางที่ดันไปต้องผ่านตัวกรองสองชั้น บนเซิร์ฟเวอร์มันต้องอยู่ในคอนฟิกที่โหลดแล้ว ไม่ใช่ในบล็อกที่คอมเมนต์ไว้หรือไฟล์เฉพาะไคลเอนต์ที่ชื่อไม่ตรง บนไคลเอนต์ต้องเปิด pull และต้องไม่มี pull-filter ใดทิ้งออปชันนั้น เชื่อมต่อด้วย verbosity 4 แล้วอ่านออปชันที่ถูกดันไปซึ่งไคลเอนต์รายงาน: ถ้าเส้นทางอยู่ในรายการนั้น แปลว่าเซิร์ฟเวอร์ทำหน้าที่แล้ว และไคลเอนต์เป็นฝ่ายเลือกไม่ติดตั้ง

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

พรีฟิกซ์ที่ดันไปกับเส้นทางขากลับเป็นปัญหาคนละเรื่อง

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

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

เปรียบเทียบตารางที่ปลายทั้งสองข้าง

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

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

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

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