NO_PROPOSAL_CHOSEN trên L2TP? Hãy quét cổng trước

Lời nhắc tên người dùng không bao giờ xuất hiện, và máy khách báo NO_PROPOSAL_CHOSEN. Tại thời điểm đó, thông tin đăng nhập và khóa chia sẻ trước là không liên quan, vì hai đầu chưa thống nhất cách bảo vệ pha 1. Hầu hết mọi người phản ứng bằng cách dán một chuỗi mật mã tìm thấy trên mạng. Quét cổng trả lời cùng câu hỏi đó bằng bằng chứng và mất khoảng thời gian tương tự.

Thông báo này loại trừ điều gì

Việc từ chối xảy ra ở chế độ chính, trước mọi trao đổi L2TP hoặc PPP, nên đường hầm và cơ sở dữ liệu người dùng chưa được hỏi tới. Pha 1 thương lượng mã hóa, tính toàn vẹn và một nhóm Diffie-Hellman. Pha 2 thương lượng đề xuất ESP cho dữ liệu. Lỗi ở pha 1 không thể khắc phục bằng cách thay đổi thiết lập PFS của pha 2, và một liên kết IKE đã hoàn tất không chứng minh đề xuất ESP phù hợp.

Ghi lại backend trước khi sửa cú pháp: ipsec --version. libreswan và strongSwan chấp nhận các cách viết đề xuất khác nhau cho cùng thuật toán.

Sau đó đọc lý do từ chối trong ngữ cảnh với journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Quét cổng để biết tập chuyển đổi của nó

Trình quét hỏi trực tiếp cổng những chuyển đổi nào sẽ được thương lượng. Trước tiên hãy dừng dịch vụ IPsec cục bộ để phép dò không cạnh tranh với máy khách của bạn, rồi đọc các dòng SA. Hãy coi danh sách là bằng chứng về phía đối diện, không phải thực đơn để bật toàn bộ.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Các thiết bị cũ thường cung cấp 3DES, SHA1 và MODP1024, vì đó là giá trị mặc định khi sản phẩm xuất xưởng và không ai xem lại. Hãy giữ đầu ra thô của lần quét, vì đó là bản ghi duy nhất về những gì phía đối diện cung cấp ngày hôm đó. Nếu đó là mức trùng khớp mạnh nhất hiện có, hướng leo thang đúng là tới chủ cổng, không phải tới cấu hình máy khách vốn bật lại mã hóa yếu cho mọi người.

Khớp phần trùng mà không tắt an toàn

Chỉ nhập những chuyển đổi xuất hiện cả trong bản quét và trong chính sách của bạn. Ví dụ dưới đây phản ánh một cổng cung cấp 3DES, SHA1 và MODP1024 ở pha 1. Lưu ý cảnh báo về backend: libreswan 4.x không biên dịch nhóm modp1024, nên điều này áp dụng cho strongSwan hoặc bản dựng libreswan có hỗ trợ DH2. Hãy xác minh phiên bản trước khi kết luận máy khách bị hỏng.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Dấu chấm than ở cuối ghim một đề xuất duy nhất. Dùng nó để cô lập một thử nghiệm, sau đó gỡ bỏ để cổng có thể thương lượng thứ mạnh hơn về sau.

Kiểm tra daemon và cổng trước khi thử lại

NetworkManager-l2tp khởi động phiên bản xl2tpd của riêng nó. Nếu dịch vụ hệ thống đã chiếm UDP 1701, máy khách lùi về một cổng nguồn tạm thời, điều mà RFC 3193 cho phép và một số máy chủ lặng lẽ bỏ qua. Hãy kiểm tra chủ sở hữu ổ cắm trước lần thử tiếp theo.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Các bí mật được tạo cũ là một nguyên nhân âm thầm khác. Các tệp trong /etc/ipsec.d/ được đặt tên theo một kết nối cũ có thể sống lâu hơn hồ sơ đã tạo ra chúng, vì vậy hãy xóa những tệp không được tham chiếu và thử lại.

Cuối cùng, hãy kiểm tra lời khuyên đến từ đâu. Một ipsec.conf được viết cho IKEv1 XAuth mô tả một loại VPN khác, và đề xuất của nó không phải là dòng duy nhất sẽ sai trong hồ sơ L2TP. Ghi lại tập chuyển đổi bạn đã nhập bên cạnh hồ sơ, để người tiếp theo không lặp lại việc dò.