用wireshark分析網路
這兩天看了兩本有意思的書,ofollow,noindex" target="_blank">Wireshark網路分析就這麼簡單 、wireshark網路分析的藝術 。
之前工作中就常常用到這個軟體,好多時候總是感嘆這個軟體實在太NB了
,這本書作者也是個實戰派,採用種種案例展示瞭如何用Wireshark探索網路現象,實在是很迷人。
開篇有一個很有意思的小問題,我思考了一下,覺得很容易作為網路理解的小case用在課堂ABC上,記錄一下。
問題:兩臺伺服器A和B的網路配置如下
-
伺服器A:
- IP:192.168.26.129
- Mask: 255.255.255.0
- Gateway: 192.160.26.2
-
伺服器B:
- IP:192.168.26.3
- Mask: 255.255.255.224
- Gateway: 192.160.26.2
B的子網掩碼本應該是255.255.255.0,被不小心配成了255.255.255.224。它們還能正常通訊嗎?
哈哈,我就喜歡這樣簡單明快的問題。看似簡單,其實想想還是有點陷阱的。而且這種問題有個共同點,就是如果你不懂原理,也沒關係;喜歡瞎動手的童鞋一般都會去試試這種情況,所以能把答案碰出來
。我就見到過這種·自學成才·的老師,他們從來沒有在學校裡系統學過什麼TCP/IP或者老破舊的ISO 7層模型,照樣能對網路和路由配置如數家珍,他們的能力完全建立在實戰的基礎上。
讓我們好好分析一下這個問題。
首先B的子網掩碼配置決定了它和A不在一個子網上,我們在書本上學到的知識,如果兩臺機器不在一個子網上,能夠通訊嗎?
哈,如果死讀書不實踐的人肯定會說:不能通訊,不在一個子網嘛。
那麼我們照這個邏輯,公司裡豈不是不同子網的機器老死不相往來了?
看吧,這是第一個陷阱,兩臺機器跨子網能否通訊,取決於閘道器。
如果沒有閘道器伺服器,或者閘道器伺服器限制的話,肯定是不能通訊的,雖然A和B物理上處於同一個子網,但是這個時候可以看成有一道防火牆在兩臺機器之間。
其實大部分網路管理員都會把閘道器設定為不同子網間相互轉發的,不然一個公司各部門間的機器不能互訪,豈不是很悲劇。
那麼在閘道器能正常轉發的情況下,我們來腦補一下兩個場景,B訪問A,A訪問B的具體過程。
B Ping => A
- B首先檢查到A和它不在一個子網,這個時候它需要閘道器來轉發資料包
- B發一個閘道器IP的ARP請求
- 閘道器(192.168.26.2) 回覆B的ARP請求,告訴它俺的MAC 地址是XXX
- 有了閘道器的MAC,B就可以直接發包給網關了,它告訴閘道器,我要你幫我轉發包給A
- 如果閘道器沒有限制的話,它就會把包轉發給A
- A收到B的請求,他就會問,這個B是誰呀?A檢查一番,發現B和自己在一個子網
- 既然一個子網,那麼A就不會走網關了,它直接發出ARP請求在乙太網上廣播,誰是B呀,MAC地址回我一個
- B在物理上實際上是和A在一起的,所以直接響應A,俺的MAC地址是這個
- A收到B的ARP響應,就很HAPPY的跳過閘道器,直接給B響應包啦
- 這樣的結果就是B發給A的包需要走閘道器,A發給B的包直接廣播到乙太網上,由B直接接收
- 最終的效果就是B能和A正常通訊,雖然B的通訊繞了一點遠路
A Ping => B
這個過程其實跟上面一樣,A發出ARP請求直接找到了B,所以A發包給B是不用走閘道器的,B的響應還要走閘道器。
怎麼樣,這麼看看,是不是問題就很明晰了呢。大部分情況下(閘道器沒有特殊配置),A和B是能夠正常通訊的。
有點小得意的說,這個問題我很快就反應過來了;因為我和作者一樣是野路子出家,實戰瞎鼓搗過,所以這類小Case恰好是嘗過的菜。
咳咳,真是有點自吹自擂了;其實絕大多數網路問題最後找到原因都很簡單,但是當一個大型的網路裡面發生詭異的情況時,能迅速定位問題點是很不容易的。我又回想起來之前工作時,在一個客戶現場遇到的坑。
很久很久以前~~~
咳咳,其實也不是多久,但那個時候我已經工作挺長時間了,雖然沒有經過什麼系統理論培訓,但是靠著大量野路子實踐,我覺得也算是見過很多網路萬年坑了,我去客戶現場從來不怵頭,但就是那一次,差點陰溝裡翻船~~
我去國內的某家大型券商部署專案,那家券商真是壕啊,從伺服器到網路裝置都是定製的特別高階的一批貨,然後我熟門熟路的安裝好Centos7.1,他們的系統管理員按照內部規定,做了安全防護之後,我們從他們的頂層小機房轉移到操作辦公室,準備部署應用軟體。
這家券商的網路大部分已經遷移到SDN上面,辦公室的終端機器經過兩層跳板,跳到一個雲主機的shell上面,然後再遠端ssh連線到我們剛剛裝好的伺服器上,準備大展拳腳~~~~
根據故事的發展,這個時候就出現了詭異的事情,隨機過20~40分鐘後,我們的ssh連線就會卡一段時間,然後有機率斷掉,之前所有工作都是正常的,而且有時候能正常個1小時,但是最後總是會開始卡。
唉,網路卡死,網路時不時斷掉,真的是現場網路工程師人生中的一大悲劇,這類問題感覺天天遇見,但是總是沒有一個固定的套路去解決它。
我們的終端機經過了兩重跳板,然後ssh客戶端和伺服器之間,還有一個龐大的網路拓撲,跋山涉水十萬八千里才能相見,然後就被某個不知名的幽靈生生拆散了,想象他們艱難的會師路徑,我不禁打個冷顫。
肯定不能先去懷疑他們的會師歷程,我們先去查詢最簡單的,也是最容易出錯的部分,就是服務端的sshd配置
因為安裝完系統後,客戶的管理員根據他們的安全管理條例,運行了自己開發一個指令碼進行了系統加固,很自然的,我們懷疑這個指令碼是不是有什麼地方配置不對,導致問題
在對伺服器配置穩健和指令碼程式碼詳細檢查之後,我失望的判定,人家的指令碼沒問題
配置沒有問題,那就看看是不是ssh終端軟體有問題呢
我反覆使用ssh登陸不同的伺服器,驚奇的發現,凡是登陸我們剛安裝好的這批伺服器,就會時不時斷掉,其它伺服器就沒有問題; 但是悲劇的是我們的伺服器所在的機房,沒有其它測試機,所以只能證明ssh終端軟體沒問題
不到萬不得已,我是不想懷疑中間龐大的網路路徑的,誰知道是不是什麼抽風的防火牆規則呢
我抱著筆記本,跑到樓上伺服器的小機房直聯看看,發現直聯好得很
現在說起來簡單,其實跑一趟機房需要審批、內部人員帶路一堆手續,累的客戶跟我上上下下,驗證一次需要1個小時以上,而且重現時間是隨機的,這就是一線人員苦逼的地方啊。
看起來一切都導向那個我最不願意看到的結果,好像是通訊中間有個什麼詭異的防火牆規則之類的~~,但是這麼龐大的網路拓撲,怎麼定位問題呢?
到了此時,客戶不再糾結於安全管理條例,我們小心翼翼的祭出了·抓包·這個手段
-
不到萬不得已,其實大家都不想抓包的;金融行業的客戶群,重視安全問題甚於生命,所以能在生產環境中讓你抓包,其實已經是皇恩浩蕩了。
-
經過了幾十分鐘苦苦等待,終於問題又重現了,我們小心翼翼的把抓到的包存到本地,用wireshark開啟,像欣賞小電影一樣仔仔細細~~~
-
果然有問題,那臺伺服器的ARP響應包裡面,MAC地址竟然會變!
-
奇哉怪哉,我們剛配好這臺伺服器,怎麼就讓人ARP欺騙了呢?而且如果是他們的網路裡面有ARP病毒,為啥就只找我們的伺服器呢?
當時已經從早上折騰到下午3點種左右,雖然有了重大發現,但是也有了更大的迷惑
突然我靈光一閃,伺服器接了兩根網線,一根是管理口為了方便管理,這個一直沒有動過,會不會是~~~
我立馬報著筆記本和一臺小交換機跑上樓去
將伺服器和筆記本通過一臺小交換機聯到一個小區域網絡中,再抓包發現了真相
這臺定製的伺服器是浪潮提供的,而浪潮的管理口有個奇怪的設定,它和伺服器上的多個網絡卡被繫結成一個NIC Teaming,型別為Transmit Load Balancing(TLB)。TLB的特點就是收包工作只由一個網絡卡負責,發包工作則分攤給所有網絡卡,但是管理口的預設配置有問題,有時候莫名其妙會共享同一個IP,迴應ARP請求的時候把自己的MAC地址發回去,但是系統中管理口是沒有配置的,所以這臺伺服器莫名其妙就自己變成了一臺ARP欺騙源。
問題定位了,我們打電話找浪潮的供應商;供應商也非常奇怪,表明是第一次碰到這種問題,可能是由於定製的機器,考慮不周導致的。
然後我們的解決方法就是,將筆記本直聯伺服器,在筆記本上執行一個DHCP 服務,這樣管理口在開機的時候會被分配一個IP地址,我們再通過這個IP地址登陸伺服器管理介面,配置一個靜態IP,就OK了。
雖然最後是一個簡單至極的ARP欺騙問題,但是發生在一個龐大的網路拓撲中,除錯手段被限制,發生時間隨機,樓上物理距離和安全條例導致你重現一次成本極為高昂,你還能·鎮定自若,指揮談笑間·嗎,這是一次一波三折的排障經歷啊。
我這麼詳細的回憶一次折騰的排障經歷,是因為我在這本書裡發現了作者和我一摸一樣的苦逼例子,在<wireshark網路分析的藝術>這本書裡,大家有興趣可以自己去翻翻。
其實這兩本書真可謂是作者的網路排障手記,因為我也有那麼一段跑在一線的日子,讀起來格外親切。這就是一線工程師的日常啊。
曾經,我以為熟讀<TCP/IP詳解>和<Unix網路程式設計>就能成為無所不能的網路大拿;曾經,我以為獨立實現一個網路協議棧就是開創天地的神邸;後來,我明白了,網路的海洋無窮無盡,雖然規則是死的,但是現實世界實在不可預測,也許下一分鐘就會有一個匪夷所思的case來糾纏你,嘲笑你的妄自尊大。
在網路世界邁入SDN之際,我非常惶恐,因為我明白以我的智商,不可能成為什麼·專家·了;我想,未來,可能只有在AWS或者Google Cloud浸淫數十年的人,才能小心翼翼的稱自己為·真專家·;面對網路知識的變幻莫測,總有一種·生有涯,知無涯·的惶恐;我總是會感嘆,網路這個東西實在是太神奇了,真不知道如何形容這份感覺,就是隻有·神奇·來形容