L2TP NO_PROPOSAL_CHOSEN: giai đoạn nào thực sự thất bại?
Thông báo chỉ nói rằng một đề xuất bị từ chối, chứ không nói đề xuất nào. Hãy đọc nhật ký của backend để xác định giai đoạn, rồi so sánh các bộ với người vận hành cổng.
NO_PROPOSAL_CHOSEN đến trước khi bất kỳ tên người dùng PPP nào được kiểm tra, đây là một dữ kiện hữu ích và cũng là lý do thông báo gây hiểu nhầm. Nó báo rằng một bên đã từ chối một đề xuất; nó không báo tham số nào không khớp, và không nói gì về việc việc từ chối xảy ra khi dựng liên kết IKE hay muộn hơn trong lúc đàm phán về bảo vệ lưu lượng. Đằng sau hai khả năng đó là hai cách sửa khác nhau, và chỉ một trong số đó liên quan đến hộp kiểm PFS mà người ta tìm đến trước tiên.
Một thông báo, hai tập đề xuất
Cách bố trí IKEv1 L2TP/IPsec có hai vòng đàm phán nối tiếp. Giai đoạn 1 dựng liên kết bảo mật IKE từ một thuật toán mã hóa, một thuật toán toàn vẹn và một nhóm Diffie-Hellman. Giai đoạn 2 sau đó đàm phán cách bảo vệ lưu lượng, và yêu cầu PFS thuộc về cuộc trò chuyện thứ hai đó.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Vì các giai đoạn nối tiếp nhau, vị trí thất bại cho bạn biết nên so sánh danh sách nào. Toàn bộ giá trị chẩn đoán của thông báo nằm ở đó, và đáng để rút ra trước khi chạm vào bất kỳ cài đặt nào.
Vì sao hộp kiểm PFS không thể sửa giai đoạn 1
Tắt PFS thay đổi một thuộc tính của giai đoạn 2. Nếu hai bên chưa bao giờ thống nhất về giai đoạn 1, cuộc trò chuyện ESP không bao giờ diễn ra, nên hộp kiểm hoàn toàn không có tác dụng với việc từ chối, và đó là lý do việc bật tắt nó tạo ra cùng lỗi với dấu thời gian khác.
Lỗi ngược lại cũng phổ biến không kém. Một liên kết IKE thành công không chứng minh đề xuất ESP khả dụng, và chắc chắn không chứng minh nhóm của giai đoạn 2 khớp nhau. Hãy coi đường hầm quản trị đã thiết lập chỉ là bằng chứng về giai đoạn 1. Người ta đọc dòng xanh là «đường hầm đã lên», rồi mất một giờ ở sai giai đoạn vì không gì cho họ biết vòng đàm phán thứ hai chưa bắt đầu.
Đọc nhật ký trước khi chọn thuật toán
Thu thập các thông báo ngay trước lần từ chối từ backend thực sự xử lý kết nối, và tương quan chúng với cùng lần thử đó. Không có tương quan ấy, bạn đang đọc lịch sử của một kết nối khác và rút ra kết luận từ nó.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanTừ những dòng đó, trả lời hai câu hỏi: liên kết giai đoạn 1 có được thiết lập không, và trao đổi nào đã thất bại. Hai câu trả lời ấy thu hẹp việc tìm kiếm vào một danh sách thuộc tính. Một thông báo trần trụi không có ngữ cảnh xung quanh không làm được điều đó, dù việc thử một đề xuất từ một chủ đề diễn đàn có hấp dẫn đến đâu. Sao chép một chuỗi đang chạy từ máy có backend khác thường thay thế một lần từ chối bằng một lần khác, muộn hơn một chút.
Cú pháp của backend không đi theo
Ghi lại phiên bản NetworkManager-l2tp và phiên bản backend IPsec trước khi so sánh bất cứ điều gì. Libreswan và strongSwan không chia sẻ cú pháp đề xuất hay các bộ thuật toán giống hệt nhau, nên một chuỗi chạy được ở bên này là lỗi cú pháp ở bên kia. Backend đã cài đặt cũng có thể từ chối IKEv1 theo chính sách, và khi đó sẽ không đề xuất nào được chấp nhận.
README của dự án ghi lại những khác biệt backend đó và giữ riêng các trường của giai đoạn 1 và giai đoạn 2. Hãy đọc nó như tài liệu về cấu trúc, không phải lời mời bật mọi mật mã lịch sử và một nhóm yếu, vì một kết nối chỉ thành công nhờ cách đó không phải là kết nối bạn được yêu cầu dựng.
Thống nhất bộ, rồi kiểm chứng các bước
Hỏi người vận hành cổng xem những bộ IKE và ESP nào được hỗ trợ và phê duyệt, rồi so sánh câu trả lời đó với các đề xuất thực tế của máy khách thay vì với tệp cấu hình của nó. Nếu bất đồng cụ thể về PFS của giai đoạn 2, hãy chốt một nhóm được hỗ trợ hoặc một chính sách không PFS đã được phê duyệt rõ ràng. Đừng suy ra chính sách từ tên lỗi.
Khi phần giao duy nhất đòi hỏi mật mã mà tổ chức không còn chấp nhận, quyết định thuộc về cổng hoặc một cuộc chuyển đổi giao thức. Nới rộng chuỗi của máy khách cho đến khi có thứ gì đó đàm phán được là cách bàn giao một điểm yếu đã biết kèm theo dấu kiểm xanh bên cạnh.
Sau khi sửa đúng chỗ không khớp, hãy xác nhận việc thiết lập IPsec trước khi điều tra L2TP và PPP, và coi mọi lần từ chối xác thực về sau là thuộc bước kế tiếp. Sau đó thử gia hạn trong quy trình kiểm thử đã được phê duyệt, vì việc thiết lập liên kết đầu tiên không nói gì về phần còn lại của vòng đời nó.