Cảm ơn anh conmale.

Thiệt tình vẫn cảm thấy không ổn lắm vì các wwwect này sẽ phải tốn thêm 1 process (netcat chẳng hạn) để bỏ packet, như vậy thì packet vẫn đi từ card mạng đến user process, tức là pass qua toàn bộ các table và chain của iptable (?), trong khi với dòng drop thì packet được drop ngay từ lúc PREROUTING.

Mà thực tế (đã được chứng minh) nhiều khi lại khác với những gì mình nghĩ nên bữa nào quởn phải nghiên cứu thử vụ này. 

Sau khi thêm dòng:

iptables -t mangle -I PREROUTING -p udp -j REDIRECT --to-ports 9 

vào iptables, e gặp lỗi sau:

[7258252.635604] x_tables: ip_tables: REDIRECT target: only valid in nat table, not mangle 

Trong khi đó trong "man iptables", table mangle có chain PREROUTING:

mangle:
This table is used for specialized packet alteration. Until kernel 2.4.17 it had two built-in chains: PREROUTING (for altering incoming packets before routing) and OUTPUT (for altering locally-generated packets before routing). Since kernel 2.4.18, three other built-in chains are also supported: INPUT (for packets coming into the box itself), FORWARD (for altering packets being routed through the box), and POSTROUTING (for altering packets as they are about to go out) 

$iptables --version
iptables v1.4.10
$ uname -a
Linux ubuntu 2.6.38-8-generic-pae #42-Ubuntu SMP Mon Apr 11 05:17:09 UTC 2011 i686 i686 i386 GNU/Linux 

Em không hiểu sao lại bị lỗi trên, mong anh xem giúp. 

@conmale

Bữa nay mới thử setup để test thử việc send udp đến port 9 để xem coi nó có đi qua các chain hay không.

Hệ thống gồm:
- máy linux A 172.16.34.1 chạy debian sid
- máy windows B 172.16.34.222 chạy windows, có cài oscinato (traffic generator)

Rule iptables trên A:

# iptables -t nat -I PREROUTING -s 172.16.34.222 -p udp --dport 1999 -j REDIRECT --to-port 9
# iptables -A INPUT -s 172.16.34.222 -p udp --dport 9 -j ACCEPT

run netcat vào null

# netcat -l -u -p 9 > /dev/null &

Oscinato trên B:
port group là card mạng, create new stream với các thông số sau:

tab Protocol selection
frame length fixed (64), L1 = MAC, L2 = Ethernet II, L3 = IPv4, L4 = UDP, L5 = none, VLAN untagged

tab Protocol data:
Media Access Protocol -> đưa MAC của A vào phần source, và MAC của B vào phần dest
Ethernet II -> check vào ethernet type 08 00 (default - ip4)
UDP -> Override source port = 9999, Override dest port = 1999
Payload Data -> Fix word = 0 1 2 3

tab Stream control
Send = packet, Mode = Fixed, Number of packets = 100, After this stream = go to first (tức là sẽ loop ở đây), rate = 2 packet/s

Tổng kết cấu hình:
Máy B sẽ send 2 packet UDP/s từ port 9999 vào port 1999 của máy A, đồng thời ở Máy A có rule để match các UDP packet từ máy B gửi đến port UDP 1999 của máy A và wwwect từ port 1999 sang port 9 trong table nat của iptables. Đồng thời user process netcat listen trên udp port 9 và vứt bỏ packet.

Trong oscinato tiến hành gửi packet, mở console root bên máy A lên và type vào
# watch iptables -L -n -v

Ta sẽ thấy rule iptables của chúng ta nhập được match (số lượng packet tăng) ->nghĩa là rule wwwect ở table nat match và rule accept trong table filter được match. Kill netcat process thì rule trong table filter vẫn tăng match count.

Như vậy có thể kết luận là udp packet thực sự có traverse đến table filter cho đến khi match 1 rule, bất kể có service nào đăng ký listen hay không.

Theo suy nghĩ của tui là cũng hợp logic khi ở kernel, xử lý packet sẽ không quan tâm nhiều đến ý nghĩa quy ước của port number. Đằng nào thì kernel cũng xử lý xong packet mới handle sang user space process. Tuy nhiên cũng có thể có những optimization nào bên dưới để xử lý các trường hợp ngoại lệ như thực tế đã chứng minh.