OpenVPN báo active (exited)? Tìm instance bạn đã khởi động

Bạn kiểm tra tunnel, chạy systemctl status openvpn và nhận active (exited) không có Main PID cùng danh sách tiến trình trống. Cách đọc tự nhiên là dịch vụ đã khởi động rồi chết, nên bạn mở unit, thấy /bin/true và kết luận gói bị hỏng. Trong cách đóng gói Debian, trạng thái đó là wrapper đang làm việc đúng thiết kế, còn tunnel sống trong một trong các instance unit mà nó khởi động. Unit tổng hợp sẽ không bao giờ cho bạn biết instance nào đã tạo ra nó.

active (exited) trên unit này thực sự nghĩa là gì

Unit được đóng gói là tác vụ một lần: ExecStart của nó là /bin/true, và RemainAfterExit=yes là thứ giữ một unit đã xong vẫn được báo cáo là active (exited). Bỏ chỉ thị đó đi thì cùng tác vụ /bin/true thành công ấy kết thúc ở inactive (dead), đúng trạng thái mà người ta mong đợi và đọc sai theo hướng ngược lại. Lệnh chỉ là chỗ giữ chỗ, và unit báo cáo về công việc mà các unit khác làm. Không có gì hỏng trong cách sắp xếp đó, và thay /bin/true là đổi hợp đồng đóng gói chứ không phải tunnel.

Wrapper ủy thác. Nó khởi động các instance unit do cấu hình gói hoặc bộ sinh systemd của gói cung cấp, vì thế danh sách tiến trình trống không chứng minh gì về tunnel. Khi không chọn instance nào, wrapper vẫn thành công và vẫn không khởi động gì. Trạng thái trả lời wrapper có chạy hay không, chứ không phải có tunnel hay không.

Đọc ba dòng của đầu ra status chứ không phải từ trong ngoặc. Loaded nêu tệp unit mà systemd đã đọc, Active mang dấu thời gian lần chạy thành công cuối, và Main PID vắng mặt khớp với một tác vụ một lần đã xong. Ba dòng đó cũng là cách phân biệt wrapper này với một dịch vụ sụp một giây sau khi khởi động.

Liệt kê các unit trước khi đọc lại status

Hỏi systemd cái gì tồn tại trước khi hỏi cái gì đang chạy. Một template có thể được cài trong khi chưa có instance nào được tạo, và chỉ unit được tạo mới mang tunnel. Bắt đầu từ tập đã nạp:

systemctl list-units 'openvpn*'

Danh sách đó là những gì systemd đã nạp ngay lúc này, và là thứ gần nhất với bản kiểm kê tunnel. Các tệp unit đã cài trả lời câu hỏi khác, và danh sách đó vẫn hiện template khi chưa có gì được tạo:

systemctl list-unit-files 'openvpn*'

Đọc cả hai danh sách cùng nhau, vì template ở danh sách thứ hai và instance ở danh sách thứ nhất là hai câu trả lời khác nhau. Template tồn tại và instance đang chạy không phải cùng một sự thật, và chỉ cái thứ hai mới nghĩa là tunnel. Cách bố trí gói cũng khác nhau giữa các bản phân phối và phiên bản OpenVPN. Template openvpn@ cũ hơn, cặp client và server tách rời, và wrapper của bản phân phối đều có thể hợp lệ trong cách đóng gói của chúng.

Hãy thích nghi với máy của bạn chứ không phải bài hướng dẫn bạn tìm được. Tên instance trong đầu ra của người khác có thể là office trong khi của bạn là home hoặc work. Thứ được truyền đi là phương pháp, không phải chuỗi.

Đi theo tên instance đến tệp mà nó đọc

Trong template client upstream, thư mục làm việc của unit là /etc/openvpn/client và lệnh của nó lấy %i.conf từ đó, nên openvpn-client@office đọc /etc/openvpn/client/office.conf. Xác nhận ánh xạ đó trên unit đã cài thay vì tin vào ví dụ, vì template bạn có thể cũ hơn hoặc do bản phân phối viết lại:

systemctl cat [email protected]

Đọc các drop-in xuất hiện ở cuối đầu ra đó, vì một tệp dưới .d/ có thể đổi ExecStart, thư mục làm việc hoặc đường dẫn cấu hình. Hồ sơ bạn tải về với tên office.ovpn không phải tệp mà instance mở. Khoảng cách đó là lý do thường gặp khiến lỗi nêu một đường dẫn bạn chưa từng sửa.

Đường dẫn tương đối trong hồ sơ là cái bẫy tiếp theo. Di chuyển tệp chính trong khi các tham chiếu ca, cert và key vẫn tương đối chỉ đổi lỗi thiếu tệp này thành lỗi thiếu tệp khác. Cái thứ hai trỏ tới một tệp mà bạn chắc chắn là có, nên thư mục hồ sơ quan trọng hơn tên tệp.

Khởi động nó, rồi đọc nhật ký của instance đó

Khởi động instance bạn vừa kiểm tra, vì nhật ký của unit tổng hợp sẽ không chứa lỗi của tunnel. Sau đó đọc nhật ký của lần khởi động này và tìm theo thứ tự đó lỗi cấu hình, lỗi truy cập tệp và lỗi kết nối, vì mỗi lỗi hỏng ở một giai đoạn khác nhau của quá trình khởi động.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Khởi động và bật là hai quyết định riêng: start chạy unit ngay bây giờ, enable sắp xếp lần khởi động sau, và enable --now làm cả hai trong một bước. daemon-reload đọc lại định nghĩa unit và không khởi động lại tiến trình đang chạy cũng không áp dụng hồ sơ đã sửa. Sau khi đổi hồ sơ, hãy khởi động lại instance, vì đó là thứ đọc lại tệp.

Đừng đặt trình quản lý thứ hai trên cùng một tunnel

NetworkManager và các trình quản lý phiên OpenVPN 3 có trạng thái kết nối riêng, và một instance systemd bên cạnh một trong số đó đặt hai chủ sở hữu lên cùng một tunnel. Triệu chứng là tunnel lên rồi bị thay thế vài giây sau, hoặc một tunnel từ chối ở yên trạng thái dừng. Hãy chọn trình quản lý mà bản phân phối của bạn ghi tài liệu cho môi trường đồ họa, và dùng systemd một cách có chủ đích trên máy chủ.

Kiểm tra xem đã có chủ sở hữu chưa trước khi khởi động instance. Khi một applet màn hình hiển thị kết nối, instance bạn khởi động sẽ cạnh tranh với nó thay vì hoàn thiện nó. Vô hiệu hóa trình quản lý bạn không dùng thay vì chạy cả hai và hy vọng thứ tự giữ được. Xung đột đó cũng giải thích những nhật ký nơi tunnel được thiết lập rồi bị một tiến trình bạn chưa từng khởi động phá bỏ.

Trả lời câu hỏi ban đầu bằng tên instance, tệp nó đã đọc và dòng nhật ký đã hỏng.Ghi chú của OpenVPN về tích hợp systemd mô tả cách bố trí template và ánh xạ tệp mà qua đó tên instance được phân giải.