linux多路路由保持长链接的问题

platinum

我看不懂你的实现，但是我觉得好像有问题
正确的做法应该是直接获取 ip、port、protocol，通过 hash 函数计算 key，直接在 conntrack 里查表看是否存在

瀚海书香

回复 21# platinum
因为有skb，所以ct=nf_ct_get(skb,&ctinfo)获取。而ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip则应该是应答包的目的ip地址，那么你的下一跳就应该是从这个ip地址所属的接口出去的。
例如:
内口:192.168.0.1
外口1:172.16.0.2
外口2:172.16.1.2
route default via nexthop 172.16.0.1
                           nexthop 172.16.1.1

如果有一个连接 192.168.0.8---x.x.x.x，使用路由172.16.0.1，那么应答连接应该是 x.x.x.x---172.16.0.2；所以我们如果知道应答连接的目的ip是172.16.0.2的话，那么它的原连接的路由就应该是172.16.0.1。也就是应答的目的ip跟路由应该是同一个网段的。

platinum

1、为什么一定是 REPLY 包的 IP
2、如果本身也做了 NAT，那么可能还比较麻烦，因为 MASQUERADE 和 SNAT 是在 POSTROUTING 里做的

瀚海书香

回复 23# platinum
就是因为做SNAT所以才用在reply的dip。因为如果做snat的话，reply的dip就应该是snat后的ip。
虽然snat是在postrouting，但是我们只对已建立的链接确保路由flush后再次查询的路由跟上次的不变，所以说我们处理的链接已经是做了snat的了。因为snat只对新建的链接和related的链接起作用。

platinum

我不太了解路由的选路方式，如果数据是从外面主动向内请求的呢？是不是也依然如此？
另外，如果是 FTP 的 DATA 信道，在开启 nf_nat_ftp 模块的情况下，状态不是 ESTABLISHED，而是 RELATED，这个你考虑了没有？

瀚海书香

回复 25# platinum
如果从外向内请求的情况，因为向内的路由的单路的，所以应该不会做多路路由这一部分的，而对应的向外的时候应该是查询local表，不会走multipath，所以应该没问题。
本人接触的网络拓扑比较少，可能有理解不到的地方。

瀚海书香

回复 18# ShadowStar

ShadowStar兄，不要在那偷着笑了
给点别的思路吧

platinum

回复  platinum
就是因为做SNAT所以才用在reply的dip。因为如果做snat的话，reply的dip就应该是snat后的ip。
瀚海书香 发表于 2010-06-24 17:04

如果是从外网回来的包，是 REPLY，在 PREROUTING 阶段目的 IP 被还原，
在 ROUTING 阶段看到的应该是内网 IP，也就是 SNAT 之前的，如果是这样，那么和你说的恰好相反啊？

瀚海书香

回复 28# platinum
如果是从外网回来的包，是 REPLY，在 PREROUTING 阶段目的 IP的确 被还原，但是在nf_conn的tuplehasn中记录的是没有被还原的ip。

platinum

回复 29# 瀚海书香


我的理解是这样的你看对不对
1、如果是从内网出去的请求，REPLY 状态包是从外网回来的
2、如果是从外网主动进来的请求，那么无论是 ORIGIN 还是 REPLY 都不走 route.c 中的 ROUTE_MULTIPATH 流程，因此不用考虑如何处理

如果是这样的，那么我有一个疑问
从内网出去的包的回包，根据 NAT 要做 DNAT 转换，而这个转换是在 PREROUTING 阶段完成的，那么为什么在 ROUTE 阶段看到的 DIP 却是转换前的呢？