Tuyến mặc định của XFRM nuốt mất IKE và ESP: giữ đường ra bên ngoài

Lưu lượng được bảo vệ, đường hầm hoạt động, rồi nó chết ở lần làm mới khóa tiếp theo. Tuyến mặc định qua giao diện XFRM mô tả lưu lượng bạn muốn bảo vệ. Nó cũng nuốt luôn các gói cần thiết để tiếp tục bảo vệ.

Hai đích đến liên quan không thể thay thế cho nhau. Việc định tuyến phải nói rõ điều đó.

Truy vấn peer thực sự đi đâu

Ghi lại các quy tắc đang hoạt động, bảng chứa tuyến XFRM và địa chỉ công cộng của peer. Sau đó xem đường đi mà kết nối bên ngoài sẽ chọn với nguồn và dấu thực của nó. Một đích chung không cho bạn biết gì về đường điều khiển đó. Chỉ nguồn và dấu thực mới cho câu trả lời hữu ích.

Một kết nối đầu tiên thành công cũng chứng minh được ít. Lỗi thường xuất hiện sau khi việc cài đặt tuyến thay đổi câu trả lời. Khởi động thành công, rồi lần làm mới đầu tiên thì không.

ip rule show
ip route show table 220
ip -4 route get 198.51.100.44 from 10.40.0.2
ip xfrm policy list

Nếu truy vấn cho peer rơi vào giao diện XFRM, các gói bên ngoài đang được định tuyến vào đường hầm mà chúng tự dựng. Đó chính là vòng lặp, thấy được bằng một lệnh.

Các tùy chọn loại trừ trên một cổng hiện đại

Tài liệu của strongSwan về VPN dựa trên định tuyến đưa ra hai câu trả lời thực tế. Một cách đánh dấu IKE và ESP để quy tắc trỏ tới bảng XFRM không khớp với chúng. Cách kia để lại một tuyến peer hoặc loại trừ mà truy vấn vẫn có thể chạm tới.

Chọn cách mà bộ quy tắc của bạn có thể diễn đạt mà không có tác dụng phụ. Dấu là sạch khi phần còn lại của ngăn xếp đã dùng dấu. Nó là mối nguy khi cùng một mặt nạ mang nghĩa khác trong quy tắc khác. Cả hai loại gói đều cần cách xử lý này.

Chỉ đánh dấu IKE để các gói dữ liệu ở lại trên đường bị bắt. Điều đó tạo ra một đường hầm bắt tay xong rồi không mang gì.

Dấu là một bit trong fwmark của gói mà không thứ gì khác trên cổng đòi: 0x1 với mặt nạ 0x1 là lựa chọn thông thường, và phải đặt ở hai nơi để việc loại trừ hoạt động. Charon cần nó trên socket IKE, và các thiết lập dấu vào và ra của kết nối con cũng cần cùng giá trị để các gói được đóng gói cũng đi ra có dấu. Mặt nạ 0x1 thay vì 0xffffffff để các bit còn lại tự do, điều này quan trọng khi một hệ thống con khác đã đánh dấu gói trên cùng máy. Khi cả hai được đặt, quy tắc được viết như một loại trừ, nên các gói có dấu bỏ qua bảng chứa tuyến XFRM và rơi xuống bảng chính:

ip rule add not fwmark 0x1/0x1 lookup 220 pref 1000
ip -4 route get 198.51.100.44 from 10.40.0.2 mark 0x1

Sau đó đọc câu trả lời với dấu đã áp dụng. Không có nó, bạn đang xem đường đi của lưu lượng được bảo vệ, tức là ngược với câu hỏi của phần này.

Việc cài đặt tự động giả định gì về bản dựng

Cài đặt tuyến tự động cho giao diện XFRM phụ thuộc vào phiên bản strongSwan và cấu hình của nó. ID giao diện, chính sách đã cài và liên kết đều phải tham chiếu tới các đối tượng dự định. Sự không khớp hiện ra như một tuyến lặng lẽ trỏ tới một nơi có thật.

Sao chép số bảng hoặc mặt nạ dấu từ cổng khác là cách các xung đột bắt đầu. Trước tiên hãy kiểm tra thứ gì đã dùng nó. Xung đột ảnh hưởng tới lưu lượng xa hơn nhiều so với đường hầm bạn muốn đổi, và triệu chứng hiếm khi chỉ vào bản sao.

Thay đổi địa chỉ peer là một phần của thiết kế. Tuyến host cho địa chỉ hôm qua không phải kế hoạch khôi phục điểm cuối, trong khi dấu vẫn sống sót qua thay đổi đó.

Theo dõi lần làm mới đầu tiên

Kiểm tra đường ra bên ngoài sau khi các tuyến được bảo vệ đã cài, không phải trước đó. Sau đó theo dõi lần làm mới tiếp theo và một lần trao đổi ứng dụng. Lỗi thường xuất hiện ở bước chuyển đó chứ không phải lúc khởi động.

ip -4 route get 198.51.100.44
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or esp'

Tạm thời bỏ tuyến mặc định được bảo vệ thường khôi phục kết nối. Kết quả đó mang tính chẩn đoán, không phải cuối cùng.

Mục tiêu là sự tách biệt ổn định giữa lưu lượng bên trong và các gói bên ngoài mang nó. Ghi cơ chế đã chọn và bảng hoặc dấu của nó vào ghi chú của cổng. Nếu không, người tiếp theo chạm vào quy tắc sẽ đưa vòng lặp trở lại.