OpenConnect vpnc-script: ไฟล์ใดที่กำลังทำงานอยู่?

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

สองโปรแกรม สองความรับผิดชอบ

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

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

ค้นหาตัวช่วยที่ไคลเอนต์ที่กำลังทำงานใช้

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

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

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

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

อ่านการทำงานแรกที่ล้มเหลว ไม่ใช่คำเตือนสุดท้าย

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

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

ตรวจสอบการเชื่อมต่อ การเชื่อมต่อใหม่ และการตัดการเชื่อมต่อ

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

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

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

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