Vì sao một tuyến OpenVPN thua chính sách XFRM của strongSwan
Một tuyến OpenVPN cụ thể không ghi đè chính sách XFRM: hãy đọc tuyến và các bộ chọn của chính sách, rồi thu hẹp, tạo ngoại lệ hoặc chuyển sang giao diện XFRM.
Các gói tin có thể đi theo một tuyến OpenVPN mà vẫn bị chính sách IPsec bắt giữ, và sự kết hợp đó trông như lỗi định tuyến từ mọi góc nhìn trừ góc đúng. Linux phân giải một tuyến rồi mới tra cứu một cơ sở dữ liệu chính sách bảo mật riêng, nên một tuyến đích cụ thể hơn không đẩy lùi chính sách XFRM khớp. Triệu chứng thấy được là lưu lượng rời máy chủ và không bao giờ đến, trong khi cả hai đường hầm đều tự báo khỏe. Ba lựa chọn giải quyết việc này, và lựa chọn nào tùy thuộc vào việc tuyến nào trong hai đường dẫn phải mang tiền tố đó.
Hai quyết định, không phải một
Việc chọn tuyến trả lời một câu hỏi hẹp: bước nhảy tiếp theo và địa chỉ nguồn nào phải mang gói tin này. Cơ sở dữ liệu chính sách bảo mật trả lời câu hỏi khác: gói tin này có cần bảo vệ IPsec không, và dưới những bộ chọn nào. Cả hai chạy cho cùng một gói tin, và thỏa mãn cái thứ nhất không nói gì về cái thứ hai. Vì vậy đổi một metric hay thêm một tuyến tĩnh có thể để triệu chứng nguyên vẹn.
Một bộ chọn IPsec rộng là nguyên nhân thường gặp. Chính sách bảo vệ 172.16.0.0/12 cũng bao phủ 172.20.8.0/24, nơi quản trị viên có thể định đến qua đường hầm OpenVPN thay vào đó. Ý định chỉ tồn tại trong bảng định tuyến, và cơ sở dữ liệu chính sách chưa bao giờ biết về nó.
Hãy coi đó là xung đột giữa hai đường bảo vệ đã cấu hình chứ không phải cuộc thi giữa hai metric. Bản sửa thuộc về thành phần được cấu hình với phạm vi sai.
Đọc tuyến mà kernel thực sự chọn
Bắt đầu bằng tra cứu mà kernel thực hiện, gồm địa chỉ nguồn và bất kỳ quy tắc chính sách nào có thể chuyển nó sang bảng khác. Một tuyến trong bảng chính có thể không bao giờ được xét nếu một quy tắc trước đó chọn bảng khác, và khớp tiền tố dài nhất chỉ áp dụng trong bảng mà quy tắc chọn.
ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15Lệnh cuối cùng là lệnh quan trọng, vì nó in tuyến đã chọn cùng địa chỉ nguồn mà kernel sẽ dùng. So sánh đầu ra đó với bộ chọn mà chính sách IPsec khớp. Khi tuyến trỏ tới giao diện OpenVPN và chính sách vẫn khớp cùng cặp, bạn đã tái tạo xung đột mà không phải đoán.
Giữ bản kết xuất không có địa chỉ không liên quan trước khi chúng tới phiếu hỗ trợ. Bảng định tuyến từ máy chủ sản xuất mang theo cấu trúc liên kết nội bộ, và chỉ những dòng trả lời câu hỏi mới đáng dán.
Cũng hãy đọc chính sách đang áp dụng
Danh sách chính sách cho thấy hướng, các bộ chọn và mẫu quyết định điều gì xảy ra với gói tin khớp. Đọc hướng đi ra trước, rồi phía đi vào cho lưu lượng trở về, vì một ngoại lệ một chiều tạo ra kết nối bắt đầu mà không bao giờ hoàn tất.
ip -s xfrm policy
swanctl --list-sasSo sánh các bộ chọn trong danh sách với các tiền tố mà kết nối đã thương lượng. Tắt cài đặt tuyến của strongSwan không xóa các chính sách đó, và đổi metric không thay đổi cặp nguồn và đích mà một chính sách bảo vệ. Hai bản sửa giả này nên bị loại sớm, vì đó là những thứ đầu tiên người ta thử.
Nếu danh sách không có chính sách cho tiền tố bạn mong đợi, vấn đề ở nơi khác và bảng định tuyến có lẽ đang nói thật. Nếu nó có chính sách rộng hơn bao phủ tiền tố, bạn đã tìm thấy việc bắt giữ.
Ba lựa chọn khi cả hai đường đều hợp lệ
Thu hẹp bộ chọn IPsec là lựa chọn sạch nhất khi tiền tố rộng là tiện lợi chứ không phải yêu cầu. Giảm bộ chọn lưu lượng từ xa xuống các mạng con thực sự thuộc về phía sau IPsec loại bỏ xung đột cho mọi máy chủ cùng lúc, và cái giá là thương lượng lại khóa chứ không phải thành phần mới.
Một ngoại lệ passthrough là lựa chọn phẫu thuật khi bộ chọn rộng phải giữ lại. strongSwan hỗ trợ một kết nối riêng mà child của nó dùng chế độ pass, điều này nói với kernel rằng lưu lượng khớp không được IPsec xử lý. Địa chỉ từ xa loopback giữ kết nối đó khỏi bị chọn cho các đối tác đi vào, và các bộ chọn phải mô tả cặp được phép thực sự chứ không phải mọi thứ.
connections {
openvpn-exception {
remote_addrs = 127.0.0.1
children {
openvpn-exception {
local_ts = 10.44.7.0/24
remote_ts = 172.20.8.0/24
mode = pass
start_action = trap
}
}
}
}Các ví dụ cấu hình strongSwan ghi lại kiểu chính sách này và quy ước đối tác loopback. Lựa chọn thứ ba là một thiết kế dựa trên định tuyến với giao diện XFRM, nối chính sách với lưu lượng được định tuyến qua một giao diện có tên thay vì với bộ chọn toàn cục. Đó là di trú chứ không phải tinh chỉnh, và lưu lượng vẫn phải thỏa mãn các bộ chọn đã thương lượng.
| Option | Use it when | Cost |
|---|---|---|
| Narrow the selector | The broad prefix was convenience | A rekey and a policy review |
| Passthrough child | The broad selector must stay | One exception per intended pair |
| XFRM interface | Policy should follow routing | A design migration |
Chứng minh ngoại lệ mà không làm yếu phần còn lại
Sau khi nạp thay đổi, hãy thử ngoại lệ và một đích thông thường phải tiếp tục được bảo vệ. Kiểm tra cả hai chiều, rồi hạ đường hầm OpenVPN và xác nhận điều gì xảy ra với lưu lượng được miễn trừ. Một ngoại lệ lặng lẽ gửi tiền tố đó công khai khi đường hầm xuống là quyết định chính sách bạn nên đưa ra có chủ đích, không phải phát hiện trong lúc sự cố.
Ghi lại tiền tố nào dùng đường nào và vì sao. Nếu không, kỹ sư tiếp theo nhìn thấy bộ chọn rộng sẽ mở lại đúng cuộc điều tra đó, và câu trả lời sẽ nằm trong một thông điệp commit không ai đọc.