L2TP: tín hiệu chết 15, NO_PROPOSAL_CHOSEN và modp1024 mất tích

Kết nối của bạn treo, ứng dụng khách thoát và dòng cuối trên màn hình là death_handler: Fatal signal 15 received. Dòng đó báo một lần ngắt, không phải nguyên nhân. Một dòng phía trên trong nhật ký IPsec gần như luôn có NO_PROPOSAL_CHOSEN, và cặp này chỉ vào pha 2 của quá trình trao đổi, nơi hai bên so sánh lựa chọn mã hóa và băm rồi dừng lại khi không có lựa chọn chung nào. Thông tin đăng nhập chưa được gửi ở giai đoạn đó, nên gõ lại mật khẩu không thể thay đổi kết quả.

Trên một máy khách Linux, thường có hai điều làm rỗng phần giao đó. Daemon cục bộ có thể không còn triển khai nhóm Diffie-Hellman mà hồ sơ yêu cầu, hoặc hồ sơ mang một đề xuất pha 1 trong trường pha 2. Cả hai đều để lại dấu vết trong nhật ký, và không cái nào là vấn đề tài khoản.

Hai thông báo thực sự nói gì

IKE thương lượng theo từng lượt. Pha 1 dựng một kênh được bảo vệ và tự chọn thuật toán; pha 2, tức SA con, mang lưu lượng dưới một bộ riêng. NO_PROPOSAL_CHOSEN là thông báo mà bên trả lời gửi lại khi không tổ hợp nào được đề nghị là chấp nhận được, và nó xuất hiện dưới dạng [ HASH N(NO_PROP) ] bên trong một lượt trao đổi INFORMATIONAL.

Tín hiệu 15 là một sự kiện khác: có gì đó bảo tiến trình cục bộ dừng lại và bộ xử lý đã ghi lại. Khi cả hai dòng xuất hiện cùng nhau, thứ tự là nhân quả, từ chối trước rồi mới tắt.

Hãy đọc cuộc thương lượng trước khi chạm vào thông tin đăng nhập

Nâng mức nhật ký ở nơi daemon ghi, rồi kết nối lại trong khi theo dõi đầu ra. Trên máy có NetworkManager, plugin L2TP chuyển mức đó cho phần phía sau, và thông báo rơi vào journal hoặc tệp syslog cổ điển tùy bản phân phối. Bất kỳ lệnh nào trong số này sẽ cho thấy cuộc trao đổi: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' hoặc tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Dòng nêu tên pluto đến từ libreswan, charon đến từ strongSwan, và cả hai mô tả cùng một trạng thái bằng từ khác nhau. Dạng đáng tìm là dạng nêu tên nhóm bị thiếu, ví dụ algorithm 'modp1024' is not supported, vì nó biến một lỗi mơ hồ thành lỗi cụ thể.

modp1024 đã đi đâu

Nhóm 2 của Diffie-Hellman yếu đến mức nhiều bản phân phối đã ngừng biên dịch nó vào libreswan từ phiên bản 3.30. Khi đó một hồ sơ viết từ nhiều năm trước, hoặc lấy từ hướng dẫn cổng chỉ liệt kê aes128-sha1-modp1024, yêu cầu daemon cục bộ làm điều mà nó hoàn toàn không làm được. Các bản dựng NetworkManager-l2tp mới hơn khiến kết quả đó dễ xảy ra hơn: từ 1.2.16 chúng thay bộ này bằng các đề xuất kiểu Windows 10 và iOS và bỏ modp1024 ngay khi phát hiện libreswan. Phía đối diện thường vô can và vẫn cung cấp đúng nhóm bạn đã cấu hình.

Chính sự bất đối xứng đó khiến lỗi có vẻ ngẫu nhiên. Máy khách cũ kết nối được, cùng hồ sơ đó trên laptop đã cập nhật thì không, và cấu hình máy chủ chưa từng thay đổi. Thiệt hại do lệch phiên bản.

Hai cách sửa với phạm vi khác nhau

Cách sửa rẻ là ngừng ghi cứng thuật toán. Xóa cả hai trường đề xuất trong trình soạn thảo và để plugin chọn một bộ mà đầu bên kia chấp nhận; nếu cổng hỗ trợ các nhóm hiện đại thì thương lượng kết thúc mà không cần thêm việc.

Cách sửa thứ hai giữ một cổng cũ trong tầm truy cập bằng cách cài strongSwan, gói của nó vẫn triển khai nhóm 2 trên hầu hết bản phân phối. Đó là thay daemon, nên có giá: xác nhận xem các đường hầm khác trên máy có phụ thuộc cấu hình libreswan trước khi gỡ nó, và chờ các lần từ chối SELinux giữa NetworkManager và plugin strongSwan trên Fedora. Những lần từ chối đó xuất hiện trong nhật ký kiểm toán chứ không phải vết IKE, nên đường hầm có thể trông hỏng ngay sau khi cài thành công. Thứ tự hiệu quả là dnf install strongswan trước, rồi rpm -e libreswan.

Các chuỗi đề xuất khớp nhau, và những cái bẫy quanh chúng

Khi phải điền tay các trường, pha 1 và pha 2 nhận giá trị khác nhau. Cặp được biết là chạy được với đầu bên kia kiểu Meraki cung cấp aes128-sha1-modp1024 ở pha 1 với 3des-sha1-modp1024 phía sau, cả hai đóng bằng dấu chấm than khiến bộ trở nên nghiêm ngặt, nên chỉ những đề xuất đó được gửi.

Sau đó pha 2 thu hẹp còn aes128-sha1 và 3des-sha1 với cùng dấu nghiêm ngặt và không có hậu tố Diffie-Hellman nào. Một dòng pha 2 mang -modp1024 là giá trị pha 1 ở sai trường, và bên trả lời từ chối nó ở mỗi lần thử lại. Sao chép dòng đó sang hồ sơ thứ hai thì hồ sơ thứ hai cũng hỏng y như vậy, và đó là cách một lỗi đánh máy trở thành sự cố cho cả đội.

Các lỗi khác cũng mang cùng cửa sổ bật lên mà không phải lệch đề xuất. Trên KDE, loại L2TP có thể vẫn được liệt kê khi đã cài plugin nhưng mọi kết nối chết ngay, vì trình soạn thảo kết nối và các trợ giúp thời gian chạy được đóng gói riêng. Máy không màn hình có thể dùng lại hồ sơ từ một desktop đang chạy: sao chép từ /etc/NetworkManager/system-connections/, đặt chế độ thành 600, rồi chạy nmcli con reload. Đưa nó lên bằng nmcli con up id work-l2tp, vì dạng trần cần UUID, và xóa mọi mục ifname cũ, nếu không trình quản lý trả lời Could not find source connection trong khi mọi thứ khác đều đúng.

Khóa chia sẻ trước có thể được lưu dưới dạng văn bản rõ hoặc dưới dạng 0s theo sau là base64; cả hai dạng đều dùng được, nhưng giá trị phải khớp với cổng theo từng byte, kể cả các dấu cách ở cuối mà bạn đã sao chép kèm.