请问在如何在NF_LOCAL_IN获得TCPv4包的目标（本机）端口？因为本机的TCP服务是监听并fork新的进程的，所以在netfilter里面拿到的只是监听端口而不是真正的端口。

如果不行，有什么办法获得呢？目标是尽量减少对内核的改动。谢谢！

>>因为本机的TCP服务是监听并fork新的进程的，所以在netfilter里面拿到的只是监听端口而不是真正的端口。

监听端口也是真正的端口

在LOCAL_IN这个hook点上，直接察看数据包的TCP端口，不就可以看到了么。

我的意思是说要拿到fork以后的端口， 因为我的程序要对不同的连接进行不同的地址修改。如果用监听端口，就没办法分辨了。另外HOOK里面拿到的TCP端口是监听端口而不是fork以后的端口，所以没用。

>>因为我的程序要对不同的连接进行不同的地址修改。

怎么改的？

>>另外HOOK里面拿到的TCP端口是监听端口而不是fork以后的端口，

fork以后的端口？是什么？

我相信楼主肯定混淆了某些概念.

查了一下，TCP监听端会为每一个连接fork()一个新的套接字，可是没有提到会使用一个新的端口。是我记错了。我以为会使用一个新的端口。

如果这样的话，我想在netfilter里面分辨不同的TCP连接改怎么办呢？我的程序要对不同的连接进行地址修改，有点像本地的NAT。 谢谢了！

我猜想你是想分辨具体的数据报的功能，然后采取相应处理这样一个需求吧。如果这样，你从判断数据报的一些特殊关键字或者域来做相应处理不就行了，你前面说到的端口不就相当于你的一个判断条件吗？

我是要分辨不同的TCP连接，可是这些连接都是连到本地同一个监听端口上的。原来的设计是使用本地端口作为哈希表的索引，这样查表效率也比较高，可是这种设计对于fork出来的连接就不管用了。 另外，我本来是可以使用远程地址+远程端口作为关键字的，可是因为我做的是移动IP方面的东西，也就是说远程IP地址在一段时间以后可能会被分配给不同的节点，如果它们再使用同样的端口，那么我这边就有问题了。虽然这种情况的概率比较小，但也不可以忽略。

所以我想知道的是在网络层有没有可能分辨这类fork出来的连接呢？

远程地址+端口，作为这一条连接来说，它是不会改变的，如果改变，那这条连接也就断了，需要重新建立。即使你说的假如可以使用本地端口作为判断，那远程地址或者端口变了，你这条连接也得重新建立。