systemd dừng dịch vụ VPN: khớp Type= với máy khách

Các unit có thể trông đúng, systemctl start có thể báo thành công, và mười giây sau dịch vụ nằm ở trạng thái không hoạt động. Hoặc nó khởi động lại mỗi nửa phút cho đến khi giới hạn khởi động dừng nó. Không hành vi nào là lỗi mạng: unit mô tả vòng đời tiến trình không khớp với điều máy khách thực sự làm. Máy khách có thể fork rồi thoát, hoặc cấu hình phiên rồi thoát ngay.

Vì sao unit thành không hoạt động vài giây sau khi khởi động thành công

systemd suy ra trạng thái từ tiến trình mà nó đã khởi động, nên Type= là một khẳng định về tiến trình đó, không phải tài liệu. Với Type=simple unit được tính là hoạt động trong khi lệnh chạy và thành không hoạt động khi lệnh trả về. Vì thế một máy khách giao kết nối cho trình trợ giúp rồi thoát trông như bị sập, ngay cả khi đường hầm đang hoạt động. Nhật ký sau đó cho thấy một mẫu khởi động và dừng đọc như một tệp nhị phân hỏng.

Hãy đọc loại unit bên cạnh hành vi của máy khách trước khi chạm vào cấu hình mạng.

Chọn loại khớp với máy khách

Hai mẫu bao phủ hầu hết CLI của nhà cung cấp: một lệnh cấu hình phiên rồi thoát, và một lệnh fork trình trợ giúp trước khi trả về. Mỗi loại cần một dạng unit khác nhau.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot cùng với RemainAfterExit=true giữ unit hoạt động sau khi lệnh trả về, điều này khớp với mẫu cấu hình rồi thoát, và lệnh dừng cho dịch vụ một lần đóng sạch. Máy khách fork giữ nguyên dạng đó nhưng cần Type=forking để systemd theo dõi tiến trình con. Đặt Restart=on-failure, RestartSec=30 và một StartLimitBurst hữu hạn, để sự cố của nhà cung cấp không biến thành vòng lặp khởi động lại chôn vùi lỗi.

Đừng bao giờ để một máy khách được giám sát trở thành daemon

Các trình giám sát bên ngoài systemd đụng cùng một bức tường. Một script chạy của runit khởi động máy khách đã thành daemon sẽ quay lại trình giám sát ngay lập tức, và nó đọc lần trả về đó như một vụ sập rồi khởi động thêm một bản sao. Mọi trình giám sát đều mong sở hữu tiến trình ở tiền cảnh, như sshd -D vẫn đứng phía trước. Bỏ cờ daemon cho các lệnh được giám sát và để trình giám sát làm phần nền. Các script bọc quay về trước khi đường hầm tồn tại cũng gây ra sự nhầm lẫn tương tự.

Một tiến trình tự tách khỏi chính nó là vô hình với mọi thứ lẽ ra phải theo dõi nó.

Phiên kết thúc và mang đường hầm đi theo

Một phiên máy tính để bàn sở hữu máy khách mà nó khởi động. Kết thúc đăng nhập và bus phiên biến mất, mang theo đường hầm, điều này giải thích vì sao kết nối của máy khách đồ họa thường rớt khi cửa sổ cuối cùng đóng lại. Máy chủ nên dùng unit hệ thống hoặc hồ sơ NetworkManager tự khởi động. Unit người dùng chỉ có nghĩa khi đường hầm phải kết thúc cùng lần đăng nhập, nên hãy gắn nó vào mục tiêu của phiên đồ họa và nêu điều đó trong phần mô tả.

Người dùng dịch vụ là nửa còn lại của cùng vấn đề. Một khóa thuộc sở hữu của root với chế độ 0600 là không đọc được với unit chạy dưới tài khoản khác, bất kể sudo đã đạt được gì trong shell của bạn.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

Xếp các phụ thuộc sau khi địa chỉ tồn tại

Khi một daemon gắn vào địa chỉ đường hầm chưa được tạo, nó thoát với Cannot assign requested address. Cách sửa là xếp thứ tự rõ ràng, không phải vòng lặp thử lại.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= xếp thứ tự các công việc, còn Requires= trên unit thiết bị gắn phụ thuộc vào sự tồn tại của giao diện, điều này mạnh hơn chỉ chờ mục tiêu mạng. Tải lại trình quản lý sau khi sửa và khởi động lại dịch vụ phụ thuộc, rồi đọc nhật ký của nó thay vì cho rằng thứ tự đã có hiệu lực. Gửi đầu ra của máy khách vào nhật ký bằng StandardOutput=journal hoặc một tùy chọn log, vì một máy khách được giám sát ghi vào tệp không ai mở trông giống hệt một cái chưa từng khởi động.

Sau đó khởi động lại một lần và xác nhận unit hoạt động sau khi thiết bị đường hầm xuất hiện. Một bản sửa chỉ được kiểm chứng bằng systemctl start thì chưa kiểm tra thứ tự khởi động mà nó phải sửa.