无法启用web服务(网络问题排查-Web应用页面无法访问)

部署在服务器上的Web应用因为机房迁移,导致PC上无法正常访问Web页面,下面我们就来说一说关于无法启用web服务?我们一起去了解并探讨一下这个问题吧!

无法启用web服务(网络问题排查-Web应用页面无法访问)

无法启用web服务

问题背景

部署在服务器上的Web应用因为机房迁移,导致PC上无法正常访问Web页面。

原因分析

本次遇到的问题纯属网络层面问题,不用多想,先登录到服务器上,查看服务端口的监听状态:

[root@node2]# netstat -anp|grep 443 tcp6 0 0 :::443 :::* LISTEN 8450/java

在服务器所在节点、服务器之前的其他节点上curl监听端口看看是否有响应:

[root@node2]# curl -i -k https://192.168.10.10:443 HTTP/1.1 302 Found Location: https://127.0.0.1:443 Content-Length: 0 [root@node2]# curl -i -k https://192.168.10.11:443 HTTP/1.1 302 Found Location: https://192.168.10.11:443 Content-Length: 0

到此为止,说明Web服务运行正常,问题出在了PC到服务器这个通信过程。本地wireshark抓包看看,相关异常报文如下:

371 70.961626 3.2.253.177 172.30.31.151 TCP 66 52541 → 443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 373 70.962516 172.30.31.151 3.2.253.177 TCP 66 443 → 52541 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128 375 70.962563 3.2.253.177 172.30.31.151 TCP 54 52541 → 443 [ACK] Seq=1 Ack=1 Win=65700 Len=0 377 70.963248 3.2.253.177 172.30.31.151 TLSv1.2 571 Client Hello 379 70.964323 172.30.31.151 3.2.253.177 TCP 60 443 → 52541 [ACK] Seq=1 Ack=518 Win=30336 Len=0 381 70.965327 172.30.31.151 3.2.253.177 TLSv1.2 144 Server Hello 383 70.965327 172.30.31.151 3.2.253.177 TLSv1.2 105 Change Cipher Spec, Encrypted Handshake Message 385 70.965364 3.2.253.177 172.30.31.151 TCP 54 52541 → 443 [ACK] Seq=518 Ack=142 Win=65556 Len=0 387 70.967194 3.2.253.177 172.30.31.151 TLSv1.2 61 Alert (Level: Fatal, Description: Certificate Unknown) 388 70.967233 3.2.253.177 172.30.31.151 TCP 54 52541 → 443 [FIN, ACK] Seq=525 Ack=142 Win=65556 Len=0 391 70.968320 172.30.31.151 3.2.253.177 TLSv1.2 85 Encrypted Alert 392 70.968321 172.30.31.151 3.2.253.177 TCP 60 443 → 52541 [FIN, ACK] Seq=173 Ack=526 Win=30336 Len=0 394 70.968356 3.2.253.177 172.30.31.151 TCP 54 52541 → 443 [RST, ACK] Seq=526 Ack=173 Win=0 Len=0 395 70.968370 3.2.253.177 172.30.31.151 TCP 54 52541 → 443 [RST] Seq=526 Win=0 Len=0

关键是最后两个,可以看出报文存在复位标志RST。与提供环境的人了解到PC与服务器之间使用的交换机是通过GRE隧道打通的网络,基本怀疑是交换机配置存在问题;

同时观察到PC访问集群的ftp也存在异常,说明是一个通用问题,而PC上ping和ssh服务器都没有问题,说明是配置导致的部分协议的连接问题;

后来提供环境的人排查交换机配置,发现GRE隧道的默认MTU为1464,而集群网卡上的MTU为1500,最后协商出的MSS为1460(见抓包中的前两个报文):

[leaf11]dis interface Tunnel Tunnel0 Current state: UP Line protocol state: UP Description: Tunnel0 Interface Bandwidth: 64 kbps Maximum transmission unit: 1464 Internet protocol processing: Disabled Last clearing of counters: Never Tunnel source 3.1.1.11, destination 2.1.1.222 Tunnel protocol/transport UDP_VXLAN/IP Last 300 seconds input rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec Last 300 seconds output rate: 0 bytes/sec, 0 bits/

这种情况下,最大的报文发到交换机后,因为交换机允许的最大报文数为1464-40=1424字节,所以出现了上述现象,同时也解释了http和ftp有问题(长报文),而ping和ssh没有问题(短报文)。

解决方案

方案1:修改隧道口和物理口的MTU值,但是取值不好定,因为不知道应用最长报文的长度。

方案2:GRE隧道口配置TCP的MSS,超出后分片处理。

设置TCP的MSS参考命令:

【命令】 tcp mss value undo tcp mss 【缺省情况】 未配置接口的TCP最大报文段长度。 【视图】 接口视图 【缺省用户角色】 network-admin mdc-admin 【参数】 value:TCP最大报文段长度,取值范围为128~(接口的最大MTU值-40),单位为字节。 【使用指导】 TCP最大报文段长度(Max Segment Size,MSS)表示TCP连接的对端发往本端的最大TCP报文段的长度,目前作为TCP连接建立时的一个选项来协商:当一个TCP连接建立时,连接的双方要将MSS作为TCP报文的一个选项通告给对端,对端会记录下这个MSS值,后续在发送TCP报文时,会限制TCP报文的大小不超过该MSS值。当对端发送的TCP报文的长度小于本端的TCP最大报文段长度时,TCP报文不需要分段;否则,对端需要对TCP报文按照最大报文段长度进行分段处理后再发给本端。 该配置仅对新建的TCP连接生效,对于配置前已建立的TCP连接不生效。 该配置仅对IP报文生效,当接口上配置了MPLS功能后,不建议再配置本功能。

参考资料
  1. https://blog.csdn.net/qq_43684922/article/details/105300934
,

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页