Linux內(nèi)核發(fā)送構(gòu)造數(shù)據(jù)包的方式

Godbach

原帖由 瀚海書(shū)香 于 2009-9-2 17:14 發(fā)表
分析的非常好，小弟收藏了

呵呵，多多交流。帖子中也是有提出問(wèn)題的，大家有相關(guān)經(jīng)驗(yàn)的可以分享一下。

瀚海書(shū)香

其實(shí)好像發(fā)送也可以通過(guò)接收來(lái)實(shí)現(xiàn)。
在PREROUTING點(diǎn)上修改數(shù)據(jù)包的目的ip，然后修改校驗(yàn)和，之后調(diào)用netif_receive_skb(),這樣數(shù)據(jù)包就會(huì)走forward鏈而發(fā)送出去。

Godbach

原帖由 瀚海書(shū)香 于 2009-9-2 17:27 發(fā)表
其實(shí)好像發(fā)送也可以通過(guò)接收來(lái)實(shí)現(xiàn)。
在PREROUTING點(diǎn)上修改數(shù)據(jù)包的目的ip，然后修改校驗(yàn)和，之后調(diào)用netif_receive_skb(),這樣數(shù)據(jù)包就會(huì)走forward鏈而發(fā)送出去。

你的意思相當(dāng)于，修改后的數(shù)據(jù)包再次走PREROUTING點(diǎn)了。

另外，修改之后是否會(huì)走forward還是需要看路由的。

platinum

原帖由 Godbach 于 2009-9-2 16:56 發(fā)表


你的意思是說(shuō)，如果在橋模式下使用REJECT，RST包可能發(fā)布出去。

是的，應(yīng)該發(fā)不出去，因?yàn)橹皇切薷牧嗽茨康?IP 源目的 PORT，之后交給 LOCAL_OUT 自動(dòng)選路了
因此，本地協(xié)議棧會(huì)自動(dòng)尋找適合的 interface 去發(fā)包，整個(gè)過(guò)程沒(méi)有修改 dev

[ 本帖最后由 platinum 于 2009-9-2 17:50 編輯 ]

瀚海書(shū)香

如果目的ip是本地就不會(huì)走forward，如果目的ip不是本地就會(huì)走forward。

修改之后會(huì)重新進(jìn)入NF的流程

platinum

原帖由 瀚海書(shū)香 于 2009-9-2 17:36 發(fā)表
如果目的ip是本地就不會(huì)走forward，如果目的ip不是本地就會(huì)走forward。

修改之后會(huì)重新進(jìn)入NF的流程

如果是別人發(fā)過(guò)來(lái)的包，那確實(shí)如此，如果是自己發(fā)出去的包，就和 FORWARD 無(wú)關(guān)了

Godbach

原帖由 platinum 于 2009-9-2 17:32 發(fā)表

是的，應(yīng)該發(fā)不出去，因?yàn)橹皇切薷牧嗽茨康?MAC 和源目的 IP 源目的端口，之后交給 LOCAL_OUT 自動(dòng)選路了
因此，本地協(xié)議棧會(huì)自動(dòng)尋找適合的 interface 去發(fā)包，整個(gè)過(guò)程沒(méi)有修改 dev

REJECT模塊并未修改源和目的MAC的吧。

另外，在構(gòu)造包并調(diào)用dev_queue_xmit函數(shù)之前，也并未修改dev啊。

Godbach

修改之后會(huì)重新進(jìn)入NF的流程

這種修改之后調(diào)用netif_recieve_skb的方式你是否實(shí)踐過(guò)?

platinum

原帖由 Godbach 于 2009-9-2 17:48 發(fā)表


REJECT模塊并未修改源和目的MAC的吧。

另外，在構(gòu)造包并調(diào)用dev_queue_xmit函數(shù)之前，也并未修改dev啊。

是的，我看錯(cuò)了，沒(méi)有修改 MAC
送到上層后，是通過(guò)本地 IP 棧自動(dòng)選路的

Godbach

原帖由 platinum 于 2009-9-2 17:51 發(fā)表

是的，我看錯(cuò)了，沒(méi)有修改 MAC
送到上層后，是通過(guò)本地 IP 棧自動(dòng)選路的

對(duì)。這個(gè)地方send_reset為什么還需要自己在模塊代碼中查找新路由呢，交給IP協(xié)議棧統(tǒng)一處理不行嗎？