Vì sao L2TP/IPsec cần UDP 1701 bên cạnh IPsec

Các tường lửa cho phép IKE và ESP nhưng không cho phép UDP 1701 phá vỡ kết nối L2TP theo cách trông giống sự cố thông tin đăng nhập. Lý do là L2TP là giao thức thứ hai đi bên trong giao thức thứ nhất. IPsec mang và xác thực trao đổi, còn L2TP chạy đường hầm riêng của nó trên UDP 1701, mà ngăn xếp cục bộ vẫn phải chuyển tiếp. Biết mỗi tiêu đề xuất hiện ở đâu giúp giải thích thiết bị nào cần quy tắc nào.

Hai giao thức, hai bộ cổng

Một kết nối L2TP/IPsec dùng IKE trên UDP 500, xuyên NAT trên UDP 4500 ở nơi có chuyển đổi địa chỉ, và ESP như giao thức IP 50 ở nơi không có. Bản thân L2TP là giao thức đường hầm trên UDP 1701, và nó chạy sau khi IPsec đã xác thực đối tác. Hai nửa hỏng theo cách khác nhau, và các dòng nhật ký báo cáo về chúng đến từ các thành phần khác nhau. Một bộ quy tắc chỉ bao phủ nửa đầu sẽ tạo ra kết nối thương lượng được rồi chết ở giai đoạn đường hầm.

Số hiệu cổng mô tả các điểm cuối truyền tải, còn ESP hoàn toàn không phải cổng. Vì thế một giao diện tường lửa chỉ cung cấp quy tắc TCP và UDP không thể diễn đạt chính sách IPsec đầy đủ. Giao thức 50 phải được cho phép như một giao thức, và một quy tắc chỉ nhắc đến UDP sẽ không bao giờ khớp với nó.

Lớp bọc giải thích cổng

Trên đường truyền, một kết nối L2TP/IPsec thường hiển thị IKE trên 500 và ESP đã bọc trên 4500. Tiêu đề UDP 1701 nằm bên trong phần tải được bảo vệ, vì thế bắt gói trên giao diện ngoài không thấy nó. Máy chủ cục bộ vẫn phải chuyển datagram đó đến tiến trình nền L2TP, và việc chuyển diễn ra sau khi giải đóng gói. Do đó quy tắc 1701 thuộc về tường lửa của chính điểm cuối, ngay cả khi không thiết bị trung gian nào từng thấy cổng đó.

Thứ tự xử lý giải thích phần lớn sự nhầm lẫn. Nếu ngăn xếp áp dụng chính sách IPsec trước bộ lọc máy chủ, gói L2TP đã giải đóng gói được so khớp là UDP 1701; nếu thứ tự đảo ngược, cổng ngoài là thứ mà bộ quy tắc nhìn thấy. Cả hai hành vi đều tồn tại trong thực tế, vì thế cùng một bộ quy tắc có vẻ chạy được trên nền tảng này và hỏng trên nền tảng khác.

Kiểm tra đường đi theo thứ tự

Trước hết bắt gói trên giao diện ngoài và xác nhận IKE cùng ESP đã bọc di chuyển theo cả hai chiều. Sau đó kiểm tra bộ đếm tường lửa cục bộ cho lưu lượng đã giải đóng gói. Thứ tự quan trọng, vì một lần bắt gói không hiển thị gì nghĩa là sự cố nằm phía trên máy chủ.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

Lần bắt gói xác nhận nửa đầu của trao đổi và cho thấy đối tác có trả lời hay không. Danh sách quy tắc cho thấy có quy tắc 1701 hay không và nó nằm ở đâu so với bất kỳ chính sách loại bỏ nào. Danh sách socket xác nhận tiến trình nền L2TP đã bám và đang lắng nghe, điều này loại trừ một dịch vụ chưa từng khởi động. Hãy đọc cả ba trước khi đổi một quy tắc, vì thiếu trình lắng nghe và cổng bị lọc tạo ra cùng một phàn nàn từ người dùng.

Những gì quét cổng không thể hiển thị

Một lần quét UDP 1701 từ bên ngoài nhắm vào máy chủ được cấu hình đúng thường không báo gì, và đó là kết quả mong đợi. Cổng này không lộ ra internet; chỉ đến được nó sau khi IPsec đã xác thực đối tác. Coi kết quả đóng là lỗi sẽ dẫn đến mở một cổng lẽ ra phải đóng. Việc quét không thể nhìn vào bên trong đường hầm hơn mức nó có thể nhìn thấy lưu lượng ứng dụng.

Thay vào đó hãy thử bằng một máy khách thực và đọc xem nó đến giai đoạn nào. Nếu kết nối thương lượng rồi khựng lại, nghi phạm là tiến trình nền L2TP hoặc bộ lọc cục bộ; nếu nó không bao giờ thương lượng, thì các cổng ngoài là thủ phạm. Cách tách đôi duy nhất đó loại bỏ phần lớn phỏng đoán về việc thêm quy tắc nào, và việc phân lớp giao thức khiến điều này có thể dự đoán được thay vì huyền bí.