Đây là cách tôi đo này, với netcat:
Mở máy chủ Unix của tôi (Mac OS X Darwin), không có tường lửa (hoặc trên một máy tính Windows nơi các bức tường lửa của Windows cho phép người netcat "nc" thực thi để lắng nghe trên các cổng UDP), tôi chạy một máy chủ UDP với sự chậm trễ biến được cung cấp bởi khách hàng từ xa:
WINHOST=10.116.140.69
mkfifo f
nc -u -p 2222 $WINHOST 6666 < f | \
(while read secs; do for sec in $secs; do echo sleep $sec 1>&2; sleep $sec; echo SLEPT $sec; echo SLEPT $sec 1>&2; done; done) > f
Mở máy chủ Windows của tôi (Windows 7 Professional SP1 64-bit), Windows Firewall, với Cygwin cài đặt để cung cấp vỏ và netcat, tôi chạy ứng dụng khách UDP tương tác:
UNIXHOST=192.168.181.1
nc -u -p 6666 $UNIXHOST 2222
Bạn không phải sử dụng Cygwin; một netcat Windows sẽ hoạt động tốt, nhưng các dòng lệnh có thể khác nhau.
Sau đó, vào khách hàng đó, tôi nhập một loạt các khoảng thời gian kiểm tra, quan sát máy chủ đang ngủ sau đó trả lời, quan sát xem khách hàng có nhận được phản hồi hay không. Những hoạt động: 1, 2, 10, 60, 120, 180. Sau đó, thất bại này: 240. Tiến hành một tìm kiếm nhị phân giữa 180 và 240.
Ví dụ 1: Về phía khách hàng, tôi gõ:
10
60
120
180
240
và quan sát sự chậm trễ yêu cầu phản hồi lên tới 180 tác phẩm, 240 không.
Ví dụ 2: Về phía khách hàng, tôi gõ:
180
181
182
182
và quan sát rằng sự chậm trễ yêu cầu đáp ứng lên đến 181 công trình, 182 thì không.
Ví dụ 3: Về phía khách hàng, tôi gõ (tất cả trên cùng một dòng):
180 180 180 181 181 181 182 182 182 183 183 183
mà tạo ra một yêu cầu UDP từ khách hàng, sau đó là một loạt các phản ứng phân cách bằng 180, 181, 182, hoặc 183 giây. Nó đã được quan sát thấy rằng yêu cầu-đáp ứng chậm trễ lên đến 181 làm việc, và ngoài ra, tiếp tục phản ứng (không có yêu cầu mới) trong khoảng thời gian lên đến 181 giây cũng làm việc.
Vì vậy, lỗ hổng tường lửa có bộ hẹn giờ không hoạt động, bất kể sự không hoạt động chậm trễ trong phản hồi ban đầu hay trong lưu lượng bổ sung tiếp theo.
Kết quả trên nhiều máy tính:
- On rằng Windows 7 SP1 Professional máy tính để bàn 64-bit, lỗ phản ứng UDP được mở cho 181 giây. Có thể tôi cũng đang đo một bức tường lửa mạng giữa hai hệ thống, vì chúng nằm trên các mạng riêng biệt - nhưng tôi nghĩ chúng được định tuyến không tường lửa. Trong mọi trường hợp, lỗ hổng tường lửa của Windows là ít nhất 181 giây trên hệ thống này.
- Máy tính xách tay Windows 7 Professional SP1 64 bit khác, cùng một phân đoạn mạng (do đó chắc chắn không có tường lửa can thiệp), lỗ phản hồi UDP mở trong 64 giây.
Tôi muốn thấy các phép đo tương tự trên các máy Windows khác ở các mức hệ điều hành và cấu hình tường lửa khác nhau.
"Không cần thiết phải gửi đến cổng UDP mà bạn muốn là người gửi" -depends của loại NAT. Điều này đúng với Cone NAT bị hạn chế nhưng không phải đối với Cone NAT bị hạn chế. –