OpenConnect nên tiếp tục thử lại một VPN bị ngắt trong bao lâu?

--reconnect-timeout trả lời một câu hỏi hẹp: sau khi đường hầm sụp, tiến trình máy khách này tiếp tục thử trong bao lâu trước khi bỏ cuộc và thoát. Trang hướng dẫn của OpenConnect ghi nhận tùy chọn đó với giá trị mặc định được ghi chép là 300 giây cho các lần thử tiếp theo sau một liên kết bị mất hoặc một peer ngừng trả lời, và con số này là hạn chót cho một máy khách đang chạy, không phải bằng chứng rằng VPN vẫn truy cập được. Đây cũng không phải chính sách giữ tiến trình sống, và phần lớn sự nhầm lẫn bắt đầu từ đó.

Sự nhầm lẫn tăng lên khi có cơ chế thứ hai nằm bên trên. Một giám sát khởi động lại máy khách, một đầu dò ping cổng và cửa sổ thử lại tích hợp đều có thể phản ứng với một lỗi, và sự cố sau đó tạo ra ba dòng thời gian mà không ai hòa giải được.

Cửa sổ kết nối lại thực sự giới hạn điều gì

Hãy tưởng tượng mạng truy cập biến mất trong vài giây. Máy khách thấy liên kết rớt, hoặc ngừng nghe phản hồi từ peer đã chết, và bắt đầu thiết lập lại phiên trong khi giữ trạng thái mà nó có thể. Các lần thử tiếp tục cho đến khi cổng chấp nhận lại hoặc cửa sổ cạn, và một cửa sổ đã cạn kết thúc bằng việc thoát khác không. Chính lần thoát đó, không phải giá trị thời gian chờ, là nơi quyền sở hữu vòng đời chuyển sang người giám sát tiến trình.

Cửa sổ không nói gì về tần suất đầu dò chạy, và nó không thể kéo dài xác thực. Nếu cổng đã thu hồi phiên, hoặc tài khoản giờ yêu cầu một yếu tố thứ hai mới, chờ lâu hơn sẽ không làm phiên cũ hợp lệ trở lại. Một lần thử mới chỉ thành công khi đường dẫn trở lại, cổng vẫn nhận ra phiên và thông tin xác thực được yêu cầu vẫn dùng được, nên hãy đọc con số này như một hạn chót chứ không phải khoảng thời gian sống.

Cửa sổ cũng không chi phối việc ứng dụng làm gì trong khi nó chạy. Tùy nền tảng và mức độ sâu của lỗi, máy khách có thể đang kết nối lại với các tuyến vẫn còn cài đặt, hoặc sau khi chúng đã bị gỡ. Đó là lý do một yêu cầu phát ra giữa lúc gián đoạn thường bị treo cho đến hết thời gian chờ thay vì thất bại nhanh.

Khởi động lại của giám sát và các lần thử của máy khách là hai tầng

Hãy để máy khách đang chạy tiêu cửa sổ của chính nó, và để trình quản lý dịch vụ phản ứng với việc thoát. Một máy khách ở tiền cảnh dưới systemd với chính sách khởi động lại cho đúng sự phân chia đó: thử trong một khoảng có hạn, rồi một quyết định khởi động lại duy nhất. Kết quả là một dòng thời gian duy nhất mà sau này bạn vẫn có thể dựng lại.

Một máy khách ở nền cộng với một đầu dò độc lập khởi chạy bản sao khác khi không thấy giao diện là mẫu đi sai. Khi đó cả hai tiến trình tranh nhau cùng một nút thiết bị, các tuyến và cài đặt bộ phân giải. Nếu bạn thực sự muốn một daemon, hãy đặt tùy chọn đó trên dòng lệnh mà máy khách thực sự khởi chạy:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Hai chi tiết trên dòng đó có trọng lượng. --background tách tiến trình ra, nên tệp pid trở thành tay nắm đáng tin cậy duy nhất trên nó, và thời gian chờ chỉ bị tiêu khi chính tiến trình đó còn sống; một giám sát giết nó không để lại ngân sách để tiếp tục.

