一次詭異的ssh遠程時斷時續問題

一大早，公司砸開了鍋，紛紛說公司全部的服務器都出現登陸出現延遲。我連忙遠程了一下，用ssh -v debug了一下，發現遠程鏈接並未出現什麼問題。但登陸不到幾秒鐘，鼠標就不動了。這還了得，根本沒法幹活嘛！我陸續查了防火牆的負載，日誌，cpu,session等都未發現什麼異常。公司的遠程工具也設置了反空閒。

我繼續用ping,tracert工具發現到聯通的節點就沒法訪問。很顯然tracert沒到公司的防火牆地址就不行了。我初步判斷是機房的網絡有問題。與機房協調溝通，並沒有半點收穫。人家說他們網絡正常，其餘客戶都沒出現問題。從機房的流量監控看也沒發現流量異常。

我不得已親自去一趟機房，登上服務器一看，未出現任何問題，訪問外網也正常。ssh配置文件沒有問題。用機房的內網遠程訪問咱們的服務器，依舊是時斷時續。用了tcpdump抓包工具，發現一臺服務器的發出的udp包過多，我開啓了udp flood防禦功能，但並未出現改觀。

在機房用機房的內網遠程咱們的服務器也是時段時續。在機房tracert咱們的服務器和在公司同樣，機房這才答應和機房的網絡提供商聯通聯繫。過後機房也未認可是機房的網絡問題。隔幾天遠程居然奇蹟般的恢復正常。

究竟是哪裏出現了問題呢，真是一個詭異的故障經歷。雖然沒有搞清楚問題出在哪裏，記錄下來，以做參考，也但願高人們能提出意見，不甚感激。

過後兩個月，這篇文章有了下文。

詭異的狀況再次出現，從cacti監控圖能夠看見一臺服務器的網卡流量較高，登上這臺服務器，用iftop -n查看網卡流量發現有不少udp包，用lsof -i udp,發現發包的罪魁禍首是webservice,這是開發人員部署的一種分佈式服務，把服務的部署人員協商，中止了這個服務，幾分鐘之後，ssh卡頓現象瞬間消失。上次已經發現了udp包過多的問題，只是作了一些策略，並未中止服務。至於這個服務爲何會有那麼大的破壞力，我也不得而知。事情總算過去了，至此ssh詭異事件也劃上了句點。