端口telnet不通排查過程
現狀
簡單描述下最近在做啥，我手里維護的一些系統的線上服務器，還在使用centos7，7.3/7.6/7.9都有，運維側選定的替換系統是openEuler20.03-LTS-SP1。按理說，運維直接在線上升級系統就完了，但是，由于風險太大了（直接升級后可能導致應用異常），就還是需要研發出遷移方案、測試組進行測試后，比較保險。
于是，我就在本地虛擬機virtualbox先來折騰試試，先搭了個centos 7.3的系統，部署了個應用，監聽端口9900，結果怎么都訪問不了。
下面記錄下排查過程。
應用介紹
我們這個服務器是centos7.3，上面的應用也比較老，是一種java servlet容器：resin，和tomcat類似，對外提供http接口。
配置監聽端口的地方如下：
程序啟動后，我看端口是在監聽的：
我本機curl試了下，可以訪問：
[root@node7 my168_web]# curl localhost:9900
<html>
<body>
<h2>Hello World!</h2>
</body>
</html>
我這個虛擬機的端口9900，需要暴露到windows宿主機進行訪問，配置了下端口映射：
然后，通過瀏覽器訪問localhost:19900，發現失敗：
排查過程
懷疑ipv6
我在虛擬機上，開了tcpdump，發現可以收到syn握手：
tcpdump -i any tcp port 9900 -Ann
我在虛擬機，又試了下：
[root@node7 my168_web]# curl localhost:9900
<html>
<body>
<h2>Hello World!</h2>
</body>
</html>
發現抓包如下：
此時，就看到通過localhost訪問時，用的ipv6的地址，此時，開始懷疑是不是9900端口，僅監聽了ipv6導致的。
下面這個輸出，強化了我的猜測：
我又看了下其他環境，發現：
如果這個環境里，只有ipv4地址，netstat的輸出就不一樣
另外一套環境，有ipv6地址，netstat輸出就是inet6啥的。
嘗試修改配置文件，監聽ipv4
把配置改成了下面這樣：
<http address="0.0.0.0" port="9900"/>
重啟后，netstat結果發現輸出沒啥變化：
[root@node7 my168_web]# netstat -nltp|grep 9900
tcp6 0 0 :::9900 :::* LISTEN 11992/java
此時，在網上問大模型，大模型提到：
大模型建議實際測試下，看看到底是否支持ipv4：
測了之后，發現確實可以，那就說明對ipv4的支持沒問題：
嘗試從其他虛擬機telnet該端口
我找了另一臺同網段的機器10.0.2.8：
[root@node-4 yum.repos.d]# telnet 10.0.2.12 9900
Trying 10.0.2.12...
telnet: connect to address 10.0.2.12: No route to host
很奇怪的是，你說no route我可以理解，就是找不到目標主機的路由項嘛，但是，我在目標主機開了抓包的，發現telnet的時候，能收到syn包：
而且，抓包到wireshark看的時候，發現mac地址也是正確的：
下圖附兩臺機器的mac地址：
我于是在發起端的機器，查看下路由表：
發現路由表沒錯。
安裝了個traceroute，發現就一跳，然后看看arp，發現這個ip對應的mac地址也是對的。
此時，又去網上查了下，開始懷疑到了防火墻的身上。
防火墻排查
找了下centos7.3中對應的防火墻相關命令：
https://www.ctyun.cn/zhishi/p-330299
發現目標服務器上，防火墻真的開著的：
查了下，9900端口是否開放，發現沒開放：
[root@node7 my168_web]# firewall-cmd --query-port=9900/tcp
no
9900加入開放：
firewall-cmd --permanent --add-port=9900/tcp
firewall-cmd --reload
[root@node7 my168_web]# firewall-cmd --permanent --add-port=9900/tcp
success
[root@node7 my168_web]# firewall-cmd --reload
success
[root@node7 my168_web]# firewall-cmd --query-port=9900/tcp
yes
然后再試試，果然就好了：
總結
這個centos7.3是新裝的虛擬機，忘了防火墻會自動開啟這回事了。
由于對netstat的輸出也是半桶水，導致走了彎路，好歹最后還是找到了正確的路。
浙公網安備 33010602011771號