Ngắt kết nối có chủ đích cần tín hiệu riêng. Một khoảng tạm dừng theo kế hoạch và một sự cố thật trông giống hệt nhau với người quan sát ngây thơ, và cả hai đều bị đọc là «không kết nối». Hãy điều khiển việc tạm dừng qua thao tác dừng của giám sát, hoặc qua một dấu mà lớp bao hiểu được, để việc dừng có chủ đích không kích hoạt một lần khởi động lại mà không ai yêu cầu.

Ngăn việc bàn giao chạy đua với vòng thử lại

Phục hồi không giám sát phụ thuộc vào thông tin xác thực được gia hạn mà không có người hiện diện. Một chùm khóa chỉ mở trong phiên máy tính tương tác, hoặc một token luôn đòi mã được gõ, sẽ khiến máy khách mắc kẹt ở bước xác thực khi đường dẫn trở lại. Hãy giải quyết luồng công việc đó trước khi kéo dài cửa sổ, vì cửa sổ dài hơn chỉ cho cùng một lời nhắc bị chặn nhiều thời gian thất bại hơn.

Không nên nới lỏng việc xác minh máy chủ để giảm lời nhắc. Chính ghim hoặc neo tin cậy xác thực cổng là thứ làm cho kết nối lại tự động an toàn, và việc tắt nó để tránh câu hỏi về chứng chỉ đánh đổi một gián đoạn nhìn thấy được lấy một gián đoạn vô hình. Hãy giữ danh tính đã xác minh và sửa lời nhắc thay vào đó; một máy khách sẵn sàng kết nối tới bất kỳ cổng nào còn tệ hơn một máy khách dừng lại và chờ.

Sự hiện diện của giao diện cũng không phải tín hiệu sức khỏe. Một thiết bị đường hầm có thể tồn tại với một phiên đã chết phía sau, và một tiến trình khởi chạy có thể tồn tại mà không có đường hầm nào. Không quan sát nào trong số đó trụ được trước một yêu cầu thật. Sức khỏe phải đến từ thứ người dùng cần, ví dụ một yêu cầu đi qua đường hầm tới một dịch vụ nội bộ đã biết.

Cần xác minh gì trong và sau sự cố

Hãy chạy bốn sự kiện như các bài kiểm tra riêng: một gián đoạn ngắn hơn cửa sổ, một sự cố dài hơn nó, một lỗi xác thực và một lần dừng có chủ đích. Mỗi sự kiện phải kết thúc ở một trạng thái khác nhau và dự đoán được, và ranh giới giữa hai sự kiện đầu là toàn bộ lý do để chọn một giá trị.

Hãy giữ các kiểm tra hướng ra ngoài, vì bảng tiến trình tự nó chứng minh rất ít. Quan sát xem pid có ổn định suốt đoạn cắt ngắn không, rồi xác nhận rằng sau đoạn dài nó đã biến mất và được thay thế một lần:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Trong gián đoạn ngắn, hãy xác nhận máy khách thực sự đã thử lại thay vì thoát sớm, và các tuyến cùng mục bộ phân giải đã trở lại mà không trùng lặp. Với sự cố dài hơn, hãy xác nhận một lần thoát sạch và đúng một lần khởi động lại theo sau. Với lỗi xác thực, hãy xác nhận máy khách không quay vòng trước một cổng sẽ tiếp tục từ chối nó. Hãy thêm một kiểm tra rằng pid trở về một giá trị duy nhất thay vì tích tụ.

Với lần dừng có chủ đích, URL sức khỏe phải vẫn không truy cập được và tiến trình phải vẫn ở trạng thái xuống. Sau đó đóng vòng từ phía ứng dụng: cùng yêu cầu đó phải thất bại khi đường hầm không còn và phải thành công sau khi nó trở lại, từ địa chỉ nguồn mà chính sách của bạn mong đợi. Một biểu tượng đường hầm màu xanh không phải bằng chứng, nhưng một yêu cầu hoàn tất thì là bằng chứng.