[歡迎進(jìn)入討論] 關(guān)于syn-proxy的一些問(wèn)題

Godbach

原帖由 dreamice 于 2009-3-13 10:01 發(fā)表


透明代理的話，tcp握手直接和proxy完成了，不用關(guān)心這個(gè)問(wèn)題。
但后續(xù)通信的包，需要proxy和server再建立一次連接。

tcp握手時(shí)，client知道他是直接和proxy握手的呢，還是client一直是以為和server在握手？

dreamice

原帖由 Godbach 于 2009-3-13 10:09 發(fā)表


tcp握手時(shí)，client知道他是直接和proxy握手的呢，還是client一直是以為和server在握手？

如果是透明代理的話，client當(dāng)然是不知道的是在和proxy握手的。
如果是反向代理，那就知道了

richardhesidu

這樣行不行
自己定一個(gè)my_sock結(jié)構(gòu)，里面存儲(chǔ)源地址，源端口，目標(biāo)地址，目標(biāo)端口，差值，skb_buff鏈表（存儲(chǔ)SYN包），連接狀態(tài)。再創(chuàng)建一個(gè)my_sock的hash表。client和firewall第一次握手的時(shí)候，創(chuàng)建一個(gè)my_sock。firewall和server完成第二次握手的時(shí)候給my_sock的差值賦值。完成所有六次握手以后，把my_sock.state設(shè)為TCP_ESTABLISHED。對(duì)以后所有收到的包，匹配其地址和端口。并判斷state是否established。如果是，就根據(jù)情況修改ack或是syn。

dreamice

原帖由 richardhesidu 于 2009-3-13 10:32 發(fā)表
這樣行不行
自己定一個(gè)my_sock結(jié)構(gòu)，里面存儲(chǔ)源地址，源端口，目標(biāo)地址，目標(biāo)端口，差值，skb_buff鏈表（存儲(chǔ)SYN包），連接狀態(tài)。再創(chuàng)建一個(gè)my_sock的hash表。client和firewall第一次握手的時(shí)候，創(chuàng)建一個(gè)my_s ...

老大，你這個(gè)實(shí)現(xiàn)太復(fù)雜了。
現(xiàn)在新版內(nèi)核也支持透明代理，實(shí)現(xiàn)非常簡(jiǎn)單：client發(fā)起和server的連接，被proxy攔截（注意這里是攔截），然后偽裝成server和client建立起連接，
連接建立成功以后，proxy在偽裝成client向server請(qǐng)求數(shù)據(jù)（當(dāng)然這里也要和server建立tcp連接），server返回?cái)?shù)據(jù)后，再次被proxy攔截，proxy此時(shí)偽裝成server
向client返回?cái)?shù)據(jù)。

這個(gè)過(guò)程就是完全的透明代理。

反向代理則不同：
client不知道server的存在，把proxy當(dāng)成server，而proxy有自己的IP，client請(qǐng)求proxy的時(shí)候，proxy再以自己的身份向真正的server發(fā)起請(qǐng)求，并獲取返回包，最后proxy再以自己的身份向client返回包。這個(gè)過(guò)程，可以說(shuō)對(duì)server來(lái)說(shuō)，他的client只是proxy，對(duì)client來(lái)說(shuō)，server就是proxy。

richardhesidu

原帖由 dreamice 于 2009-3-13 12:12 發(fā)表


老大，你這個(gè)實(shí)現(xiàn)太復(fù)雜了。
現(xiàn)在新版內(nèi)核也支持透明代理，實(shí)現(xiàn)非常簡(jiǎn)單：client發(fā)起和server的連接，被proxy攔截（注意這里是攔截），然后偽裝成server和client建立起連接，
連接建立成功以后，proxy在偽 ...

透明代理的確是一個(gè)不錯(cuò)的解決方法。
樓主說(shuō)的syn proxy跟透明代理還是不同。syn proxy只是對(duì)Client和Server之間的三次握手做一個(gè)類似的透明代理。建立連接后，數(shù)據(jù)的傳輸只是轉(zhuǎn)發(fā)而已。
如果純粹是防SYN Flood攻擊，可能syn proxy效率會(huì)高一些吧。

dreamice

原帖由 richardhesidu 于 2009-3-13 12:59 發(fā)表

透明代理的確是一個(gè)不錯(cuò)的解決方法。
樓主說(shuō)的syn proxy跟透明代理還是不同。syn proxy只是對(duì)Client和Server之間的三次握手做一個(gè)類似的透明代理。建立連接后，數(shù)據(jù)的傳輸只是轉(zhuǎn)發(fā)而已。
如果純粹是防SYN F ...

嗯，這個(gè)應(yīng)用倒是。

Godbach

syn proxy只是對(duì)Client和Server之間的三次握手做一個(gè)類似的透明代理。建立連接后，數(shù)據(jù)的傳輸只是轉(zhuǎn)發(fā)而已。

我覺(jué)得這里在建立連接后，數(shù)據(jù)的傳輸報(bào)文還是需要被修改的啊。怎么會(huì)是透明的呢？

richardhesidu

原帖由 Godbach 于 2009-3-13 13:07 發(fā)表


我覺(jué)得這里在建立連接后，數(shù)據(jù)的傳輸報(bào)文還是需要被修改的啊。怎么會(huì)是透明的呢？

透明的意思就是看不到或者不用關(guān)心啊。syn proxy中，client和server都不知道firewall的存在。
透不透明，跟firewall是否修改報(bào)文沒(méi)有關(guān)系。

Godbach

明白:wink:
那這樣來(lái)說(shuō)syn-proxy應(yīng)該就是透明代理啊。用戶一直是不知道Firewall的。

[ 本帖最后由 Godbach 于 2009-3-13 13:35 編輯 ]

dreamice

原帖由 Godbach 于 2009-3-13 13:34 發(fā)表
明白:wink:
那這樣來(lái)說(shuō)syn-proxy應(yīng)該就是透明代理啊。用戶一直是不知道Firewall的。

那不就跟我說(shuō)的那個(gè)差不多了
如果除了syn包都不走proxy的話，那只能說(shuō)是syn cookie的transparent proxy吧