從一道題目開始提及

 

目錄

• 從一道題目開始提及
  • 從一道題目開始提及
  • 本身
  • 疑惑與荒誕
  • 真實一點
    • A老師
    • B老師
    • C老師
  • 到底誰說的是對的？
  • 意外收穫
  • 補充一點
  • 再補充一點

 

從一道題目開始提及

• 在閱讀下面的內容時，要求讀者對十進制二進制的轉換、子網劃分、arp協議、三層交換機比較瞭解，這部份內容屬於通訊的基礎知識，在下文當中會直接帶過，不作分析。
• 寫這一篇可太費勁了，模擬實驗作了五六次;

從一道題目開始提及

B主機pingA主機能ping通嗎？不管通或者不通，請說明通訊流程。

交換機配置至關簡單，以下所示，除此以外無它。

vlan 12
vlan 13

int vlan 12
	ip add 10.100.12.1 24
int vlan 13
	ip add 10.100.13.1 24

int g1/0/13
	port link-type access
	port access vlan 13
int g1/0/12
	port link-type access
	port access vlan 12

本身

在作實驗、或請教別人以前，本身應該先分析和思考，下面是個人思考：

1. B主機認爲自己所處的網絡是10.100.12.0/24，同時B主機認爲A主機所在的網絡是10.100.13.0/24，B認爲A與本身不在一個網段，因此B主機想要與A主機通訊應該先詢問B主機所在網絡的網關，獲得網關的MAC以後，進行ICMP的的請求包封裝交給網關。
2. 網關位於交換機的vlanif接口上，收到了B的ICMP請求報文以後，查看了ICMP的目標IP，根據路由表ICMP的請求包將轉發到交換機13口，ICMP的請求順利到達 A主機。
3. 主機收到了網關轉發給它的數據幀，發現源IP是10.100.12.231，運算後發現與本身所處在同一個網段，因而arp廣播B主機的MAC地址，但vlan13裏面，只有A主機和它的網關，並無其它主機，網關又隔絕廣播，arp的廣播請求沒法到達B主機 ，A主機由於沒法獲得B主機的MAC地址，因此也就沒法封裝ICMP的回覆報文，因此主機B與主機A通訊是不通的。

疑惑與荒誕

後面開始驗證本身的想法，我打開ensp模擬了這個實驗，經過屢次抓包發現當交換機將B主機的ICMP請求交給A以後，A主機居然直接將回復包交給網關轉發了，B主機由於收到A主機 的回覆因此顯示是可以通訊的！

• 個人分析是錯誤的嗎？有可能，我拿捏不許；
• ENSP出了問題？也有可能，由於ENSP這種垃圾軟件出現這種問題也不奇怪。

在此處展現我在ENSP作的拓撲：

用PC2 PING PC1 在通的前提下，在PC1上抓包，以下圖所示：

經過上圖咱們看到PC2發給PC1的請求包是網關轉發的，回覆包居然也是網關轉發的，這和咱們分析的那種狀況不符。

將ENSP與vmware workstation結合一下,但願再貼近一下真實環境：

這樣環境比較真實，至少PC是真的，用10.100.12.231 PING 10.100.13.178 不通，在這種狀況下，在10.100.13.178上抓包：

在10.100.12.231上抓包，看下，以下圖所示：

經過上面這種方式，卻是驗證個人分析，可是有一點奇怪，那就是兩個vlanif接口的MAC居然一致，這與真的交換機仍是不太同樣，真正的交換機兩個vlanif接口的MAC不可能同樣，模擬器果真仍是差點意思，並不能百分百貼近真實的環境。

怎麼辦？我想到我有幾位大牛老師的聯繫方式，這幾位老師都是高手，在IT圈子裏面是有名號的，好多人都認識的，下面我會貼一下聊天記錄。值得一提的是，當我在某個IE培訓機構的羣裏面向老師提問時，老師言語中透露出個人基本功不夠紮實，我沒有反駁，也沒有在乎，可能真的是我錯了。

真實一點

幸虧我是在企業環境當中，手邊有華三在的S5560和峯火的三層交換機。找了兩臺筆記本、找到了一臺宇視的三層交換機和一臺華三S5560三層交換機，我作了一個真實的實驗，仍是在B PING A的時候，在A主機上抓包。

