Systemd và NetworkManager: ai khởi động VPN khi khởi động máy?

Hai máy Ubuntu từ cùng một ảnh, một hồ sơ VPN, kết quả trái ngược khi đăng nhập: trên máy này đường hầm đã lên trước khi màn hình nền xuất hiện, trên máy kia nó không bao giờ lên. Hồ sơ không phải là biến số ở đây. Điều khác nhau là thành phần nào trong ba thành phần được lệnh khởi động nó, và ba thành phần đó không dùng chung một công tắc.

So sánh chúng cạnh nhau nhanh hơn là đoán mò. Mỗi cơ chế hỏng theo một cách dễ nhận ra, và đó chính là lý do việc so sánh đáng làm.

Ba bộ khởi động với ba tác nhân khác nhau

Dịch vụ openvpn đóng gói là con đường lâu đời nhất. Script init của nó đọc danh sách tự khởi động từ /etc/default/openvpn. Nếu danh sách đó bị chú thích hoặc để trống, script sẽ khởi động mọi cấu hình nó tìm thấy trong thư mục ấy thay vì đúng cấu hình bạn đã thêm. Một tệp thêm cho một đường hầm có thể âm thầm dựng lên vài đường.

Hàng thứ hai là hàng người ta cấu hình sai. NetworkManager giữ hồ sơ đã nhập và sẽ khởi động nó, nhưng chỉ với vai trò thứ cấp của một kết nối khác, nghĩa là tác nhân thuộc về liên kết mạng chứ không thuộc về VPN.

So sánh chi phí thiết lập và phạm vi

Con đường script init chỉ tốn một dòng và bao trùm mọi cấu hình trên máy. Điều đó đúng với router và sai với laptop hay chuyển giữa các mạng. Con đường NetworkManager tốn một lần tra UUID và gắn đường hầm vào một kết nối nền. Nó lên ở SSID của cơ quan và vẫn tắt ở mạng khách sạn.

Một unit viết tay tốn kém nhất và đem lại nhiều quyền kiểm soát nhất, kể cả thứ tự so với các dịch vụ khác. Phạm vi là yếu tố quyết định. Nếu máy chỉ có một mạng và một đường hầm thì dịch vụ đóng gói là trung thực và dễ đoán. Nếu đường hầm phải đi theo một mạng Wi-Fi cụ thể thì thành phần thứ cấp là cái duy nhất trong ba diễn đạt được điều kiện đó mà không cần script thêm.

Chọn một chủ sở hữu và gỡ những cái còn lại

Một hồ sơ do hai chủ sở hữu khởi động tạo ra thời điểm thay đổi giữa các lần khởi động, tệ hơn cả khi chỉ dùng một trong hai cơ chế. Hãy chọn chủ sở hữu, rồi tắt con đường cạnh tranh một cách có chủ ý chứ không phải vô tình.

# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'

# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"

Nếu con đường bị loại bỏ là con đường đóng gói, hãy làm đúng thứ tự: đặt AUTOSTART thành none, chạy systemctl daemon-reload để các unit được sinh ra nhận danh sách mới, rồi tắt phiên bản mẫu mà bạn không còn cần. Bỏ qua lần nạp lại sẽ để các unit cũ vẫn hoạt động, và trông như thay đổi không có tác dụng gì.

Một lần dừng bị treo là vấn đề riêng với câu trả lời có giới hạn. TimeoutStopSec giới hạn thời gian systemd chờ trước khi gửi SIGKILL. Tệp drop-in là chỗ đúng để đặt nó, vì sửa unit đóng gói sẽ mất thay đổi ở lần nâng cấp sau.

Kiểm chứng điều gì thực sự đã khởi động

Khởi động lại và đọc bằng chứng thay vì tin vào tệp cấu hình. Unit sở hữu đường hầm sẽ hiển thị trạng thái hoạt động và mốc thời gian khởi động khớp với lần khởi động máy, và giao diện VPN sẽ tồn tại trước khi bạn đăng nhập.

systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0

Ở đây còn một phép kiểm tra nữa: xác nhận rằng ExecStart của unit trỏ tới đúng tệp nhị phân bạn nghĩ. Một ứng dụng khách biên dịch cục bộ hoặc gói snap thường cần đường dẫn tường minh hoặc lớp bọc snap run, vì systemd không kế thừa thứ tự tìm kiếm của shell bạn. So sánh command -v openvpn với tệp unit sẽ giải quyết việc đó trong vài giây.

Ghi chủ sở hữu đã chọn vào ghi chú của máy, cạnh tên hồ sơ. Người tiếp theo gỡ lỗi một đường hầm mất tích sẽ bắt đầu từ dòng đó thay vì lặp lại việc so sánh.