请问在如何在NF_LOCAL_IN获得TCPv4包的目标（本机）端口？

dreamice

原帖由 piaobo79 于 2008-7-3 14:18 发表


不是SIP的NAT，我只是使用SIP消息来进行地址的更新而已，和SIP本身的NAT机制无关。

我说了是在服务器和客户端的内核里实现NAT，也就是地址映射。现在的问题是为了正确的映射原有的IP地址，我需要对收到的 ...

我觉得用netfilter的helper机制可以解决你的问题。有个问题:移动ip变了，但是通信的端口我觉得应该是不会变的，因为可以说一个端口对应于一个服务程序。至于你移动ip端如何实现，我不了解；但是对于服务端，监听某个端口，建立一个conntrack，一旦ip变化了，这个conntrack实际上是无效了，那就通过helper来建立一个新的conntrack。

piaobo79

原帖由 dreamice 于 2008-7-3 15:18 发表


我觉得用netfilter的helper机制可以解决你的问题。有个问题:移动ip变了，但是通信的端口我觉得应该是不会变的，因为可以说一个端口对应于一个服务程序。至于你移动ip端如何实现，我不了解；但是对于服务端， ...

请问conntrack 是按照什么来track的呢？ 如果是<saddr,sport,daddr,dport>的话就不管用了。因为saddr,sport和daddr都可能会变,只有dport,也就是本地的端口才不会变。可是fork出来的连接dport是一样的。

dreamice

原帖由 piaobo79 于 2008-7-3 17:10 发表


请问conntrack 是按照什么来track的呢？ 如果是的话就不管用了。因为saddr,sport和daddr都可能会变,只有dport,也就是本地的端口才不会变。可是fork出来的连接dport是一样的。

daddr也可能变？那ip都变了怎么能到达你的服务器（也就是你的机子）？saddr,sport变是可以理解的，netfilter在内核里面，确切的说是IP层，还没有到你考虑fork的时候。一条conntrack包含（saddr,sport，daddr,dport，protocol（TCP or UDP）），如果你的mobile device的数据报能到达你的服务端，而且服务不中断，那必须属于一条有效conntrack，必须由数据报内容来协商后续通信的ip地址及端口，建立一条expect 连接（期望的连接），这样，后续的通信才能通过netfilter到达你提供的服务。如果如你所说的，“saddr,sport和daddr都可能会变”，那没办法分辨连接了。
有些参数是变的，而有些是不会变的，通过不变的来处理变化的，这是ip conntrack及expect里面实现的功能，sip，h323的实现都是包括多条连接的，其中包括控制连接，数据连接等等，你这个也可以援引这种方式，当ip发生变化时，意味着上一条连接已经失效了，新的ip协商将建立一条新的连接，就保证了服务的连续性了。

[ 本帖最后由 dreamice 于 2008-7-3 20:48 编辑 ]

piaobo79

原帖由 dreamice 于 2008-7-3 18:03 发表


daddr也可能变？那ip都变了怎么能到达你的服务器（也就是你的机子）？saddr,sport变是可以理解的，netfilter在内核里面，确切的说是IP层，还没有到你考虑fork的时候。一条conntrack包含（saddr,sport，dadd ...

看来是很难做到了。daddr可变是因为服务端也可能是移动的，也是采用移动IP，这点我们已经实现了. 移动IP的主要目的就是在双方IP改变的时候把这个变化隐藏起来，使传输层以上都不能察觉, 这样才实现无缝移动。我们不使用SIP的方式是因为要兼容原有不支持移动IP的程序，所以不能在传输层或者之上实现。

dreamice

两个不会是同时变，所以你这个是完全可以实现的。我觉得你好好缕一下思路。

piaobo79

同时变的几率很小，可是不能不考虑...我再想别的办法吧。