仍是上面這個環境。

A的MAC是：70b5:e898:7af6

B的MAC是：F8B1-56AB-419A

vlan13的接口MAC是：5c:a7:21:0c:7a:c3

vlan12的接口MAC是：5c:a7:21:0c:7a:c2

而後在B主機上抓包看下：

先用宇視的三層交換機，而後再用華三交換機，主機B與主機A都是不通，抓到分析後發現與我所說的結論同樣，我震驚了，這麼一番折騰，最終發現我是對的！

同時我還發現了一位知名老師老師寫的關於計算機網絡原理的書裏面錯誤的地方，他們大牛的形象在我心中坍塌了，同時內心的名言警句來我心中浮現，什麼盡信書不如無書，紙上得來終覺淺，都好有道理呀！同時我也發現了林沛滿的《wireshark網絡分析就是這麼簡單》一書是基於真實環境編寫的，並非在模擬器上編寫的，很是真實可靠，做者水平至關之高，你們能夠放心閱讀。

上述我詢問的這些講師，有講課10多年經驗的，也有就在大學裏面任教的，有兩位老師在回答的時候都是答非所問，只有一位老師尊重事實，但也僅限於根據模擬環境的當中的答案當中推導理論，自圓其說。緣由其實有不少了，老師們多是由於太忙了，給學生答疑成了例行工做，作麻木了，無論怎樣吧，反正最後還得靠咱們本身，在這些大牛都在「矇蔽」你的時候，要勇敢，勇敢的挑戰本身、勇敢的挑戰別人，若是最終結果發現是本身錯誤的，那也要勇敢的修正的本身知識體系。

下面讓咱們看看這些老師的回答；

A老師

我認爲我已經把問題說的夠清楚，但仍然感受溝通上有障礙，以爲A老師是答非所問，反正我是啥都沒聽懂。哎，QQ溝通原本就是有這種闡述不明的感受。

B老師

一樣的問題，我又問了B老師，下面就是B老師給個人答案，怎麼說呢？不作評價，我是失望 的，我沒有有看懂，哎~

C老師

C老師不愧是有經驗的老師，並無輕易回答我，而讓本身在ENSP作實驗驗證，而後C老師給了以下的解釋，我和這位老師是電話溝通的，就沒有截圖了，C老師經過作實驗抓到獲得結果，而後經過抓到結果推理原理給我講，A主機收到B主機的ICMP請求報文以後，就原路返回了！抱歉，這種解釋我不能接受……

到底誰說的是對的？

我先說結果，是我分析的結論是對的，最終這老師們不得不認可。

意外收穫

第一點

當咱們的windows電腦配置完ip、掩碼、網關以後，即便什麼也不作，在開機狀態下，網卡會向外發送arp廣播，詢問網關的mac是多少，其實這沒有什麼，當把這個發現放到上述場景當中就有意思了。當交換機收到B的icmp的請求包以後，在轉發給A主機之際，A主機所在的網關會不會arp請求A的MAC地址呢？我屢次抓包都沒看到，緣由是由於當A主機配置完IP、掩碼、網關以後，立馬就會發送一個詢問網關的arp廣播，而後網關會迴應，這一回應不只僅會意味着A主機會獲得網關的MAC，也意味着網關所在的交換機也會獲得A主機的MAC。在這種狀況下之下，當B主機所在的vlan網關獲得B發往A主機的ICMP請求報文時，就不會再arp廣播A主機的MAC地址了，就會直接封裝。

再延伸一點，若是咱們在一個設備不上配置網關，僅配置IP和掩碼，這樣當開機的時候，也會發送一個arp廣播，詢問是否有使用它當前使用的地址，咱們能夠利用這點，在某些不方便接外設的設備開機時，就在它的網口上等着抓arp包，其實就能看到他的IP地址，獲取了設備的IP地址以後在鏈接它就簡單了。

第二點

