问题背景

部署在服务器上的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功能后，不提议再配置本功能。