IKEv2 dùng UDP 500 và 4500: cổng nào chở dữ liệu?

Mở UDP 500 trên tường lửa cho phép đường hầm thương lượng, rồi kết nối ngừng chuyển lưu lượng. Danh sách cổng bị thiếu chứ không sai. IKEv2 bắt đầu trên một socket và trong nhiều triển khai thực tế tiếp tục trên socket khác, trong khi phần tải có thể không phải là cổng nào cả. Đọc các giai đoạn theo thứ tự sẽ giải thích quy tắc nào đang thiếu.

Hai cổng, hai nhiệm vụ

IKEv2 bắt đầu bằng trao đổi khóa trên UDP 500, nơi hai bên xác thực nhau và lập một kết hợp bảo mật cho đường hầm. Đường dữ liệu tiếp theo là chuyện riêng: có thể là ESP gốc, tức số giao thức IP chứ không phải cổng, hoặc lưu lượng được đóng gói trong UDP trên 4500. Tách hai thứ này trong một lần rà soát tường lửa là khác biệt giữa đường hầm thương lượng được và đường hầm thực sự chạy. Một socket chở điều khiển, socket kia chở phần tải.

Vì vậy một quy tắc chỉ cho phép 500 tạo ra triệu chứng khó hiểu nhất trong cả họ giao thức: thương lượng thành công và không có gì hữu ích tiếp theo. Trạng thái hiển thị một peer, nhật ký hiển thị IKE SA đã thiết lập, và ứng dụng vẫn hết thời gian chờ. Quyền còn thiếu thuộc về một luồng khác với luồng vừa thành công.

Vì sao có 4500

Nhiều thiết bị NAT không chuyển tiếp được giao thức nào khác ngoài TCP hoặc UDP, và một số viết lại địa chỉ theo cách phá vỡ kiểm tra toàn vẹn của ESP. Đóng gói ESP trong UDP giải quyết cả hai vấn đề, với cái giá là thêm một tiêu đề và một cổng thứ hai phải được cho phép. Chính việc đóng gói đó là lý do cổng thứ hai tồn tại.

Khi phát hiện NAT, bản thân IKE cũng chuyển sang 4500 để mọi lưu lượng dùng chung một đường qua bộ dịch. Một dấu bốn byte không phải ESP phân biệt thông điệp điều khiển với dữ liệu trên socket đó. Việc chuyển đổi là quyết định của giao thức, không phải sở thích của quản trị viên.

Cổng nguồn thay đổi ở đâu

Bộ dịch có thể viết lại cổng nguồn của máy khách, nên bộ ba nhìn thấy ở máy chủ không khớp với bộ ba ở máy khách. Hãy xem cả hai phía của mỗi bước nhảy NAT trước khi kết luận rằng một quy tắc bị bỏ qua. Chỉ khắc phục sự cố ở máy khách có thể tạo ra quy tắc trông đúng mà vẫn thất bại.

Các triển khai hỗ trợ MOBIKE cũng có thể chuyển sang 4500 mà không phát hiện NAT, và một số triển khai cố ý ép buộc đường đó. Vì vậy thấy 4500 là bằng chứng của một quyết định, không phải bằng chứng của router gia đình.

Kiểm tra cả hai luồng ở mọi ranh giới

Đi qua ba ranh giới: mạng máy khách, bất kỳ tường lửa trung gian nào và máy chủ. Mỗi nơi cần những luồng mà triển khai ghi nhận, không phải luồng từ một bài viết về trường hợp khác.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

Dòng ESP trong danh sách tường lửa là một khớp giao thức, nên quy tắc cổng không bao giờ bao phủ nó. Nếu người vận hành dùng cổng tùy chỉnh, hãy theo cấu hình đã ghi nhận ở cả hai đầu, vì máy khách không thể tạo trình lắng nghe trên máy chủ bằng cách chọn một số quen thuộc.

Ghi lại nơi thương lượng dừng và liệu một kết hợp bảo mật con đã được cài đặt, vì cặp đó tách đường bị chặn khỏi lỗi xác thực hoặc chính sách. Sau đó lặp lại bài kiểm tra với xác minh máy chủ được bật, vì khả năng tiếp cận không phải xác thực. Bước cuối đó tách một cổng được phép khỏi một peer đáng tin cậy.