寄送郵件的封包被防火牆檔掉

記錄一個困擾很久(半年以上),最終由網管人員解決的問題:
應用程式利用 .NET 類別來發送郵件,大多時候沒有問題,可是偶爾使用者會反應沒收到信件。從應用程式的 log 發現 exception 訊息為:遠端伺服器已經中斷連線。

這種偶爾出現(約一兩個月才出現一次)的問題最讓人頭痛,因為開發人員比較不容易抓到問題的真正原因,一開始大都只能用猜的,例如:可能是網路瞬斷所造成。同時,沒有明確的證據,可能也不知道如何請網管人員協助查看是哪一段網路傳輸的部分可能有問題。

由於我對防火牆、路由器等網路設備相關知識不熟悉,郵件伺服器也不在我的管轄範圍,因此只能先以程式設計的角度嘗試找出問題發生的原因。經過反覆的測試,發現同一份 HTML 格式的郵件,如果將內文加入一些 Enter 鍵斷行,原本寄送失敗的信件就可以寄送成功了。我第一次碰到這種情況,實在太詭異了。

此外,同樣的測試郵件內容,在機房裡面的應用程式會寄送失敗,在我的機器上卻能發送成功。由於我的機器與機房裡的機器的主要差別就在防火牆設備,於是將這兩條線索提供給網管人員。

經網管人員查看網路傳輸的 log 和防火牆設定之後,發現是被 CISCO 防火牆設備的 ESMTP 檔掉了。也就是說,當欲發送的 HTML 郵件含有特定 pattern 的字串時,CISCO 防火牆會認為那是不安全的封包而將它檔掉。

以下是網管提供的 log (實際的 IP 位址已改掉):

2009-04-10 14:20:02 Local4.Info 123.45.67.100 %ASA-6-302014: Teardown TCP connection 3734887 for outside:123.45.2.64/25 to inside:123.45.67.152/3913 duration 0:00:00 bytes 1644 Flow closed by inspection
2009-04-10 14:20:02 Local4.Info 123.45.67.100 %ASA-6-106015: Deny TCP (no connection) from 123.45.67.152/3913 to 123.45.2.64/25 flags PSH ACK on interface inside
2009-04-10 14:20:02 Local4.Info 123.45.67.100 %ASA-6-106015: Deny TCP (no connection) from 123.45.67.152/3913 to 123.14.2.64/25 flags PSH ACK on interface inside
2009-04-10 14:20:02 Local4.Info 123.45.67.100 %ASA-6-106015: Deny TCP (no connection) from 123.45.2.64/25 to 123.45.67.152/3913 flags ACK on interface outside

網管把 CISCO 的 ESMTP 功能關閉之後,系統的發信功能就全都正常,再也沒發生同樣的問題了。底下是關閉 ESMTP 選項的操作畫面:


問題雖然獲得解決,但我還是不明白 CISCO 的 ESMTP 為什麼會把正常內容的信件檔下來。似乎該去上一點網路管理方面的課程了..... @[email protected]

4 則留言:

  1. 我覺得專業還是要分工,所以這類網管方面的事情還是交給他們去做,找bug速度絕對比你快得多,不然他們就都要失業了,呵呵~

    像我自己也懂得一些,但是因為術業有專攻,如果你跨到他們的地盤幫他們找問題,可能對方不會感激你還覺得你管太多(經驗談)。所以我都儘量裝作"猜測"可能是哪方面有問題而請他們幫忙。

    更重要的是developer沒有administrator的權限,最終你還是要依賴他們幫你修正... (除非你是developer + administrator,那就和我以前一樣慘)

    回覆刪除
  2. Kenny 兄所言極是。有時真的得用猜測、提醒的口吻與對方交涉。畢竟是請對方協助,總不能表現得一副自己知道更多的樣子。
    不過有時候我會碰到一種狀況,就是如果沒有拿出比較明確的證據,證明我已經排除掉所有應用程式方面的可能問題,得到的答案往往是:「網路都很正常啊,我們沒有停機。」有時候還得詳細解釋為什麼應用程式會出現這種問題,以及為什麼需要檢查網路封包的 log。
    我是一點點 developer 加一點點 admin 啦 :)

    回覆刪除
  3. 站在網管的角度,他們要接觸一大堆設備及設備軔體上新的功能,往往為了安全機制,會把選項勾起來,就會形成很嚴格的封包篩選。

    好的網管人才可以掌握安全與便利之間的平衡,糟糕的就會一竿子亂封亂擋。我本身是編程人員,因此在設定mail server的安全性時會對一些安全選項作出考量(依照法律的比例原則,不會以安全之名封掉人性的必要)。

    我們最終仍是要解決問題,沉穩的作法還是要舉出證明來幫助網管人員解決問題,兩造之間也是能其中得到回饋與信任。

    當然,若老是網管那邊出問題或規劃不佳,這時候就要講主管在會議上開炮了。不過,有些事情除非我們親力親為,否則仍是一個懸案。

    回覆刪除
  4. > 有些事情除非我們親力親為,否則仍是一個懸案。

    確實如此,得主動提出有力的證據才行啊!

    回覆刪除

技術提供:Blogger.