亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: 【netfilter】關(guān)于構(gòu)造和發(fā)送數(shù)據(jù)包 [打印本頁]

作者: triplesheep    時間: 2015-06-20 20:48
標(biāo)題: 【netfilter】關(guān)于構(gòu)造和發(fā)送數(shù)據(jù)包
最近看了兩篇關(guān)于netfilter構(gòu)造和發(fā)送數(shù)據(jù)包的文章,總結(jié)起來大概是有兩種方法,一是構(gòu)造完包以后繼續(xù)走NF流程,需要手動路由;二是利用dev_queue_xmit函數(shù)發(fā)送,需要構(gòu)造MAC地址,有一些問題想要問問大家,謝謝大家~~~
方法一:
1、看的文章(“Linux內(nèi)核發(fā)送構(gòu)造數(shù)據(jù)包的方式”)中手動路由后將數(shù)據(jù)包發(fā)出,沒有對mac層進(jìn)行處理,這樣沒有問題嗎(比如我將源ip和目的ip交換,那么mac的源地址和目的地址應(yīng)該也要交換吧)?還是由于是在ip層進(jìn)行處理所以屏蔽了mac層的影響?還是后面會自動加上mac?謝謝~~~
2、假設(shè)在LOCAL_OUT點(diǎn)進(jìn)行了構(gòu)造包的處理,源ip和目的ip交換,那么發(fā)送出去后是會回到PRE_ROUTING點(diǎn)然后正常進(jìn)行處理的是嗎?
方法二:
1、我將源ip和目的ip交換,那么mac的源地址和目的地址是不是只需要簡單的交換就可以用dev_queue_xmit發(fā)出數(shù)據(jù)包了?
2、在LOCAL_OUT中的數(shù)據(jù)包是沒有MAC層數(shù)據(jù)的,這樣是不是就沒辦法的到mac的相關(guān)信息了,方法二是不是就行不通。
3、這種方法構(gòu)造的數(shù)據(jù)包為什么不用對路由進(jìn)行相關(guān)的處理?
另:
1、在hook點(diǎn)將自己鉤子設(shè)置為第一優(yōu)先級NF_IP_PRI_FIRST是不是有時候會影響到本來的路由信息(因?yàn)?個hook點(diǎn)本身掛有路由連接相關(guān)的函數(shù))?
最近忙著考試,沒有特別特別認(rèn)真的看相關(guān)資料,有些大錯誤還麻煩大家指出,跪謝大家~~跪謝大家~~~
作者: firocu    時間: 2015-06-22 12:17
本帖最后由 firocu 于 2015-06-22 12:18 編輯

方法一
1. 我沒看那篇文章, 既然在網(wǎng)絡(luò)層構(gòu)造的報(bào)文, 發(fā)包到鏈路層自然會根據(jù)ip地址, 自動生成MAC頭部.
2. 在local out發(fā)送的報(bào)文目的地址本機(jī)的, 路由之后會ip_local_deliver, 送上來不會經(jīng)過pre routing


方法二:
1. 同上
2, 3  沒理解, 你可以看看這個函數(shù)neigh_connected_output

另,
hook 點(diǎn)的優(yōu)先級和路由無關(guān).

PS:
真羨慕樓主, 大學(xué)就搞這些東西.
回復(fù) 1# triplesheep


   
作者: triplesheep    時間: 2015-06-25 15:12
不好意思現(xiàn)在才回復(fù),跪謝ORZ回答~~~,我打算先在ubuntu下試驗(yàn)一下~\(≧▽≦)/~回復(fù) 2# firocu


   
作者: nswcfd    時間: 2015-06-25 20:45
本帖最后由 nswcfd 于 2015-06-25 20:47 編輯

>方法一:
>1、看的文章(“Linux內(nèi)核發(fā)送構(gòu)造數(shù)據(jù)包的方式”)中手動路由后將數(shù)據(jù)包發(fā)出,沒有對mac層進(jìn)行處理,這樣沒有問題嗎(比如我將源ip和目的ip交換,那么mac的源地址和目的地址應(yīng)該也要交換吧)?還是由于是在ip層進(jìn)行處理所以屏蔽了mac層的影響?還是后面會自動加上mac?謝謝~~~
繼續(xù)走netfilter,最終會執(zhí)行dst->output,在那里會跟ARP子系統(tǒng)進(jìn)行交互,也就是firocu提到的neigh_connected_output這一族函數(shù)。
所以不需要顯式的關(guān)心MAC問題。

