OpenVPN không khởi động: hãy đọc dòng đầu tiên, không phải tệp cấu hình

Một VPN chết trong giây đầu tiên là con vật khác với một VPN kết nối rồi mới thất bại, và sai lầm thường gặp là coi hai thứ đó là một. Ở đây không có bắt tay, không trao đổi chứng chỉ và không có tuyến để xem xét. Một dòng trong nhật ký quyết định bản sửa nào trong vài bản sửa không liên quan được áp dụng, và bỏ qua nó tốn cả buổi chiều sửa một tệp cấu hình chưa từng được đọc. Hãy đọc dòng đó trước.

Ba lệnh chỉ đọc đưa bạn tới đó: journalctl -u openvpn@server -b --no-pager trước, systemctl status openvpn@server thứ hai, và ss -lunp cho các trình lắng nghe UDP và chủ sở hữu của chúng.

Dòng đầu tiên chọn nhánh

Xung đột cổng và thiếu tệp nhị phân đều giết lần khởi động trong một giây, và chúng để lại những dòng đầu tiên khác nhau. Thông báo về địa chỉ đã được dùng nêu tên cổng; tệp thực thi bị thiếu nêu một đường dẫn không còn tồn tại; điều kiện thất bại hoặc thiếu tệp cấu hình nêu tên tệp. Ba điều đó dẫn tới những bản sửa khác nhau, và không điều nào tốt hơn nhờ cài lại ứng dụng khách. Hãy chép lỗi đầu tiên vào ghi chú trước khi chạy bất cứ thứ gì khác.

Hãy cảnh giác với vòng lặp thử lại che khuất dòng gốc. Một đơn vị có chính sách khởi động lại có thể chôn lỗi đầu tiên dưới một tá dòng giống hệt, nên journalctl -b được lọc theo đơn vị và đọc từ trên xuống tốt hơn phần đuôi.

Ai khác đang giữ cổng 1194

Thủ phạm thường không phải một máy chủ thứ hai mà ai đó cố ý cấu hình. Hãy chờ một ứng dụng khách khởi động bằng tay vẫn còn sống trong một thiết bị đầu cuối khác, một hồ sơ thứ hai tình cờ chọn cùng cổng, hoặc một gói của nhà cung cấp có đường hầm riêng giữ 1194. Chủ sở hữu ổ cắm xuất hiện trong ss -lunp; đưa PID đó cho systemctl status để biết liệu có đơn vị nào chịu trách nhiệm. Hãy hạ nó bằng chính đường điều khiển của nó, không phải bằng tín hiệu.

Một tín hiệu gửi tới tiến trình do đơn vị quản lý thường kích hoạt khởi động lại, và cùng lỗi đó xuất hiện lại chốc lát, trông như một vấn đề mới. Dùng systemctl stop cho một đơn vị, lệnh dịch vụ riêng của gói cho bản cài của nhà cung cấp, và chỉ dùng tín hiệu cho thứ bạn tự khởi động bằng tay trong shell đó.

Các đơn vị còn sót lại sau khi thanh lọc

Việc thanh lọc xóa các tệp nhị phân; những tệp đơn vị viết tay, thường nằm dưới /etc/systemd/system, vẫn sống sót qua nó. Systemd sau đó thử lại một đơn vị trỏ tới đường dẫn không còn tồn tại, và thông báo nói về tệp bị thiếu đó chứ không phải việc gỡ bỏ hôm qua. systemctl status hiển thị đường dẫn phân mảnh của đơn vị ở gần đầu, nên hãy kiểm tra nó bằng dpkg -S trước khi xóa bất cứ thứ gì. Khi mồ côi đã biến mất, systemctl daemon-reload và systemctl reset-failed xóa sạch trạng thái; nếu không, mọi lần kiểm tra trạng thái sau đó đều thừa hưởng nó.

Khi which openvpn trả lời bằng thứ gì đó dưới /usr/local, tệp nhị phân đang chạy đến từ trình cài của nhà cung cấp chứ không phải từ apt. Trình cài như vậy thường mang theo trình lắng nghe riêng, mục khởi động riêng và thư mục cấu hình riêng, nên gỡ lệnh nhìn thấy được vẫn để ổ cắm bị chiếm.

Hãy gỡ nó theo cách nhà cung cấp tài liệu, xác nhận cổng trống bằng ss -lunp, và chỉ thêm ứng dụng khách của bản phân phối nếu bạn cần.

Ổn định trạng thái trước khi thử lại

Hãy xóa trạng thái thất bại trước khi rút ra kết luận từ nó: systemctl reset-failed gỡ các bộ đếm, và systemctl status sau đó báo cáo tình trạng hiện tại của đơn vị chứ không phải lịch sử của nó. Khởi động nó một lần và đọc nhật ký của chính lần chạy đó thay vì trạng thái tổng hợp của máy. Một đơn vị báo hoạt động trong khi đường hầm không mang gì là một vấn đề riêng, và phổ biến hơn nhiều. Hai điều đó bị gộp trong các báo cáo lỗi vì cả hai đều kết thúc bằng việc người dùng nói VPN không hoạt động.

Ghi lại nhánh bạn đã chọn: xung đột cổng, thiếu tệp nhị phân, thiếu cấu hình. Lần sau bạn sẽ nhận ra nhanh hơn.