伺服器沒有從 LAN 外部響應
我有一個執行 Apache 的 Ubuntu Server 14.04,它位於企業防火牆後面。這在上個月一直執行良好,但現在伺服器沒有響應來自 LAN 外部的請求(由防火牆完成埠轉發)。現在我最初的想法是認為 apache 上出現了問題,但是當我嘗試使用內部地址(192.168.8.10)訪問伺服器時,一切正常。當我嘗試從本地網路遠端登錄時:
$ telnet 192.168.8.10 80 Trying 192.168.8.10... Connected to 192.168.8.10. Escape character is '^]'.
伺服器上的 Netstat 給我以下輸出:
$netstat -n -c | grep "192.168.8.19:80" tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV
當我
http://192.168.8.10
在瀏覽器中訪問時,netstat 會產生:$netstat -n -c | grep "192.168.8.19:80" tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 FIN_WAIT2 tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 FIN_WAIT2 tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 FIN_WAIT2
現在,當我從 LAN 外部嘗試此操作時,telnet 無法連接,瀏覽器只是超時。
$ telnet 78.xx.xx.245 80 Trying 78.xx.xx.245...
這只是無限期掛起,但 netstat 仍會確認
SYN_RECV
數據包。$ netstat -n -c | grep "192.168.8.19:80" tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV
瀏覽器測試不會在 netstat 中產生任何輸出。
這讓我認為問題出在防火牆上的埠轉發上。但是,當我嘗試將埠 80 轉發到 Windows 伺服器時,它工作得非常好。當我將埠 80 更改為轉發回 Ubuntu 伺服器時,同樣的問題。telnet 測試實際上通過防火牆到達伺服器這一事實向我表明防火牆不是問題。
我的 IT 部門告訴我,最近幾天防火牆的配置沒有更改,我也沒有對伺服器進行任何更改。事實上,嘗試將埠 80 轉發到另一台執行 apache 的 Ubuntu 桌面機器會產生相同的結果(儘管有 netstat 輸出,但瀏覽器掛起並且 telnet 未連接)。
其他埠成功轉發到防火牆後面的 Windows 伺服器(轉發到 Windows 伺服器時 80 工作)所以我認為問題不在於 ISP。這似乎只是 Ubuntu 的一個問題。
有沒有人知道這可能是什麼,因為它現在對我們來說是一個主要問題?
當主機可以與 LAN 通信但不能與 LAN 外部通信時,最可能要查找的錯誤配置是不正確的網關 IP 地址。
如果網關配置錯誤的主機是 TCP 連接的伺服器端,則症狀將是接收並接受 SYN 數據包,但由於沒有正確的網關地址而無法傳遞 SYN-ACK 數據包。這與您的問題中描述的症狀一致。
一個糟糕的解決方法是在網關處對傳入連接的源 IP 進行 NAT,這似乎是您的 IT 部門所做的。這不是一個好主意,因為您在日誌文件中失去了客戶端 IP 地址,並且可能會引入額外的連接跟踪。然而,它似乎工作得很好,因為伺服器不再將數據包發送到客戶端 IP 地址,而是發送到網關 IP 地址,因為它位於直接連接的網段上,因此不依賴於錯誤配置的預設網關。
在這種情況下,正確的解決方法是在伺服器上配置正確的網關 IP 地址並恢復在防火牆上應用的解決方法。
如果您的 Ubuntu 伺服器配置了靜態 IP 地址,則 IP 地址和網關地址都在
/etc/network/interfaces
. 更改該文件將在下次重新啟動時生效。