>2、假設(shè)在LOCAL_OUT點(diǎn)進(jìn)行了構(gòu)造包的處理,源ip和目的ip交換,那么發(fā)送出去后是會回到PRE_ROUTING點(diǎn)然后正常進(jìn)行處理的是嗎?
LOCAL_OUT出去的報(bào)文源地址是本機(jī),如果交換了IP,目的地址是變成了本機(jī),源變成了外部地址。
假設(shè)沒有修改路由,還是使用原來目的IP的dst_entry,則修改的報(bào)文可以跟修改前一樣,向nexthop正常發(fā)送;
如果修改了路由,使用本機(jī)地址對應(yīng)的dst_entry,會路由到lo設(shè)備上,而lo的xmit行為是會再次進(jìn)入PREROUTING的。
至于這樣的報(bào)文,4層協(xié)議棧能否正常處理就不好說了,因?yàn)樵词峭獠康刂贰?br />
to firocu: ip_local_deliver是dst的input函數(shù),只會在route_input的上下文里被賦值。這里是route_output場景,最終生效的是dst的output函數(shù)!救绻绣e誤,請糾正。】

>方法二:
>1、我將源ip和目的ip交換,那么mac的源地址和目的地址是不是只需要簡單的交換就可以用dev_queue_xmit發(fā)出數(shù)據(jù)包了?
如果在路由轉(zhuǎn)發(fā)路徑(ip_forward)上,數(shù)據(jù)包上有MAC,交換可以。
但問題是交換之后,下游設(shè)備(或接收端)認(rèn)不認(rèn)這個修改后的目的MAC(原來的源MAC,而不是接收端的MAC)。
此外,交換ip和mac,不修改出接口嗎?交換ip是為了滿足什么功能?

>2、在LOCAL_OUT中的數(shù)據(jù)包是沒有MAC層數(shù)據(jù)的,這樣是不是就沒辦法的到mac的相關(guān)信息了,方法二是不是就行不通?
是的,調(diào)用dev_queue_xmit,必須準(zhǔn)備好所有的內(nèi)容,包含二層MAC。

>3、這種方法構(gòu)造的數(shù)據(jù)包為什么不用對路由進(jìn)行相關(guān)的處理?
因?yàn)閐ev_queue_xmit是協(xié)議棧最后的發(fā)送接口,它假設(shè)調(diào)用者已經(jīng)把所有packet的內(nèi)容都填好了,并且內(nèi)部也沒有用到dst_entry。
它是所有發(fā)送路徑的總匯聚口,無論是三層路由,還是二層交換(bridge/vlan),最后都通過這個接口調(diào)用driver的xmit函數(shù)。不是所有的路徑都需要有dst_entry,比如bridge交換。
作者: triplesheep    時間: 2015-07-05 19:54
不好意思,最近忙考試現(xiàn)在才回復(fù)。
>2、假設(shè)在LOCAL_OUT點(diǎn)進(jìn)行了構(gòu)造包的處理,源ip和目的ip交換,那么發(fā)送出去后是會回到PRE_ROUTING點(diǎn)然后正常進(jìn)行處理的是嗎?
LOCAL_OUT出去的報(bào)文源地址是本機(jī),如果交換了IP,目的地址是變成了本機(jī),源變成了外部地址。
假設(shè)沒有修改路由,還是使用原來目的IP的dst_entry,則修改的報(bào)文可以跟修改前一樣,向nexthop正常發(fā)送;
如果修改了路由,使用本機(jī)地址對應(yīng)的dst_entry,會路由到lo設(shè)備上,而lo的xmit行為是會再次進(jìn)入PREROUTING的。
至于這樣的報(bào)文,4層協(xié)議棧能否正常處理就不好說了,因?yàn)樵词峭獠康刂贰?br />
那不經(jīng)過路由處理直接交換地址后的報(bào)文能夠正常的進(jìn)行處理嗎?目的地址變成本機(jī)后如果不再次進(jìn)入PREROUTING那它怎么將修改到的包交給本機(jī)呢?那個nexthop最終不會回到PREROUTING嗎?

>1、我將源ip和目的ip交換,那么mac的源地址和目的地址是不是只需要簡單的交換就可以用dev_queue_xmit發(fā)出數(shù)據(jù)包了?
如果在路由轉(zhuǎn)發(fā)路徑(ip_forward)上,數(shù)據(jù)包上有MAC,交換可以。
但問題是交換之后,下游設(shè)備(或接收端)認(rèn)不認(rèn)這個修改后的目的MAC(原來的源MAC,而不是接收端的MAC)。
此外,交換ip和mac,不修改出接口嗎?交換ip是為了滿足什么功能?

這個我當(dāng)時是看了一篇文章它就是直接 截取數(shù)據(jù)包進(jìn)行復(fù)制->修改ip地址->填充mac地址->發(fā)送,沒涉及到出接口所以我不是很懂QAQ


