AnyConnect rớt khi đóng terminal: các bước kiểm tra phiên

Đường hầm đang chạy, bạn đóng một terminal dư, và VPN rớt mà không cần nhấn phím nào trong ứng dụng. Trong ứng dụng AnyConnect trên Linux, nguyên nhân được báo là kế toán phiên chứ không phải định tuyến: ứng dụng ghi lại những phiên đăng nhập nào tồn tại lúc đường hầm được dựng lên và coi việc bất kỳ phiên nào trong số đó kết thúc là lý do để hạ nó xuống. Các bước kiểm tra dưới đây chạy theo thứ tự, và bước đầu tiên thất bại cho biết bạn có đang gặp đúng hành vi này không. Không có gì trong đầu ra thông thường của ứng dụng nhắc đến terminal, vì vậy phản xạ đầu tiên là đổ lỗi cho bộ tập trung thường là công sức vô ích.

Đừng bắt đầu bằng việc sửa tệp hệ thống. Mỗi bước hoặc giải thích việc rớt hoặc loại bỏ một ứng viên, và các bước rẻ tiền đi trước.

Tách việc rớt phiên khỏi việc rớt lớp nền

Kết nối lại ngay sau khi mất kết nối. Một đường hầm trở lại trong vài giây, trên cùng mạng và không cần thông tin đăng nhập mới, cho thấy tác nhân cục bộ như một phiên bị đóng chứ không phải đường lên đã chết, chuyển vùng Wi-Fi hay thời gian chờ nhàn rỗi trên bộ tập trung. Một đường hầm treo ở Connecting, hoặc chỉ hỏng cho đến khi bạn đổi mạng, là bài viết khác.

Ghi lại những gì đang mở khi đường hầm được dựng: terminal bạn chạy ứng dụng, bất kỳ shell thứ hai, phiên đăng nhập đồ họa và mọi phiên SSH từ máy khác. Bạn sẽ cần danh sách đó trong chốc lát, và việc dựng lại nó từ trí nhớ sau lần rớt tiếp theo là không đáng tin.

Kiểm tra ứng dụng đã ghi gì lúc kết nối

Ứng dụng không xem xét tiến trình cha hay quyền sở hữu terminal. Nó chụp ảnh tập hợp các phiên đăng nhập có mặt lúc kết nối rồi so sánh tập hợp đó về sau; khi một thành viên biến mất, phép so sánh thất bại và đường hầm đi theo. Vì thế việc đóng cửa sổ bạn đã kết nối có thể vô hại, trong khi đóng một terminal dư không liên quan lại giết kết nối: điều quan trọng là phiên đó có nằm trong tập hợp ban đầu hay không. Đây là so sánh tập hợp chứ không phải đếm, nên việc thay thế một phiên cũng có thể nghiêm trọng như mất một phiên.

Liệt kê những gì ứng dụng có thể thấy trước khi bạn thay đổi bất cứ điều gì:

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

Mỗi dòng từ who là một mục tiến trình người dùng trong utmp. Nếu phiên của bạn xuất hiện hai lần, một cho đăng nhập đồ họa và một cho terminal, cả hai mục đều tồn tại lúc kết nối và cả hai đều là ứng viên.

Chỉ xóa mục của chính bạn khỏi utmp

Cách lách đã công bố làm cho phiên bạn sắp dùng trở nên vô hình trong utmp trước khi ứng dụng khởi động. Một chương trình C nhỏ duyệt qua getutent(), tìm bản ghi có ut_line bằng TTY của đầu vào chuẩn, rồi ghi lại bản ghi đó. Thứ tự là có chủ ý: setutent(), đọc mục, sao chép ut_id của nó, đặt ut_type thành DEAD_PROCESS, xóa các trường người dùng và dòng, ghi lại bằng pututline(), rồi endutent().

Biên dịch nó, rồi chạy với quyền root từ shell sẽ khởi động ứng dụng:

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

Hai kiểu lỗi giải thích phần lớn báo cáo rằng công cụ không làm gì. Nó tác động lên TTY gắn với đầu vào chuẩn, nên chạy từ script hoặc cron không có terminal thì không còn gì để khớp. Và /run/utmp không ghi được bởi người dùng thường, nên chạy không có root sẽ thất bại âm thầm trừ khi bạn kiểm tra mã thoát.

Xác nhận đường hầm sống sót sau khi đóng

Hãy thử cơ chế thay vì giả định. Kết nối từ một phiên bạn định giữ, mở terminal thứ hai, đóng cái thứ hai, rồi xác nhận bằng vpn state và nhìn vào danh sách giao diện rằng đường hầm vẫn hoạt động. Nếu đường hầm sống sót, tác nhân là một loại phiên cụ thể chứ không phải mọi phiên, và bạn đã tìm ra phiên phải giữ mở.

Nếu nó vẫn rớt, phiên bị theo dõi nằm ở nơi khác, thường là phiên đăng nhập đồ họa đã sinh ra terminal của bạn, và việc bỏ một mục TTY không giúp gì. Lặp lại quan sát với danh sách đầy đủ từ bước đầu thay vì thêm thao tác.

Khi việc ghi lại utmp là câu trả lời sai

utmp là kế toán dùng chung, không phải bảng riêng. Ghi lại mục của một phiên còn sống khiến who, w và một số công cụ kiểm toán báo cáo thiếu, và một chương trình sau đó đóng đúng mục ấy có thể hỏng hoàn toàn. Hãy giới hạn công cụ trong phiên của chính bạn, giữ bản sao tệp gốc, và đừng biến nó thành dịch vụ khởi động xóa mọi bản ghi.

Nếu tổ chức của bạn thu thập kế toán phiên để tuân thủ, cách lách này xung đột với yêu cầu đó và câu trả lời được hỗ trợ là một phiên bản ứng dụng hoặc phương thức truy cập khác, không phải utmp đã vá. Với hầu hết mọi người, cách sửa ít xâm lấn nhất là chỉ cần khởi động ứng dụng từ một phiên sẽ mở suốt ngày và để yên cửa sổ đó.

Trước khi đóng phiếu, ghi lại ứng dụng đang theo dõi phiên nào khi đường hầm được dựng. Chính dòng đó biến một lần mất kết nối bí ẩn thành điều kiện có thể tái hiện cho người tiếp theo bên máy.