Khi IKEv2 trả về TS_UNACCEPTABLE, hãy so sánh các mạng con thật

Hãy đọc TS_UNACCEPTABLE như một bất đồng về phạm vi bao phủ, không phải một hồ sơ bị hỏng. Cổng cho biết hai bên không thống nhất được những địa chỉ nào mà đường hầm này được phép mang. IKE SA có thể đã được dựng lên ngay lúc đó, vì vậy một máy khách có thể trông như đã kết nối mà không có SA con nào phía sau. Khi đặt vấn đề như vậy, công việc trở nên máy móc. Ghi ra các tiền tố dự định của cả hai bên, so sánh chúng theo một hướng và thu hẹp cho đến khi chúng giao nhau.

Trước tiên hãy ghi các cặp dự định

Trước khi chạm vào cấu hình, hãy liệt kê bốn giá trị: dải nguồn của bên khởi tạo, dải đích của nó và cùng cặp đó nhìn từ phía bên trả lời. Cũng ghi lại họ địa chỉ của từng giá trị. Dải IPv4 và dải IPv6 là hai loại bộ chọn khác nhau, và không loại nào có thể gấp vào phần tải của loại kia.

Thêm mọi hạn chế về giao thức hoặc cổng mà chính sách mang theo. Một quy tắc chỉ cho phép TCP 445 tới một máy chủ tệp mô tả một tập hẹp hơn so với mạng con mà nó nằm trong. Nếu bỏ điều đó ra khỏi ghi chú, kết quả đàm phán sẽ trông không nhất quán vì những lý do bạn không thấy.

Đảo nhãn trước khi so sánh

Cục bộ và từ xa là những nhãn tương đối. Tiền tố cục bộ của máy khách là dải từ xa của cổng, và dải cục bộ của cổng là dải từ xa của máy khách. Vì thế ảnh chụp màn hình từ hai đầu không bao giờ khớp nhau, và so sánh chúng theo nghĩa đen là cách thường gặp để mất một buổi chiều.

Bên trả lời có thể thu hẹp một đề nghị thành một tập con chấp nhận được thay vì từ chối nó. Kết quả đó tệ hơn một thất bại sạch sẽ, vì nó chỉ hoạt động một nửa. Hãy yêu cầu 10.0.0.0/16 khi chính sách cho phép 10.0.5.0/24, và bạn có thể kết thúc với một SA con chỉ bao phủ đúng /24 đó. Chỉ một máy chủ trả lời, mọi thứ khác nằm ngoài, và không gì trong máy khách nói ra điều đó. Hãy đọc các bộ chọn được chấp nhận chứ không phải các bộ chọn được yêu cầu trước khi kết luận rằng đàm phán thành công.

Các hồ sơ road warrior yêu cầu tuyến mặc định đáp xuống đây liên tục. Một cổng được xây cho truy cập chia tách sẽ thu hẹp đề nghị toàn dải về các mạng con của chính nó, và máy khách phải chấp nhận kết quả đã thu hẹp hoặc thất bại ồn ào.

Đọc lời từ chối từ một lần thử

Thu thập cả hai nhật ký từ cùng một lần thử kết nối. Hồ sơ đã lưu cho thấy bạn đã cấu hình gì, không phải điều đã được đề nghị, và trên strongSwan swanctl --log in ra thông báo nhận được cùng các bộ chọn mà nó mang theo.

Sau đó kiểm tra xem thực tế đã cài đặt gì. swanctl --list-sas hiển thị các bộ chọn của SA con, và ip xfrm policy hiển thị cùng các dải đó dưới dạng mục chính sách của nhân. Một SA con trong danh sách đó với các bộ chọn bạn không định là một sự kiện thu hẹp; không có SA con cùng TS_UNACCEPTABLE trong nhật ký là một lời từ chối.

Trong lúc ở đó, hãy tách các láng giềng gần. INVALID_SELECTORS phàn nàn về một bộ chọn bên trong một SA con đã thiết lập, trong khi INTERNAL_ADDRESS_FAILURE nghĩa là bên trả lời không cấp được địa chỉ ảo, đó là vấn đề bể địa chỉ chứ không phải phạm vi bao phủ.

Kiểm tra điều gì âm thầm thu nhỏ tập hợp

Ba thứ thu nhỏ một tập bộ chọn mà không nói gì. Chính sách của bên trả lời là thứ nhất, thông qua danh sách mạng con, quy tắc nhóm hoặc ủy quyền theo người dùng làm giảm đề nghị thành một tập con. Họ địa chỉ là thứ hai: một máy khách hai ngăn xếp thường đề nghị IPv6 bên cạnh IPv4 và nhận lời từ chối cho những dải mà cổng chưa bao giờ cấu hình.

Các hạn chế về giao thức và cổng là thứ ba. Ở nơi chính sách chỉ cho phép TCP 445, một SA con có thể dựng lên trong khi ICMP và UDP vẫn ở ngoài, và người dùng báo đường hầm hỏng trong khi chỉ một giao thức là tất cả những gì từng được cho phép.

Do đó chỉ mở rộng địa chỉ không thể sửa một chính sách bị giới hạn theo cổng, và đây chính là trường hợp có nhiều khả năng sống sót qua ba vòng xử lý sự cố mà không thay đổi nhất.

Chứng minh phạm vi bao phủ bằng lưu lượng phù hợp

Sau khi SA con được cài đặt, hãy gửi một yêu cầu chắc chắn rơi vào bên trong các dải được chấp nhận. Hãy nhìn các bộ đếm thay vì biểu tượng trạng thái: ip -s xfrm state và các bộ đếm phía sau ip xfrm policy tăng lên khi một gói được khớp và bảo vệ. Số byte vẫn bằng không sau lưu lượng thật nghĩa là nhân chưa bao giờ chọn chính sách đó.

Số không đó là vấn đề định tuyến hoặc thứ tự chính sách, không phải vấn đề mật mã. Nó cũng trông giống hệt một lời từ chối bộ chọn từ chỗ ngồi của người dùng, vì thế đáng thu thập các bộ đếm trước khi mở lại hồ sơ. Các bộ đếm chỉ tăng theo một hướng lại chỉ vào đường quay về.

Kết thúc bằng việc ghi cặp được chấp nhận vào phiếu, bên cạnh dải đã được yêu cầu ban đầu. Giữ lựa chọn hẹp như yêu cầu, vì xóa lỗi bằng cách thay một dải riêng bằng mọi địa chỉ sẽ cấp nhiều quyền truy cập hơn mức đã được phê duyệt cho tài khoản.