Listener ของ OpenVPN 2.5 บน DD-WRT ตายแล้วหรือ? อ่านคอนฟิกที่มันสร้าง

Listener ที่ตายบน DD-WRT มักหมายความว่า daemon ออกไปขณะแยกวิเคราะห์คอนฟิกของมัน ไม่ใช่กฎไฟร์วอลล์บล็อกพอร์ต OpenVPN 2.5 ได้เข้มงวดค่าดีฟอลต์หลายค่าที่คอนฟิกเก่าพึ่งพา และคอนฟิกที่สร้างขึ้นซึ่งเคยทำงานบนบิลด์เก่าอาจถูกปฏิเสธก่อนที่ซ็อกเก็ตจะเปิดด้วยซ้ำ เหตุผลอยู่ในล็อกของเราเตอร์เอง และอินพุตอยู่ในไฟล์ที่สร้างขึ้น การอ่านทั้งสองอย่างตามลำดับนั้นเร็วกว่าการดักจับแพ็กเก็ตใด ๆ

daemon ไม่ใช่ไฟร์วอลล์

ความต่างนี้สำคัญเพราะจากภายนอกความล้มเหลวทั้งสองดูเหมือนกัน: ไคลเอนต์ส่ง handshake แล้วไม่มีอะไรกลับมา อย่างหนึ่งคือโปรเซสที่ไม่ได้ทำงาน อีกอย่างคือโปรเซสที่ทำงานและกรองอยู่

แยกทั้งสองด้วยการตรวจสอบสองครั้งก่อนจะเปลี่ยนอะไร เพราะการแก้ไฟร์วอลล์บน daemon ที่ตายแล้วเพียงเพิ่มตัวแปรที่สอง

อ่านคอนฟิกที่ DD-WRT สร้างขึ้น

DD-WRT ไม่ได้ส่งข้อความที่คุณพิมพ์ในเว็บอินเทอร์เฟซให้ OpenVPN มันเขียนคอนฟิกที่สร้างขึ้นไปที่ /tmp/openvpn/openvpn.conf แล้วเริ่ม daemon ด้วยไฟล์นั้น ฟิลด์ในอินเทอร์เฟซและข้อความใด ๆ ใน Additional Config จึงถูกรวมก่อนที่ OpenVPN จะเห็น การดีบักฟอร์มแทนไฟล์ที่สร้างขึ้นหมายถึงคุณกำลังอ่านเจตนา ไม่ใช่อินพุตจริง คัดลอกไฟล์นั้นไปยังที่ถาวรก่อนที่การรีบูตจะล้าง /tmp

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

ถ้าไฟล์ที่สร้างขึ้นว่างเปล่าหรือหายไป daemon ก็ไปไม่ถึงขั้นเริ่มทำงาน และปัญหาอยู่เหนือ OpenVPN ขึ้นไป

สิ่งที่ OpenVPN 2.5 เลิกยอมรับ

OpenVPN 2.5 แทนที่ ncp-ciphers ด้วย data-ciphers และยกเวอร์ชัน TLS ขั้นต่ำเริ่มต้นเป็น 1.2 มันยังเปลี่ยนการจัดการการบีบอัด ด้วยเหตุนี้คู่ที่เสนอการบีบอัดจะถูกปฏิเสธ เว้นแต่คอนฟิกจะอนุญาตอย่างชัดเจน และมันได้ประกาศชื่อออปชันเก่าเช่น ns-cert-type ล้าสมัยโดยหันไปใช้ remote-cert-tls การเปลี่ยนแปลงแต่ละอย่างเหล่านี้เปลี่ยนคอนฟิกที่เคยทำงานให้กลายเป็นความล้มเหลวในการแยกวิเคราะห์หรือเจรจา

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

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

ข้อกำหนดเฉพาะของ Broadcom

บนบิลด์ Broadcom อุปกรณ์อุโมงค์ต้องมีอยู่ก่อนที่ daemon จะใช้ได้ ตรวจสอบว่าโหลดมอดูล tun แล้วและ /dev/net/tun มีอยู่ เพราะอุปกรณ์ที่หายไปทำให้เกิดความล้มเหลวในการเริ่มที่ไม่เกี่ยวกับใบรับรองเลย เช่นเดียวกันกับสคริปต์ช่วยที่ DD-WRT สร้างสำหรับเส้นทางและ DNS: ถ้าไม่มีหรือรันไม่ได้ daemon อาจเริ่มได้แต่ก็ยังทำการตั้งค่าไม่เสร็จ

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

จากนั้นคืนบริการปกติ เพราะ daemon บนพื้นหน้าและ init สคริปต์จะแย่งพอร์ตกัน

พิสูจน์ว่า listener มีอยู่ก่อนดีบักไคลเอนต์

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

การดีบักฝั่งไคลเอนต์จะมีความหมายก็ต่อเมื่อ listener มีอยู่แล้ว จากนั้นตรวจสอบว่าการเข้ารหัสและการตั้งค่า TLS ของไคลเอนต์ตรงกับรายการ data-ciphers ของเซิร์ฟเวอร์และเวอร์ชันขั้นต่ำ และพอร์ตถูกส่งต่อไปยังเราเตอร์จริง

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