strongSwan ESP-in-UDP: khi không có NAT để phát hiện

Phát hiện NAT tìm ra việc dịch địa chỉ, không phải chính sách tường lửa. Kết nối site không có NAT vẫn có thể cần một lựa chọn ESP-in-UDP rõ ràng.

Phát hiện NAT trả lời một câu hỏi: địa chỉ hoặc cổng có thay đổi trên đường đi không? Nó không trả lời liệu tường lửa có cho phép giao thức IP 50 hay không. Các cổng site không có bất kỳ phép dịch nào vẫn có thể nằm sau một chính sách loại bỏ native ESP, và yêu cầu đó phải được cấu hình thay vì được phát hiện. Cơ chế là ESP-in-UDP, và đó là một quyết định, không phải phương án dự phòng tự xuất hiện.

Phát hiện là số học trên địa chỉ, không phải thăm dò tường lửa

IKEv2 mang các payload phát hiện NAT chứa hàm băm của địa chỉ và cổng nguồn, đích. Mỗi bên so sánh thứ nhận được với thứ thấy cục bộ, và sự không khớp cho biết có thứ gì đó đã dịch gói tin. Không có gì trong trao đổi đó kiểm tra liệu bộ định tuyến ở giữa có chuyển tiếp giao thức 50 hay không.

Hệ quả thực tiễn đáng được nói thẳng. Một tunnel từng hoạt động với native ESP sẽ không tự phát hiện tường lửa hạn chế mới, và lần thử tiếp theo của nó thất bại ở giai đoạn dữ liệu trong khi IKE vẫn thành công. Bạn sẽ thấy các liên kết bảo mật IKE đã thiết lập và không có lưu lượng được bảo vệ, điều trông giống lỗi định tuyến cho đến khi bạn bắt gói trên dây.

Vì vậy đóng gói là thuộc tính của kết nối bạn cấu hình, không phải kết quả mà các bên thương lượng từ hành vi của mạng.

encap thay đổi trao đổi như thế nào

Trong một triển khai strongSwan hiện đại được quản lý qua swanctl.conf, thiết lập encap = yes trên kết nối ảnh hưởng đến trao đổi phát hiện NAT để cả hai bên dùng đóng gói UDP cho ESP. Các gói được bảo vệ sau đó đi trong UDP, thường trên cổng 4500, và cả hai đầu phải đồng ý với cách sắp xếp đó.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Đoạn đó thuộc vào bên trong một định nghĩa kết nối thật và không phải hồ sơ site đầy đủ. Giữ nguyên địa chỉ peer, xác thực và bộ chọn lưu lượng child mà bạn đang chạy; khóa duy nhất được thêm vào thay đổi cách dữ liệu được bảo vệ được gói lại, không phải thứ nó bảo vệ.

Hướng dẫn NAT-traversal của strongSwan mô tả hành vi này, bao gồm tương tác với việc cổng trôi nổi khi dùng MOBIKE.

Dùng thiết lập thuộc về backend của bạn

strongSwan có hai backend cấu hình, và khóa khác nhau giữa chúng. Một swanctl.conf kết nối nhận encap, trong khi ipsec.conf kết nối cũ nhận forceencaps. Đặt từ khóa của backend này vào backend kia tạo ra cấu hình tải được mà không phàn nàn và không thay đổi gì, điều này tệ hơn một lỗi.

Kiểm tra daemon nào thực sự đang chạy trước khi sửa bất cứ thứ gì. Trên nhiều bản phân phối, cả hai tệp đều tồn tại vì một tệp là tàn dư của lần di trú trước, và tệp đang hoạt động là tệp mà unit dịch vụ khởi động. Hãy đọc unit đó thay vì đoán từ dấu thời gian của tệp. Một kiểm tra năm giây ở đây tránh được hàng giờ thử một thiết lập mà không gì tải nó.

Áp dụng thay đổi qua chủ sở hữu kết nối và thiết lập lại liên kết trong một cửa sổ được kiểm soát. Một child đã cài đặt giữ cách đóng gói hiện tại cho đến khi bị thay thế, nên chỉ sửa tệp không chứng minh cách sắp xếp mới đang được dùng.

Kiểm tra dữ liệu đã đóng gói, không chỉ cổng

Bắt gói trên gateway khi lưu lượng được bảo vệ đang chảy, rồi so sánh với góc nhìn của chính strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP xuất hiện như giao thức IP 50 và không giống UDP chút nào. ESP đóng gói xuất hiện như datagram UDP trên 4500 mà payload không phải IKE. Lưu lượng IKE trên cùng cổng đó không phải bằng chứng đóng gói, vì MOBIKE có thể chuyển IKE đến đó trong khi đường dữ liệu vẫn là native, nên hãy đọc payload, không phải số cổng.

Cũng cần nhớ MTU của đường đi. Phần bao thêm chi phí, và một đường từng mang native ESP có thể cần điều chỉnh khi gói lớn dần. Việc xử lý ICMP cần thiết nên là một phần của thiết kế; đóng gói không loại bỏ sự phụ thuộc đó.

Chấp nhận thay đổi khi lưu lượng ứng dụng mới bên trong tunnel hiện trong bản bắt gói dưới dạng ESP đóng gói ở cả hai đầu, và khi dịch vụ bên trong cùng tuyến trở về của nó vẫn hoạt động. Bất cứ điều gì ít hơn là một cấu hình trông đúng trong tệp.

Bài viết liên quan