应如何正确计算 TCP 序号？

platinum

有这样一个需求：
一个桥设备，修改某个 TCP 连接后的七层 request，修改其内容，重新计算校验和，继续把数据包放回系统透传

遇到一个问题：
因为修改了 request，所以 payload 长度产生了变化（可能多、可能少），skb->len 变化了，skb 中所有与长度有关的都已经调整
但是，当 TCP 在局域网中测试时没问题，在互联网上就不行了

问题原因：
虽然 skb 长度正确，IP chksum 正确、TCP chksum 正确，但 TCP 序号并未改变，导致互联网中的某些硬件将数据包丢弃，导致网络不通

如何解决？
1、在系统中维护这个 TCP 连接的序号，重新计算，但应该怎么计算？
2、不清楚是否滑动窗口也要重新计算？
3、如果 TCP 连接正常，这个规律还相对简单，如果遇到丢包、重传、乱序、复制包怎么办？如何判断？
4、如果改变了 seq，那么 ack_seq 肯定也要改的，win 呢？是否也需要一起修改？
5、上面的解决思路是否正确？是否有什么好方法可以解决这个问题呢？

[ 本帖最后由 platinum 于 2008-10-30 11:36 编辑 ]

Godbach

原帖由 platinum 于 2008-10-30 11:25 发表
有这样一个需求：
一个桥设备，修改某个 TCP 连接后的七层 request，修改其内容，重新计算校验和，继续把数据包放回系统透传

遇到一个问题：
因为修改了 request，所以 payload 长度产生了变化（可能多、可 ...

这个地方，白金兄的意思是肯定要改TCP的序列号吗?

那个RFC上有相关的规定啊，我和同事讨论了一下，都想不通这里为什么要修改序列号？

Jobs.AE@

你修改了payload以及所有相关len后，影响到的是下一个报文的sequence number，而不是当前的。

所以理论上讲，第一个报文你不需要修改seq，而后续的，由于host不知道你修改了payload，使用的seq可能就与正确的不符了，你需要进行差值计算。

如果方便你最好把通信的全过程抓包记录下来，报文发给我看看，修改前、修改后的。

滑动窗口的问题我想想再回答你。。。

Jobs.AE@

BTW：根据一些较严格的安全设备标准，seq和window这些参数都是需要审核的

可能你的局域网环境没有穿越类似设备，所以无法reproduce

Godbach

你修改了payload以及所有相关len后，影响到的是下一个报文的sequence number，而不是当前的。

所以理论上讲，第一个报文你不需要修改seq，而后续的，由于host不知道你修改了payload，使用的seq可能就与正确的不符了，你需要进行差值计算。

如果方便你最好把通信的全过程抓包记录下来，报文发给我看看，修改前、修改后的。

滑动窗口的问题我想想再回答你。。。

LS的回复让偶明白一些了。

那么如果后续的序列号不该，因为第一个被修改的数据包到请求的主机之后，主机发送响应包，这个包恢复到了host上之后，host应该可以接收到吧，但是因为序列号不对而被Drop了吗？

Godbach

那这样的话，是不是需要桥去处理所有是当前连接的发到Host包的序列号，以便host验证通过？

Godbach

原帖由 Jobs.AE@ 于 2008-10-30 11:40 发表
BTW：根据一些较严格的安全设备标准，seq和window这些参数都是需要审核的

可能你的局域网环境没有穿越类似设备，所以无法reproduce

按照你的解释，如果LZ修改完数据包，但不修改序列号的好，应该是可以到达请求主机，而且请求主机的回应包也会发送的HOST上。

而不是LZ的那种情况，数据包在转发过程中就被丢弃了。

Jobs.AE@

1、在系统中维护这个 TCP 连接的序号，重新计算，但应该怎么计算？
3、如果 TCP 连接正常，这个规律还相对简单，如果遇到丢包、重传、乱序、复制包怎么办？如何判断？
4、如果改变了 seq，那么 ack_seq 肯定也要改的，win 呢？是否也需要一起修改？
5、上面的解决思路是否正确？是否有什么好方法可以解决这个问题呢？

问题1：2楼解答了，再说一下方法，链接建立的第一个报文的seq相对为1，下一个报文（同方向）的seq等于1+len（第一个报文payload长度），以此类推
问题3：丢包就丢呗，跟你无关；重传，重新计算；乱序，与你无关；复制，所有字段保持一致；
问题4：同一个报文的seq与ack_seq是互为反方向的，按照2楼及问题1的解答处理；
问题5：如果不想处理复杂的协议校验修改，建议使用proxy模式。

粗粗一想，可能有不妥之处，你再斟酌啊，呵呵～～

Jobs.AE@

原帖由 Godbach 于 2008-10-30 11:55 发表


按照你的解释，如果LZ修改完数据包，但不修改序列号的好，应该是可以到达请求主机，而且请求主机的回应包也会发送的HOST上。

而不是LZ的那种情况，数据包在转发过程中就被丢弃了。

转发过程中，某些设备就回去校验你的seq对不对，不用等到host

我又想了一下，如果这样改了，host对收到的回应报文有可能丢弃，因为ack与他发送的seq不符了

似乎这个需求在不做proxy的情况下有点不可实现，违反了太多审查规定了。

Godbach

下一个报文（同方向）的seq等于1+len（第一个报文payload长度），以此类推

也就是被请求主机回应数据包的ACK_SEQ吧。

如果不想处理复杂的协议校验修改，建议使用proxy模式。

proxy应该处理后续的双向的包吧？