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

部署在服务器上的Web应用因为机房迁移，导致PC上无法正常访问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