Thực ra instance OpenVPN nào đang dùng hồ sơ PiVPN của bạn?

PiVPN ghi một cấu hình máy chủ và một hồ sơ máy khách, rồi thoát; nó không bao giờ trở thành tiến trình mang lưu lượng của bạn. Vì thế một handshake thất bại, một máy khách gọi sai điểm cuối, hay một dịch vụ trở lại sai sau khi khởi động lại đều không thể giải thích từ menu của trình cài đặt. Những triệu chứng đó thuộc về daemon OpenVPN đang chạy bây giờ, cấu hình mà daemon đó thực sự đã nạp, và nhật ký mà nó được trỏ tới. Bốn lệnh chỉ đọc thường giải quyết được việc này, và không lệnh nào trong số đó thay đổi chứng chỉ hay khóa của bạn.

Trợ lý và daemon là hai đối tượng khác nhau

Sự nhầm lẫn dễ giải thích: một thư mục chứa tệp do trợ lý tạo ra, tệp mà daemon đọc, và đôi khi cả một bản sao cũ của cả hai. Trợ lý là một script chuẩn bị. Nó cài gói, ghi tệp unit và in hồ sơ máy khách, rồi công việc của nó kết thúc. Cái còn lại là một mục trong trình quản lý dịch vụ và một dòng lệnh.

Trên máy chủ systemd, hãy bắt đầu từ unit đang hoạt động thay vì danh sách thư mục. Tên phụ thuộc vào cách đóng gói: ảnh Debian và Raspberry Pi OS thường cung cấp một instance mẫu như openvpn-server@server, trong khi các bản cài cũ hơn dùng openvpn@server. Hỏi trình quản lý xem cái nào đang chạy thay vì đoán từ tên tệp.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Đọc ExecStart= trong đầu ra đó. Nó nêu tệp thực thi và các tùy chọn mà trình quản lý thực sự khởi chạy, bao gồm mọi --config đường dẫn; một tệp cấu hình nằm bên cạnh mà không lệnh nào tham chiếu tới thì không thuộc tunnel đang chạy.

Lần theo chuỗi cấu hình mà daemon đã phân giải

OpenVPN không quét thư mục để tìm cài đặt. Nó đọc tệp được truyền với --config, theo mọi config chỉ thị bên trong, rồi áp dụng các tùy chọn dòng lệnh. Hướng dẫn 2.6 mô tả thứ tự đó, và điều này quan trọng khi hai tệp bất đồng về cổng, thiết bị hay mật mã.

Trước hết hãy đổ lời gọi thực tế ra, rồi xem các chỉ thị quyết định danh tính và khả năng tiếp cận. Cả hai lệnh đều chỉ đọc và an toàn trên máy chủ đang chạy, dù lệnh thứ hai in ra những đường dẫn mà bạn có thể không muốn có trong một ticket công khai.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Một tệp .ovpn trong thư mục nhà là hiện vật phía máy khách. Daemon máy chủ không bao giờ đọc nó, nên việc sửa tệp đó để chữa lỗi handshake phía máy chủ không đạt được gì.

Include là cái bẫy khác. Một dòng config kéo vào tệp thứ hai mà các tùy chọn của nó được xử lý ngay tại điểm đó, nên một chỉ thị một giá trị đến sau có thể lấn át điều mà tệp chính có vẻ nói. Nếu tệp nhìn thấy trông đúng mà daemon vẫn hành xử khác, hãy đọc tệp được include trước khi thay đổi bất cứ điều gì.

Ghép nhật ký với tiến trình, không phải với lỗi bạn nhớ

Hai đích ghi nhật ký là phổ biến, và chỉ một trong số đó là journal. Với log-append được đặt, daemon ghi vào tệp đó và journal giữ rất ít ngoài các dòng khởi động. Không có nó thì journalctl là nguồn sự kiện.

journalctl -u openvpn-server@server -n 80 --no-pager

Tương quan một lần thử kết nối với một cửa sổ thời gian. Ghi lại điểm cuối của máy khách, rồi đọc sự kiện phía máy chủ trong cùng những giây đó. Một handshake TLS không bao giờ tới được bước trao đổi chứng chỉ cho thấy vấn đề tiếp cận hoặc lệch giao thức, còn việc từ chối xác thực lại đến sau khi các tham số tunnel đã được thống nhất.

Một mục nhật ký cũ không chứng minh gì về hồ sơ bạn tải năm phút trước. Tạo lại tệp máy khách, kết nối một lần, và chỉ đọc những dòng xuất hiện trong lần thử đó.

Hãy ghi lại lỗi cụ thể đầu tiên thay vì lỗi chung cuối cùng. Lỗi bind, một trao đổi bên ngoài không phản hồi, một lần từ chối chứng chỉ và một lần từ chối tài khoản dẫn bạn tới mỗi lớp khác nhau, và một timeout ở cuối thường che mất sự kiện hữu ích bên trên.

Dựng lại tunnel không phải là bước chẩn đoán

Lối tắt hấp dẫn là dựng một tunnel thứ hai đơn giản hơn: khóa tĩnh, không chứng chỉ, không xác thực thêm. Nó thường sẽ kết nối, và nó chỉ chứng minh hai máy chủ có thể chuyển UDP hay TCP giữa nhau. Nó không nói gì về việc vì sao bản triển khai xác thực bằng chứng chỉ thất bại, và nó lặng lẽ thay thế mô hình bảo mật mà bạn được yêu cầu giữ.

Điều tương tự áp dụng cho việc tắt tls-auth hay tls-crypt, nới lỏng verify-x509-name, hoặc bỏ yếu tố thứ hai để có trạng thái xanh. Một tunnel kết nối được vì đã gỡ bỏ kiểm tra là một hệ thống khác, không phải hệ thống đã sửa.

Thực hiện một thay đổi có phạm vi ở lớp mà nhật ký đã nêu, khởi động lại đúng unit đó, và lặp lại lần thử kết nối duy nhất. Điều đó giữ phép so sánh trung thực, và để lại một thay đổi bạn có thể hoàn tác.

Cần bàn giao gì cho người tiếp theo

Ghi lại bốn dữ kiện khi bạn còn giữ chúng: phiên bản OpenVPN từ openvpn --version, unit đang hoạt động, chuỗi cấu hình cùng các include của nó, và cửa sổ nhật ký bao trùm một lần thử. Bốn điều đó biến một phàn nàn mơ hồ thành một ca có thể tái lập.

Hãy che dữ liệu nhạy cảm trước khi chia sẻ. Khóa riêng, auth-user-pass tệp, vật liệu khóa tĩnh và gói máy khách đầy đủ không thuộc về một ticket; tên tùy chọn và hình dạng chuỗi thường đủ cho cặp mắt thứ hai.

Nếu chuỗi còn nguyên vẹn và nhật ký vẫn chỉ vào mạng, bước tiếp theo là đường đi giữa máy khách và máy chủ chứ không phải một bản cài khác. Đó là phần duy nhất của câu chuyện mà trợ lý chưa bao giờ sở hữu.