從這個實驗當中獲得最重要的結論是雖然A主機已經收到網關轉發給它的B主機發送的ICMP請求報文，但A主機仍然會堅持對源IP地址進行判斷，判斷是否與其是一個網段，若是判斷是一個網段，A主機無論請求報文是怎麼來的，A主機依然會arp廣播請求目標主機的MAC，主機會獨立判斷，這是很是重要的一點。其實我想說並非這個，我想說的是有沒有哪些地方是不須要判斷，就本能發送的？這讓我聯繫到二層的arp，arp無論對方是誰，只要是有人問，那我就會迴應，這樣的理解若是放到下面這個場景當中，就有點意思了。

兩臺主機都在一個廣播域之下，而且真的有網關，正常狀況下，主機能與網關通訊。

A主機：192.168.0.10/24 網關是192.168.0.1

B主機： 192.168.0.130/27 網關也是192.168.0.1

仍是說一下，B能不能ping通A？

B對A的icmp請求報文仍是要給網關，網關也會轉發給A，那A這時候認爲B和本身是一個網段，這時候會發arp請求廣播，B會收到，那B這時候會不會迴應？B在回覆A發送的arp廣播時會不會考慮到A和本身不在一個網段，從回覆包交給網關或者丟棄掉呢？實際上是不會的，B在回覆arp請求的時候並不會作判斷，這一點要和上面作一個區分。

補充一點

當咱們分析完上面這種比較複雜的題目時，再來看下面這道題，就發現很是簡單了。

其實我一眼就能看出來這道題出自哪裏，這道題應該是出自林沛滿寫的《wireshark網絡分析就是這麼簡單》一書，就只把IP地址的第三個部分給改了，原書中是26，這裏改爲了242。

A：192.168.242.129/24 192.168.242.2
B：192.168.242.26/27 192.168.242.2

B到A的話，B會將請求交給網關，而後網關將給A，A直接廣播B的MAC，B會忽略arp的子網判斷，B會迴應A的arp請求，A如願獲得B的mac，成功回覆ICMP的回覆報文，通的。

A到B的話，A廣播B的MAC，如願收到以後，A的ICMP的請求順利到達B，B怎麼回覆呢？B會將icmp的回覆包交給網關，而後網關再給A，通的。

再補充一點

如上所示，掩碼有點奇怪，顯示撥號成功了，這個掩碼就是把這個IP掩死的意思，我在ACL的時候會用到，可是這種撥號場合我也是第一次見。

那麼問題來了，這麼設置能正常通訊嗎？先來分析一下。

掩碼的做用就是作與運算的，若是這臺設備ping 223.6.6.6通訊的話，本機會把10.108.176.145這一整個當作網絡位，與對方不在同一個網絡當中，那下一步天然要交給網關，嗯，這和掩碼是24的時候轉發路徑是相同的。

window7會提示一個警告，其實能夠強行設置，在centos7系統若是將掩碼設置爲32的話，重啓網卡以後，一點都不會報錯，並且與外界通訊正常。

若是一個主機將掩碼設置32位的話，通訊就會變成了樣，主機根本不會區分目標主機是是否和本身一個網絡位，由於在它看來，除了本身，因此的地址都和本身不是一個網絡位，會將發往除了本身以外的的IP的數據包全都交給網關。

那問題來了，在主機看來網關也和它不是一個網段，主機跟不是一個網段的主機通訊時要交給網關，但網關跟主機就是一個網段，問題自己成了問題，怎麼搞？其實像windows和linux這種成熟的系統，早就想到了這種狀況，我抓包看了一下，也搞一個環境。

A：192.168.80.2/32 192.168.80.1

B：192.168.80.208/24 192.168.80.1

A主機ping B主機？怎麼通訊？

先說結論，是能通的，主機將ICMP請求數據包交給網關，而後B主機不經過網關，B主要認爲A和它一個網段，因此A直接扔了過來。

其實當A主機配置完網關的時候，A主機是無論網關和本身是否是在一個網段，A主機這時候不會作判斷，直接就廣播網關的mac，當問題本地成爲問題，這就是一個很是好的解決方案。

若是在主機上這麼設置掩碼，實在是犯不上，爲何的呢？有點脫了褲子放屁的感受，本地局域網通訊都不須要讓網關參與，但這種方式若是配置在ppoe這種撥號場景當中，就無所謂了，反正原本就是想讓對方轉發。