>2、在LOCAL_OUT中的數(shù)據(jù)包是沒有MAC層數(shù)據(jù)的,這樣是不是就沒辦法的到mac的相關(guān)信息了,方法二是不是就行不通啊?
是的,調(diào)用dev_queue_xmit,必須準(zhǔn)備好所有的內(nèi)容,包含二層MAC。

那在請教一下存在什么函數(shù)可以在LOCAL_OUT點(diǎn)提取出MAC地址嗎?


再再再PS:目前看到的構(gòu)造數(shù)據(jù)包的要么是直接修改了原包,要么就把原包給丟了直接發(fā)新的包,在netfilter里可以在原包基礎(chǔ)上構(gòu)造一個新包然后原包和新包都留下一起發(fā)送嗎?就是
兩個都要發(fā)送?
跪謝大大~~
回復(fù) 4# nswcfd


   
作者: nswcfd    時間: 2015-07-06 12:32
> 那不經(jīng)過路由處理直接交換地址后的報(bào)文能夠正常的進(jìn)行處理嗎?目的地址變成本機(jī)后如果不再次進(jìn)入PREROUTING那它怎么將修改到的包交給本機(jī)呢?那個nexthop最終不會回到PREROUTING嗎?

“正!钡亩x是什么?再把報(bào)文送回給本機(jī)(因?yàn)槟康腎P現(xiàn)在是本地地址)?僅交換IP并不能保證,還得看路由指向哪個接口。
loopback的過程是這樣:0)output路由;1)路由到lo;2)執(zhí)行l(wèi)o的發(fā)送;3)再次rx;4)PREROUTING;5)input路由;6)路由到本機(jī);7)送協(xié)議棧
如果不是,在步驟2)就發(fā)到其它機(jī)器上了。

> 這個我當(dāng)時是看了一篇文章它就是直接 截取數(shù)據(jù)包進(jìn)行復(fù)制->修改ip地址->填充mac地址->發(fā)送,沒涉及到出接口所以我不是很懂QAQ

我沒看你談到的文章,方便的話給個鏈接。
看起來它沒改接口,就是重用原來路由的接口。
那么它修改的ip/mac分別是什么?由于是實(shí)驗(yàn)代碼,猜測是這種拓?fù)洌?A --> R --> B/C,代碼在R上執(zhí)行,把B的ip/mac修改為【同一個網(wǎng)段上】的C。

> 那在請教一下存在什么函數(shù)可以在LOCAL_OUT點(diǎn)提取出MAC地址嗎?

要是可以的話,ARP協(xié)議就沒有存在的必要了
在前面的例子里,寫代碼的人【事先知道】C的mac,所以就可以繞過ARP了。

> 再再再PS:目前看到的構(gòu)造數(shù)據(jù)包的要么是直接修改了原包,要么就把原包給丟了直接發(fā)新的包,在netfilter里可以在原包基礎(chǔ)上構(gòu)造一個新包然后原包和新包都留下一起發(fā)送嗎?就是兩個都要發(fā)送?

還是舉A -> R -> B/C的例子,R可以選擇把兩個報(bào)文都發(fā)出去,這樣B/C都會應(yīng)答,最終結(jié)果是A凌亂了

作者: triplesheep    時間: 2015-07-11 23:32
跪謝大大的回復(fù),兩個帖子都是大大回復(fù)的,跪跪跪跪謝ORZ
那篇文章的鏈接是:http://www.72891.cn/thread-1941060-1-1.html,也是版里的大大寫的
回復(fù) 6# nswcfd


   
作者: nswcfd    時間: 2015-07-13 11:36
這篇貼子的改包邏輯modify(nf local-out hook)沒有修改dst,而是直接給skb->dev賦值(hard-code),SMAC和DMAC也是事先配置的,直接調(diào)用dev_queue_xmit發(fā)送,
跟正常流程相比,沒有走dst_output->ARP的邏輯。
PS,NF_STOLEN的返回值有點(diǎn)問題,舊的skb沒有free,引用泄漏了。(要么kfree_skb+NF_STOLEN,要么返回NF_STOP)

另一種方式cp_dev_xmit_tcp(DIY方式) ,根本就不是一個nf_hook,只是在模塊加載的時候構(gòu)造一個報(bào)文,直接利用dev_queue_xmit發(fā)送。
同樣,它的dev/SMAC/DMAC都是寫死的,它甚至都沒有dst,這也從側(cè)面證明了dev_queue_xmit根本不用dst。
作者: triplesheep    時間: 2015-10-10 23:11
好的,跪謝耐心的回復(fù)~~~回復(fù) 8# nswcfd


   




歡迎光臨 Chinaunix (http://www.72891.cn/) Powered by Discuz! X3.2