在Kali平台上用ettercap做中間人欺騙時，發現arp欺騙後，受害者的機器無法打開網頁。停止arp欺騙後，受害者又能正常上網。起初我懷疑我沒有正确設定ettercap，于是我又換成cain&abel，得到同樣的結果。我猜想應該是路由器(Netgear-R800P)的防火牆在作祟。于是，我換了一個低配的路由器(MERCURY MW300)，同樣的操作步驟下，ettercap和cain&abel實施arp欺騙後都可以讓受害者的機器繼續上網。
原本到此就結束了，不過我比較好奇為什麼Arp欺騙失敗了？為此我用wireshark抓包分析了一番：
先介紹一下環境：受害者：IP 192.168.1.2/Mac e4:70:b8:c1:8a:63；中間人：IP 192.168.1.3/Mac 60:57:18:2f:c4:3e；Netgear路由器：IP 192.168.1.1/Mac a0:40:a0:83:44:2f。為了便于觀察，還需要對wireshark進行設定，添加"Time since first frame in this TCP stream"列，并對該列進行排序(具體步驟參考連結)。
下圖是進行Arp欺騙前，在受害者主機上捕獲到的通路Netgear路由管理頁面的資料包。雖然圖中沒有顯示所有資料包，但是根據握手/揮手包，可以确定受害者成功通路了路由管理頁面。
開啟Arp欺騙後，重複上述過程，得到下圖：
啊，真是滿目瘡痍！不少亂序,重傳,最後受害者還重置了連結。
起初，我以為RST包是路由器防火牆發起的。但是wireshark顯示該資料包的源頭是受害者，目的地是路由器，也就是說是受害者主動reset連結。但是，受害者的浏覽器基于什麼原因reset連結目前還是不清楚，還得往下分析。不過目前看來在受害者機器上可能無法發掘出有用的資訊了，是以，我把重點轉移到分析路由器的資料包上(由于開啟了雙向Arp欺騙，在中間人的機器上可以收到受害者和路由器的通信，是以，我并沒有用端口鏡像的方法分析路由器資料流)。
下圖是路由器上的資料包：
感覺除了滿目瘡痍，其通信量好像比在受害者機器上捕獲的數量多很多。這很正常，畢竟受害者要先通過路由把資料傳給中間人，然後再由中間人把同樣的資料傳給路由。以最後兩個RST包為例，初看以為是受害者發送了2次RST包----wireshark都是從192.168.1.2發出的----但回憶之前在受害者機器上捕獲的資料包，受害者隻發送一次RST包，是以，可以大膽的斷言其中一個是由中間人發送的。而且根據時間先後關系，可以斷定302#包是受害者原始發送的，而303#包是中間人轉發的。下面我來驗證這個斷言：
#302資料包的鍊路層的源MAC/目的MAC顯示從受害者到中間人。
#303資料包的鍊路層的源MAC/目的MAC顯示從中間人到路由器。看來前面猜想的沒錯，先記下，後面馬上會用上。
接着，我們來仔細看下Packet List面闆中的資訊。其中不少包後面跟着類似[TCP Dup ACK 25#N]的摘要資訊。[TCP dup ack M#N]中M表示丢失的包的序号，N表示第幾次丢失。這麼說#25包發生了多次丢失。我們回頭看看#25包是啥：
恩，從受害者發送給中間人的TCP握手包！這個包丢失了，浏覽器雖然努力嘗試重建立立連結，但是一直被防火牆阻擋了，是以TCP連結一直沒有成功建立，最後浏覽器也放棄了嘗試，導緻受害者機器不能上網！怪不得了。另外，結合前面說到的Arp欺騙的猜測，再仔細看"Packet List"裡的包，在TCP握手階段，受害者的Sync包和路由器的Sync/Ack包都是成對出現的，唯獨受害者的Ack隻出現一次，這對于定位問題有點幫助~