從一道題目開始說起
從一道題目開始說起
- 在閱讀下面的內容時，要求讀者對十進位制二進位制的轉換、子網劃分、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
自己
在做實驗、或請教別人之前，自己應該先分析和思考，下面是我的思考：
- B主機認為本身所處的網路是10.100.12.0/24，同時B主機認為A主機所在的網路是10.100.13.0/24，B認為A與自己不在一個網段，所以B主機想要與A主機通訊應該先詢問B主機所在網路的閘道器，得到閘道器的MAC之後，進行ICMP的的請求包封裝交給閘道器。
- 閘道器位於交換機的vlanif介面上，收到了B的ICMP請求報文之後，查看了ICMP的目標IP，根據路由表ICMP的請求包將轉發到交換機13口，ICMP的請求順利到達 A主機。
- 主機收到了閘道器轉發給它的資料幀，發現源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這種撥號場景當中，就無所謂了，反正本來就是想讓對方轉發。