Vì sao máy khách OpenVPN của bạn vẫn tắt sau một lần hết thời gian chờ

Sáng thứ Hai: đường hầm dựng lên hôm thứ Sáu đã biến mất, giao diện vẫn còn trong danh sách, và không có gì trong nhật ký nói rằng ai đó đã để ý. Máy chủ vẫn trực tuyến, bảng điều khiển vẫn xanh, và mọi thứ nó gửi trong cuối tuần đều đi ra qua giao diện vật lý. Ở đây thiếu hai quyết định độc lập: một là tiến trình máy khách có sống sót qua sự cố tạm thời hay không, hai là có thứ gì đó bên trên khởi động lại tiến trình sau khi nó thoát hay không. Chỉ sửa một trong hai sẽ để lỗ hổng kia mở.

Hãy bắt đầu từ việc thiết bị thực sự đã làm, không phải từ điều giám sát khẳng định. systemctl status openvpn-client@office và journalctl -u openvpn-client@office -n 50 cho thấy lý do thoát và dòng cuối cùng máy khách ghi trước khi rời đi.

Tiến trình thoát trước khi ai đó để ý

Máy khách biến mất mà không có lỗi thường đã thoát một cách có chủ ý. Hồ sơ quyết định hành vi đó, không phải trình quản lý dịch vụ: ping-exit kết thúc tiến trình ngay khi bên kia ngừng phản hồi, trong khi ping-restart giữ tiến trình và tự kết nối lại bên trong nó. Giới hạn phiên và bộ hẹn giờ không hoạt động tạo ra cùng một hình ảnh từ bên ngoài: không đường hầm và không báo động.

Hai chỉ thị ping không thể cùng nằm trong một hồ sơ, vì vậy hãy chọn một và ghi lại lựa chọn. Cũng hãy xem máy chủ, vì ping-exit của chính nó đóng phiên bất kể máy khách yêu cầu gì, và chỉ nhật ký máy chủ ghi lại ai đã ra quyết định đó.

Chọn giữa ping-exit và ping-restart

Chọn ping-restart cho máy tính xách tay hoặc địa điểm xa cần tự chữa lành, và để dành ping-exit cho những trường hợp đường hầm chết phải dừng tiến trình để thứ khác có thể phản ứng. Các con số ít quan trọng hơn mối quan hệ: ping 10 với ping-restart 60 nghĩa là mười giây im lặng trước khi kiểm tra và sáu mươi giây trước khi khởi động lại, điều này hung hăng trên một liên kết di động có mất gói và hợp lý trên liên kết có dây. Hãy ghi lý do bên cạnh dòng, nếu không người đọc tiếp theo sẽ cho rằng các giá trị mặc định là có chủ ý.

Sau đó xác nhận rằng thứ đã thoát thực sự là tiến trình. Một thiết bị báo cáo đang hoạt động trong khi đường hầm đã chết là một lỗi khác, được bàn ở dưới.

Giám sát thực sự khởi động lại thiết bị

Trên máy chủ systemd, thay đổi lâu dài nhỏ nhất là một tệp drop-in: Restart=on-failure và RestartSec=10 trong /etc/systemd/system/[email protected]/restart.conf. Tệp drop-in chỉ được đọc khi systemd tải lại các định nghĩa của chính nó, vì vậy hãy chạy systemctl daemon-reload sau đó. Hãy xác minh bằng systemctl show -p Restart -p ExecMainStatus openvpn-client@office thay vì cho rằng giá trị đã vào. Phiên bản trong tên tệp phải là hồ sơ mà thiết bị thực sự tải, vì vậy một tệp viết cho office không có tác dụng gì với openvpn-client@home.

on-failure bỏ qua một trường hợp: thoát sạch với trạng thái bằng không. Một số đường tháo gỡ kết thúc như vậy, nên hãy đọc trạng thái đã ghi thay vì tin vào cách diễn đạt của một trang hướng dẫn. Nếu máy khách của bạn bỏ cuộc với số không, bạn cần Restart=always, và cái giá là một hồ sơ thực sự hỏng sẽ quay lại hết lần này đến lần khác cho đến khi giới hạn tốc độ khởi động kích hoạt và nhật ký đầy.

Restart=always cũng kích hoạt sau khi dừng có chủ ý. Dùng systemctl stop để bảo trì, và che thiết bị nếu nó phải ở trạng thái tắt trong khi bạn làm việc.

Bắt rò rỉ khi đường hầm tắt

Giám sát đưa đường hầm trở lại; nó không ngăn lưu lượng đi ra trong khi đường hầm vắng mặt. persist-tun giữ thiết bị và các tuyến của nó qua các lần kết nối lại, điều này tiện lợi và mở ra một cửa sổ. Thiết bị sống sót, các tuyến vẫn trỏ vào nó, và các gói thoát ra ngoài mà không được bảo vệ và không được báo cáo. Đó là một lựa chọn chính sách, không phải giá trị mặc định trung lập.

Khi một máy chủ không được phép phát ra gói không được bảo vệ nào cả, chỉ tường lửa mới có thể bảo đảm điều đó. Một quy tắc đầu ra cho phép giao diện đường hầm và địa chỉ máy chủ VPN trong khi bỏ mọi thứ khác vẫn có hiệu lực sau khi máy khách chết, và không có gì trong cấu hình của chính máy khách có thể lọc lưu lượng mà máy khách không mang.

Hãy thử bằng cách dừng máy khách một cách có chủ ý. Chạy systemctl stop openvpn-client@office, rồi curl -m 5 https://example.com, lệnh này phải thất bại thay vì thành công qua liên kết vật lý. Thành công nghĩa là quy tắc tường lửa bị thiếu hoặc quá dễ dãi.

Kết nối lại, xác nhận đường hầm lại mang lưu lượng, và chỉ khi đó mới thêm bước kiểm tra vào giám sát. Việc thăm dò ip addr từ cron cho một thiết bị tun là giám sát thất bại thường xuyên nhất, vì với persist-tun thiết bị sống lâu hơn phiên và bước dò báo cáo khỏe mạnh trong khi không có gì được mang.