Nhật ký gỡ lỗi L2TP trống? Lỗi có lẽ nằm trong journal

Bạn khởi động trình trợ giúp L2TP với gỡ lỗi, nhìn vào terminal, và nó dừng lại mà không có gì hữu ích trên màn hình. Đây không phải là cờ gỡ lỗi bị hỏng. Một kết nối NetworkManager L2TP gồm bốn tiến trình phối hợp với nhau, và chỉ một số trong đó ghi vào terminal bạn đang xem. Phần bằng chứng còn lại nằm trong journal, cách một bộ lọc.

Bốn tiến trình, hai đích ghi nhật ký

Kết nối bắt đầu bằng IPsec, là libreswan hoặc strongSwan tùy bản cài đặt. Sau đó daemon L2TP, theo truyền thống là xl2tpd và trong một số bản dựng là kl2tpd, điều khiển đường hầm. Cuối cùng pppd xử lý xác thực và địa chỉ bên trong nó.

Dịch vụ trợ giúp điều phối các phần đó và in tiến trình của chính nó. Daemon IPsec và pppd thường báo cáo qua journal hệ thống, vì thế terminal hiển thị một kết nối thất bại trong khi lý do nằm trong tệp bạn chưa mở.

Sự tách biệt đó cũng giải thích vì sao lỗi PSK và lỗi mật khẩu trông giống nhau từ màn hình nền: cả hai đều tạo ra một ngắt kết nối chung, và giai đoạn thất bại chỉ hiển thị trong đầu ra của từng tiến trình. Đó là toàn bộ lý do journal quan trọng ở đây. Một thông báo chung trên màn hình nền, bốn tác giả khả dĩ phía sau.

Thu thập một lần thử, rồi đọc thứ tự

Tái hiện một lần, với hồ sơ đã biết và thời điểm đã biết, rồi đọc một cửa sổ hẹp thay vì toàn bộ lần khởi động. Lặp lại các lần thử trong khi thay đổi cài đặt biến nhật ký thành một hỗn hợp không thể diễn giải.

Các lệnh này chọn các tiến trình tham gia cho lần khởi động hiện tại, và đáng để xác nhận đường dẫn plugin trên bản phân phối của bạn:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Các trường lặp lại trong một lần gọi chọn hợp của các tiến trình đó, điều này giữ trình tự theo thứ tự thời gian. Trên hệ thống dựa trên Debian truy vấn tương đương là dpkg -L; vấn đề là tìm nơi trình trợ giúp thực sự sống trước khi thử chạy nó bằng tay.

Ba điều kiện quyết định bước tiếp theo

Đọc giai đoạn thất bại đầu tiên, rồi chọn theo đó. Nếu IPsec báo lỗi đề xuất hoặc xác thực ngang hàng, đường hầm chưa bao giờ được hình thành, và đổi mật khẩu PPP không thể giúp.

Nếu đường hầm đã hình thành và pppd từ chối đăng nhập, bí mật chia sẻ đã ổn và vấn đề thông tin đăng nhập nằm ở một lớp cao hơn. Nếu pppd đã thương lượng một địa chỉ và lỗi xuất hiện sau đó, cả hai đều hoạt động và vấn đề còn lại là định tuyến, DNS hoặc chính sách của máy chủ.

Ba nhánh đó bao phủ gần như mọi ngắt kết nối chung, và chúng được quyết định bởi tiến trình nào ghi lỗi cuối cùng, không phải bởi thông báo lỗi nào trông đáng lo nhất.

Cũng đáng xác nhận backend IPsec nào đã cài trước khi chạm vào cài đặt gỡ lỗi. Một tùy chọn ghi nhật ký viết cho strongSwan không làm gì khi libreswan đang chạy, và kết nối sẽ tiếp tục thất bại ở cùng chỗ trong khi bạn sửa một tệp không ai đọc.

Chế độ gỡ lỗi để lại tệp

Quy trình gỡ lỗi gốc chạy dịch vụ bằng tay với cờ gỡ lỗi, và chế độ đó có thể để lại các tệp cấu hình thời gian chạy được tạo tại chỗ khi kết nối kết thúc.

Những tệp đó chứa vật liệu xác thực: khóa chia sẻ trước, thông tin đăng nhập hoặc cả hai. Một cấu hình được tạo sao chép vào cửa sổ trò chuyện là sự tiết lộ thông tin đăng nhập, không phải trích đoạn nhật ký. Xóa các dòng bí mật trước khi chia sẻ bất cứ điều gì, và xóa thư mục khi cuộc điều tra kết thúc. Hãy coi chúng là bí mật, trích xuất các dòng cụ thể bạn cần cho báo cáo, và xóa chúng sau đó thay vì dán cả thư mục vào phiếu.

Phiên bản chạy tay cũng phải được phối hợp với phiên bản bình thường. Khởi chạy một bản sao gỡ lỗi khi dịch vụ đã sở hữu plugin tạo ra hai chủ sở hữu và một nhật ký trộn lẫn cả hai, điều này tệ hơn là không có đầu ra gỡ lỗi nào.

Sau đó khôi phục trình trợ giúp bình thường

Khi cuộc điều tra kết thúc, dừng phiên bản chạy tay, xóa các tệp thời gian chạy được giữ lại và kết nối lại theo đường bình thường để người tiếp theo thấy một cấu hình khớp với thực tế.

Sau đó xác minh kết quả ở lớp đã thất bại, không phải ở biểu tượng màn hình nền:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Một phiên xác thực, nhận địa chỉ và định tuyến đến đích dự định là kết quả bạn đang gỡ lỗi. Một terminal im lặng trong lần thử thất bại chỉ cho bạn biết nơi đầu ra không được ghi.