journalctl cho nhật ký VPN: unit nào sở hữu kết nối?

Hãy bắt đầu từ unit systemd thực sự sở hữu kết nối VPN, không phải từ lệnh nhật ký mà bạn nhớ. Một dịch vụ OpenVPN trực tiếp, một unit wg-quick và một hồ sơ NetworkManager đặt các thông điệp hữu ích của chúng vào những unit khác nhau, và một truy vấn vào unit sai sẽ cho kết quả rỗng trông như im lặng. So sánh ba chủ sở hữu phổ biến, thu hẹp cửa sổ, rồi đọc các giai đoạn theo thứ tự.

So sánh ba chủ sở hữu phổ biến

Dịch vụ máy khách OpenVPN thường là một unit cá thể được đặt tên theo hồ sơ, ví dụ [email protected]. Các thông điệp của nó bao gồm đường dẫn cấu hình, việc phân tích tùy chọn, bắt tay TLS và việc cài đặt tuyến đường mà máy khách thực hiện.

Một unit wg-quick im lặng hơn theo thiết kế. Cấu hình giao diện diễn ra khi khởi động, việc bắt tay do nhân xử lý, và các lần làm mới khóa định kỳ không được ghi lại mặc định, nên wg show thường có nhiều thông tin hơn nhật ký. Sự khác biệt đó quan trọng khi bạn so sánh một giao thức có ghi lại việc thương lượng với một giao thức không làm vậy.

NetworkManager sở hữu những hồ sơ do nó tạo ra, và các thông điệp của nó nằm dưới NetworkManager.service ngay cả khi trình cắm nền là một trình trợ giúp VPN. Hãy hỏi cả trình quản lý và unit trợ giúp khi hồ sơ được quản lý theo cách đó.

Thu hẹp truy vấn về một unit và một cửa sổ

Hỏi unit mà bạn đã xác định, và giới hạn thời gian trong lần thử mà bạn đang điều tra. Một ngày thường là đủ, và cửa sổ ngắn hơn thì tốt hơn khi máy kết nối lại thường xuyên.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

Xác minh tên đã cài đặt trước khi tin vào truy vấn. Việc đóng gói của bản phân phối đổi tên các unit, và một hồ sơ tồn tại dưới dạng tệp có thể chưa bao giờ được bật như một dịch vụ. Nếu unit không tồn tại, nhật ký rỗng đang cho bạn biết về việc triển khai chứ không phải về đường hầm.

Đọc giai đoạn thất bại đầu tiên

Đọc các sự kiện theo thứ tự chúng xảy ra: tìm điểm cuối, vận chuyển, danh tính, xác thực, cài đặt tuyến đường và lỗi sau đó của ứng dụng. Lỗi cụ thể đầu tiên là lỗi đáng điều tra, vì mọi thứ sau đó chỉ là hệ quả.

Một dịch vụ khởi động thành công không chứng minh rằng mọi tài nguyên cần thiết đều có thể truy cập. Một vòng lặp kết nối lại có thể tạo ra nhiều cuộc thương lượng riêng biệt, vì vậy hãy giữ tên hồ sơ và thời điểm thử cùng với các sự kiện, và đọc một lần thử thay vì một luồng hợp nhất. Một lần thử là một chuỗi có nguyên nhân, còn luồng hợp nhất là một bức tường gồm những dòng lặp lại. Hãy ghi lỗi đầu tiên vào phiếu trước khi đọc tiếp.

Đừng trộn dịch vụ thất bại với máy khách chạy tay

Nếu bạn khởi động máy khách bằng tay sau khi dịch vụ thất bại, đầu ra của nó đi nơi khác và hành vi có thể khác. Hãy ghi lại kết quả mới từ cùng chủ sở hữu và cùng yêu cầu sau một bản sửa được hỗ trợ, để việc so sánh cho thấy điều gì đã thay đổi thay vì trộn hai chương trình khác nhau.

Đừng sửa dấu thời gian gốc để căn với máy chủ khác. Hãy ghi riêng múi giờ và mọi chênh lệch đồng hồ đã biết, vì một dòng thời gian bạn đã chỉnh sửa không còn là bằng chứng.

Chia sẻ một trích đoạn, không phải bản xuất

Các mục nhật ký có thể chứa tên người dùng, địa chỉ điểm cuối, cấu trúc liên kết riêng và thông tin môi trường tập lệnh. Hãy xem xét trích đoạn thực tế và che phần nhạy cảm thay vì công bố một bản xuất đầy đủ không giới hạn. Trích dẫn những dòng chứng minh thất bại và tóm tắt phần còn lại. Một trích đoạn ngắn đã xem xét dễ dùng hơn một tệp mà không ai đọc.

Gửi cửa sổ hẹp, tên unit và giai đoạn thất bại đầu tiên, và nói rõ bạn đã loại trừ những gì. Hướng dẫn systemd journalctl ghi lại các bộ chọn và tùy chọn đầu ra nếu bạn cần một dạng mà phiên bản của bản phân phối hỗ trợ.