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

อย่าเริ่มด้วยการแก้ไฟล์ระบบ แต่ละขั้นตอนอธิบายการหลุดหรือตัดตัวเลือกออกไปหนึ่งตัว และขั้นตอนที่ถูกกว่ามาก่อน

แยกการหลุดของเซสชันออกจากการหลุดของชั้นล่าง

เชื่อมต่อใหม่ทันทีหลังการตัดการเชื่อมต่อ อุโมงค์ที่กลับมาภายในไม่กี่วินาที บนเครือข่ายเดิม และไม่ต้องใช้ข้อมูลรับรองใหม่ ชี้ไปที่ตัวกระตุ้นภายในเช่นเซสชันที่ปิดไป ไม่ใช่ลิงก์อัปที่ตาย การ roam Wi-Fi หรือ เวลาว่างบนคอนเซนเทรเตอร์ อุโมงค์ที่ค้างอยู่ที่ Connecting หรือที่ล้มเหลวจนกว่าจะเปลี่ยนเครือข่ายเป็นบทความอื่น

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

ตรวจสอบว่าไคลเอนต์บันทึกอะไรตอนเชื่อมต่อ

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

ระบุสิ่งที่ไคลเอนต์มองเห็นได้ก่อนคุณจะเปลี่ยนอะไร:

who
w
last -n 10
sudo ls -l /run/utmp

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

ลบเฉพาะรายการของคุณเองออกจาก utmp

วิธีเลี่ยงที่เผยแพร่ทำให้เซสชันที่คุณกำลังจะใช้มองไม่เห็นใน utmp ก่อนไคลเอนต์เริ่ม โปรแกรม C ขนาดเล็กไล่ผ่าน getutent() หาเรกคอร์ดที่ ut_line เท่ากับ TTY ของอินพุตมาตรฐาน แล้วเขียนเรกคอร์ดนั้นใหม่ ลำดับเป็นเจตนา: setutent() อ่านรายการ คัดลอก ut_id ของมัน ตั้ง ut_type เป็น DEAD_PROCESS ล้างฟิลด์ผู้ใช้และบรรทัด เขียนกลับด้วย pututline() แล้วจึง endutent()

คอมไพล์มัน แล้วรันเป็น root จากเชลล์ที่จะเริ่มไคลเอนต์:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

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

ยืนยันว่าอุโมงค์อยู่รอดหลังการปิด

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

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

เมื่อการเขียน utmp ใหม่เป็นคำตอบที่ผิด

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

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

ก่อนปิดตั๋ว บันทึกว่าไคลเอนต์เฝ้าเซสชันใดตอนที่อุโมงค์ขึ้น บรรทัดเดียวนั้นเปลี่ยนการตัดการเชื่อมต่อที่ลึกลับให้เป็นเงื่อนไขที่ทำซ้ำได้สำหรับคนถัดไปที่เครื่อง

บทความที่เกี่ยวข้อง