iptables防火墻非常的強大了，下面來介紹一個基于iptables功能來實現(xiàn) 劫持并攔截DNS查詢53端口實現(xiàn)轉向跳轉的例子，希望例子可以幫助到大家哦。

企業(yè)內網中經常會有這樣的需求，比如說業(yè)務服務器的IP地址為192.168.6.25，大家也就習慣于訪問這個地址了，運維也很厚道的將某個域名解析到這個IP地址，這樣大家也就不必記住繁瑣的IP地址，同時運維也很方便的將業(yè)務服務器由192.168.6.25的主機遷移到192.168.6.26的主機而無需通知客戶端更改地址，這也是域名發(fā)揮的作用，好了，現(xiàn)在問題來了:-)

客戶說我們企業(yè)很小，不想另外購買域名，好吧，每年五十幾塊也是一筆費用，而且購買域名后還需要有人維護，比如要記得續(xù)費什么的，略麻煩。同樣的還覺得將內網地址公布到外網上不是安全的行為。

經過我的詢問得知該企業(yè)擁有一臺自建的DNS服務器，為全網提供DNS查詢，那這事情就好辦多了，對DNS服務器軟件硬綁定指定的域名到IP地址的記錄（由于是我們自己的DNS服務器，這里的域名可以任意設置，當然最好設置為公網上沒有的域名地址以避免沖突）。

對于DNSMASQ，直接在/etc/dnsmasq.d路徑下建立一個conf文件，比如server.conf，內容如下:

address=/business.server/192.168.6.25

這里business.server為我們任意設置的域名，而192.168.6.25為指向的IP地址,由于這里局域網上網的路由DHCP自動分配DNS服務器為我們的內網服務器，所以對于自動獲取IP和DNS的客戶端則不需要我們多操心，但是問題遠遠沒有解決，如果有人自己指派了DNS服務器呢？

好吧，運維人員可不希望一個一個去通知用戶修改DNS服務器為指定的內網服務器，但是通過強大的iptables我們可以神不知鬼不覺地劫持用戶的所有DNS查詢。

當然這里的iptables是在路由上設置的(這里局域網的路由是一臺小型的服務器，運行著Linux系統(tǒng)),眾所周知，DNS使用53端口,并通過TCP或者UDP協(xié)議傳輸,那么我們就需要劫持這兩個協(xié)議傳輸通過53端口的查詢流量到我們指派的DNS服務器上,代碼如下:

1. iptables -t nat -A PREROUTING -i ethX -p udp --dport 53 -j DNAT --to $(get lan_ipaddr) 
2. iptables -t nat -A PREROUTING -i ethX -p tcp --dport 53 -j DNAT --to $(get lan_ipaddr) 

這里ethX為局域網的LAN口,而$(get lan_ipaddr)指示的是我們自己的DNS服務器(一般在內網),比如我們的LAN口為eth1,而DNS服務器位于192.168.6.10,則上述規(guī)則更改為:

1. iptables -t nat -A PREROUTING -i eth1 -p udp --dport 53 -j DNAT --to 192.168.6.10 
2. iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 53 -j DNAT --to 192.168.6.10  //Vevb.com 

好了,到這里我要介紹的也就完了,但是這種辦法有個前提是在局域網內,所有的流量必須走路由器,也就是這個路由器為網關型路由(所有流量進出口),否則此辦法無效,但對于特殊情況可以考慮采取類似的DNS投毒方式進行,我也沒試過,這邊也不介紹了,這種方法還有問題,應用上述防火墻規(guī)則會導致所有發(fā)往53端口的udp或者tcp數(shù)據(jù)流量被截獲,如果某外網服務器53端口做其他用處則會異常,同時在一定程度上也加重了自建DNS服務器的負擔,如果自建服務器崩潰,則所有的DNS解析將會失效.

當然,我今天講的這個技巧還有一個應用場景,比如在網絡環(huán)境比較惡劣的情況下,DNS被攻擊或者遭到投毒,自建服務器可以通過多種手段避免這些安全問題,這樣為了局域網安全,轉移DNS查詢流量則是必須的了.