ISP chặn UDP hay ứng dụng bên trong đường hầm?

Ai đó báo cáo rằng VPN „chặn UDP“, và câu này che giấu hai khẳng định hoàn toàn khác nhau. Một là về vận chuyển mà mạng truy cập có thể nhìn thấy, hai là về các gói của ứng dụng sau khi được giải mã bên trong đường hầm. Một đường hầm mã hóa có thể bị lọc từ bên ngoài mà không cần bất kỳ khóa nào, và một ứng dụng UDP bên trong có thể thất bại vì những lý do không liên quan gì đến lọc. Hãy quyết định bạn đang kiểm tra khẳng định nào trước khi thu thập bằng chứng.

Hai tiêu đề, một từ

Trong một triển khai IPsec có NAT-traversal, gói bên ngoài là UDP được đánh địa chỉ giữa hai điểm cuối VPN, thường ở cổng 4500. Bên trong đó, tải trọng đã mã hóa mang mọi thứ mà đường hầm chuyển tiếp, và bản thân nó có thể là TCP hoặc UDP. Vì vậy từ UDP xuất hiện hai lần, với ý nghĩa và khả năng hiển thị khác nhau.

Một mạng trung gian nhìn thấy tiêu đề bên ngoài và không thấy gì của tiêu đề bên trong. Nó có thể cho phép, định hình hoặc bỏ luồng bên ngoài, và không cần giải mã bất cứ thứ gì để làm điều đó. Chính sự bất đối xứng này là toàn bộ lý do khiến hai khẳng định bị nhầm lẫn: cùng một từ mô tả thứ mà mạng lọc và thứ mà ứng dụng gửi. Hãy ghi lớp bên cạnh từ mỗi khi ghi nhận một phát hiện, và sự nhầm lẫn phần lớn biến mất.

Tiêu đề bên trong chỉ trở nên nhìn thấy được tại điểm cuối nhận, sau khi giải mã. Từ điểm đó, gói được chuyển tiếp như bất kỳ gói nào khác, tùy thuộc vào tuyến đường, chính sách và việc lọc của chính điểm cuối. Đó là những quyết định riêng biệt do các thiết bị khác nhau đưa ra.

Mạng vẫn có thể thấy gì

Mã hóa che giấu tải trọng và tiêu đề vận chuyển bên trong, không che giấu việc một luồng tồn tại. Địa chỉ điểm cuối, cổng, kích thước gói và thời gian vẫn hiển thị, và thế là đủ để phân loại lưu lượng theo phương pháp suy đoán hoặc chặn một đích cụ thể.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

Bản ghi đầu tiên cho thấy luồng bên ngoài trên giao diện vật lý, và bản thứ hai cho thấy luồng bên trong trên giao diện đường hầm. Chạy cả hai cùng lúc trả lời câu hỏi một cách trực tiếp: nếu luồng bên ngoài tồn tại mà luồng bên trong không có, thì ứng dụng chưa từng gửi gì vào đường hầm. Nếu cả hai cùng tồn tại mà không có gì quay lại, vấn đề nằm ngoài đường hầm, ở đích hoặc trên đường trở về.

RFC 3948 định nghĩa việc đóng gói UDP bên ngoài, và đặc tả ESP định nghĩa bố cục được bảo vệ bên trong đó. Không tài liệu nào trong hai tài liệu hứa rằng một mạng truy cập sẽ cho luồng bên ngoài đi qua, vì vậy đáng để chạy một phép thử khả năng tiếp cận trên bộ bốn bên ngoài trước mọi giả thuyết về bộ bốn bên trong. Một bộ bốn bên ngoài bị chặn tạo ra một đường hầm không bao giờ hình thành, chứ không phải một đường hầm hình thành rồi mất một ứng dụng.

Tại sao một ứng dụng UDP thất bại bên trong một đường hầm đang hoạt động

Một đường hầm mang ứng dụng web nhưng không mang ứng dụng UDP có vài cách giải thích hợp lý, và việc ISP lọc giao thức bên trong không phải là cách đầu tiên. Phổ biến nhất là độ phủ: hai ứng dụng không cùng đi vào một đường hầm, vì thiếu tuyến đường đến đích UDP hoặc các quy tắc chia đường hầm của máy khách loại trừ nó.

Thứ hai là điểm cuối. Một máy chủ VPN cho phép danh sách giao thức, một tường lửa ở đích hoặc một dịch vụ không bao giờ lắng nghe trên cổng mong đợi, tất cả đều tạo ra thời gian chờ trông giống hệt một khối mạng.

Thứ ba là kích thước gói. Các ứng dụng UDP thường gửi datagram lớn hơn yêu cầu web, và việc đóng gói làm giảm MTU khả dụng, nên sau một bắt tay thành công có thể đến sự im lặng ở tải trọng đầy đủ kích thước đầu tiên. Mẫu này dễ bị đọc nhầm là chặn, vì các gói nhỏ đi qua còn gói lớn biến mất. Một phép thử MTU nhanh giải quyết việc này trong chưa đầy một phút, và câu trả lời thường là tải trọng nhỏ hơn hoặc MSS đã sửa, chứ không phải bộ lọc mạng.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

Lệnh đầu tiên kiểm tra xem một gói lớn có đi qua đường với phân mảnh bị tắt hay không, điều này nhanh chóng phơi bày vấn đề MTU. Lệnh thứ hai gửi một luồng UDP nhỏ, có giới hạn và báo cáo mất gói cùng jitter. Một luồng bắt đầu rồi dừng lại chỉ ra kích thước chứ không phải chặn.

Báo cáo lớp, không phải giao thức

Viết phát hiện theo một trong ba dạng: giao gói bên ngoài thất bại, chuyển tiếp bên trong thất bại, hoặc ứng dụng thất bại. Mỗi loại có người chịu trách nhiệm khác nhau, và trộn chúng sẽ gửi phiếu đến nhầm nhóm.

Đổi cổng cục bộ không thể tạo ra một trình lắng nghe khớp ở đầu xa, nên một giải pháp vòng tránh phía máy khách trông có vẻ giúp ích thường là bằng chứng rằng đích ban đầu đã sai. Tương tự, một hồ sơ thay thế được cung cấp chứng minh điều gì đó về khả năng tiếp cận và không chứng minh gì về việc ứng dụng có được cấu hình đúng hay không.

Hãy tách suy luận khỏi quan sát. Phân tích lưu lượng có thể gợi ý một luồng là gì mà không cần giải mã, và đó là một phát hiện hữu ích, nhưng nó không phải là cùng một khẳng định với việc đọc tiêu đề bên trong. Nêu rõ bạn thực sự có cái nào.