[欢迎进入讨论] 关于syn-proxy的一些问题

Godbach

原帖由 richardhesidu 于 2009-3-17 10:40 发表
不知道Godbach兄有没有考虑伪造包丢失的问题。
如果由于网路问题，client或sever没有收到，是否得考虑重发。給client发的syn+ack包可能没有问题，因为client会继续发送syn包。而由fw伪造的发给server的syn包和 ...

我觉得这个地方丢失就丢失吧。毕竟client和server不经过防火墙的时候可能也会存在丢包的情况啊。这个交给两端的TCP协议去处理。

Godbach

原帖由 richardhesidu 于 2009-3-17 10:55 发表
还有就是资源回收的问题了。比如ip conntrack的注销。

conntrack有自身的机制来进行超时，并删除的。这个地方既然你利用了conntrack，就不用考虑conntrack表项的删除问题了。

dreamice

原帖由 ShadowStar 于 2009-3-17 10:47 发表


透明代理的问题如下：
1。防火墙本身为网络瓶颈。在大流量攻击下是否能抗得住？
2。代理本身屏蔽了原始client的IP，导致服务器本身没有真实的访问记录。

问题1确实存在；
问题2不存在

ShadowStar

原帖由 dreamice 于 2009-3-17 11:19 发表


问题1确实存在；
问题2不存在

问题2，你确定？我没有看28的代码，不太清楚TP_PROXY。

Godbach

原帖由 ShadowStar 于 2009-3-17 11:28 发表


问题2，你确定？我没有看28的代码，不太清楚TP_PROXY。

使用透明代理是好像是需要将代理设置为client的网关。

ShadowStar

原帖由 Godbach 于 2009-3-17 11:50 发表

使用透明代理是好像是需要将代理设置为client的网关。

刚才和dreamice在QQ上探讨了一下。

结论是，2.6.28内核中的nf_tproxy还未完善，所作的工作仅仅是查找socket的存在与否。

而且，采用透明代理方式，其实就是syn proxy。或者说，syn proxy比两侧分别协商的透明代理更优化。

Godbach

原帖由 ShadowStar 于 2009-3-17 12:34 发表


刚才和dreamice在QQ上探讨了一下。

结论是，2.6.28内核中的nf_tproxy还未完善，所作的工作仅仅是查找socket的存在与否。

而且，采用透明代理方式，其实就是syn proxy。或者说，syn proxy比两侧分别协 ...

呵呵，那现在syn-proxy可能还得自己去实现啊

kns1024wh

需要做序列号的验证

Godbach

原帖由 kns1024wh 于 2009-3-17 18:11 发表
需要做序列号的验证

恩。不知kns1024wh兄做过syn-proxy的研究没有？

独孤九贱

原帖由 platinum 于 2009-3-16 14:13 发表
记得当初九贱兄也是自己一点一点慢慢摸索出来的，大概有一年了吧？
不知道效率如何？有没有新的改动呢？

也不能说是自己摸索，偶一个同事，在N年前就在4.4BSD还是啥BSD上实现了。很多小的技巧性的东东——例如：处理“当完成客户端三次握手，再去同服务器三次握手时，客户端的请求可能会提前到来。”的问题，都是向他请教的哈。
效率上还是有改进，我在一个533MHz上，处理接近30Wpps的虚假syn包，好像还可以对付哈。就是处理ack 反弹上不太理想，做了些工作，但是还是有待改进呀。