NGINX SSL 没有通过 IPv6 响应

Question 1

您有一个 MTU 问题。

我一边测试wget -O /dev/null https://www.ekasparova.eu一边观察流量tcpdump。这是我看到的：

19:56:57.048361 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [S], seq 262121609, win 28800, options [mss 1440,sackOK,TS val 298423713 ecr 0,nop,wscale 7], length 0
19:56:57.087457 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [S.], seq 2396216876, ack 262121610, win 28560, options [mss 1440,sackOK,TS val 82836580 ecr 298423713,nop,wscale 7], length 0
19:56:57.087490 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 0
19:56:57.087692 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [P.], seq 1:322, ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 321
19:56:57.126190 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [.], ack 322, win 232, options [nop,nop,TS val 82836590 ecr 298423723], length 0
19:56:57.141224 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [P.], seq 2857:3678, ack 322, win 232, options [nop,nop,TS val 82836594 ecr 298423723], length 821
19:56:57.141301 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 248, options [nop,nop,TS val 298423736 ecr 82836590,nop,nop,sack 1 {2857:3678}], length 0

前 3 个数据包是握手。两端都宣布，mss 1440这意味着它们能够接收具有 1440 字节 TCP 有效负载的数据包（加上报头），总计 1500 字节 IP 流量，这是以太网通常支持的。

接下来的 2 个数据包是客户端问候和服务器已收到的确认。

最后 2 个数据包变得有趣了。默认情况下tcpdump显示相对序列号，在这种情况下，这使捕获更易于阅读。在来自服务器的数据包中，这是有趣的部分。我们看到从到的seq 2857:3678跳跃，这意味着客户端尚未收到 2856 字节的间隙。2856 字节对应于两个 1428 字节的数据包。1440 和 1428 之间的差异是时间戳选项的大小。12857

因此，服务器将服务器问候信息拆分成 3 个数据包发送。但前两个数据包对于网络来说太大，因此未传送给客户端。

在客户端到服务器的最后一个数据包中，我们可以看到这一点sack 1 {2857:3678}。这是客户端发送的选择性确认，通知服务器到目前为止收到的数据存在间隙。

很可能服务器会不断重复发送这两个丢失的数据包。但无论它重发这两个数据包多少次，它们对于网络来说仍然太大。路径上的路由器可能会向服务器发送错误消息，告知它数据包太大，需要以较小的数据包重新传输。

如果服务器收到这些错误消息，它会根据需要重新传输较小的数据包。它会记住较小的 PMTU，以便在后续请求中不必重复此发现步骤。

所有这一切的一个可能的解释是，您的防火墙配置错误，它丢弃了所有错误消息，通知您的服务器需要以较小的数据包重新传输数据。

Answer

您有一个 MTU 问题。

我一边测试wget -O /dev/null https://www.ekasparova.eu一边观察流量tcpdump。这是我看到的：

19:56:57.048361 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [S], seq 262121609, win 28800, options [mss 1440,sackOK,TS val 298423713 ecr 0,nop,wscale 7], length 0
19:56:57.087457 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [S.], seq 2396216876, ack 262121610, win 28560, options [mss 1440,sackOK,TS val 82836580 ecr 298423713,nop,wscale 7], length 0
19:56:57.087490 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 0
19:56:57.087692 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [P.], seq 1:322, ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 321
19:56:57.126190 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [.], ack 322, win 232, options [nop,nop,TS val 82836590 ecr 298423723], length 0
19:56:57.141224 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [P.], seq 2857:3678, ack 322, win 232, options [nop,nop,TS val 82836594 ecr 298423723], length 821
19:56:57.141301 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 248, options [nop,nop,TS val 298423736 ecr 82836590,nop,nop,sack 1 {2857:3678}], length 0

前 3 个数据包是握手。两端都宣布，mss 1440这意味着它们能够接收具有 1440 字节 TCP 有效负载的数据包（加上报头），总计 1500 字节 IP 流量，这是以太网通常支持的。

接下来的 2 个数据包是客户端问候和服务器已收到的确认。

最后 2 个数据包变得有趣了。默认情况下tcpdump显示相对序列号，在这种情况下，这使捕获更易于阅读。在来自服务器的数据包中，这是有趣的部分。我们看到从到的seq 2857:3678跳跃，这意味着客户端尚未收到 2856 字节的间隙。2856 字节对应于两个 1428 字节的数据包。1440 和 1428 之间的差异是时间戳选项的大小。12857

因此，服务器将服务器问候信息拆分成 3 个数据包发送。但前两个数据包对于网络来说太大，因此未传送给客户端。

在客户端到服务器的最后一个数据包中，我们可以看到这一点sack 1 {2857:3678}。这是客户端发送的选择性确认，通知服务器到目前为止收到的数据存在间隙。

很可能服务器会不断重复发送这两个丢失的数据包。但无论它重发这两个数据包多少次，它们对于网络来说仍然太大。路径上的路由器可能会向服务器发送错误消息，告知它数据包太大，需要以较小的数据包重新传输。

如果服务器收到这些错误消息，它会根据需要重新传输较小的数据包。它会记住较小的 PMTU，以便在后续请求中不必重复此发现步骤。

所有这一切的一个可能的解释是，您的防火墙配置错误，它丢弃了所有错误消息，通知您的服务器需要以较小的数据包重新传输数据。

Question 2

我同意 @kasperd 的观点，这是 MTU 问题。例如，默认情况下wget -6 -O/dev/null http://www.ekasparova.eu不起作用（它会在https://www.babysoul.cz/同一个 IP 上进行短重定向，但随后它会挂在下一个更大的数据包上）。然后我强制减少了您的主机的 MSS：

ip -6 ro add 2a04:f310:100:3:f816:3eff:fea3:4553 advmss 1000 via $MY_GW

之后一切wget正常。所以，这是 MTU 问题。将mtr -6 -n --psize 1410 www.ekasparova.eu（有效）的输出与进行比较mtr -6 -n --psize 1411 www.ekasparova.eu，可以表明问题出在您的主机 2a04:f310:100:3:f816:3eff:fea3:4553或其上游2a04:f310:100::125

您可以采取以下解决方法（除了联系上游）：

测试它在哪种数据包大小下会中断（即，它wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1500.dat可能不会为你工作，但wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1000.dat可以正常工作），然后：

（更糟糕的是）限制默认 IPv6 路由的 MSS（如我上面所做的）。请注意，这仅适用于 TCP；例如，UDP DNS 数据包仍将被破坏，或者
（更好）降低接口 MTU（例如 ifconfig eth0 mtu 1200）。这应该适用于所有数据包。问题是，如果途中的某些数据包的 MTU 更低，您将无法与它们通信。降低 MTU 会导致性能略有下降（除非您是一个大型站点，否则通常这不是什么大问题）
（最好）尝试移除 IPv6 防火墙（您的防火墙和您的上游防火墙）是否有帮助；当您发现它确实有帮助时，尝试逐步将其重新组合，而不会破坏 PMTU 发现，直到找到有问题的线路。问题是它需要您 ISP 的更多工作和合作（并且打开防火墙可能会让您暂时处于危险之中）。

Answer

我同意 @kasperd 的观点，这是 MTU 问题。例如，默认情况下wget -6 -O/dev/null http://www.ekasparova.eu不起作用（它会在https://www.babysoul.cz/同一个 IP 上进行短重定向，但随后它会挂在下一个更大的数据包上）。然后我强制减少了您的主机的 MSS：

ip -6 ro add 2a04:f310:100:3:f816:3eff:fea3:4553 advmss 1000 via $MY_GW

之后一切wget正常。所以，这是 MTU 问题。将mtr -6 -n --psize 1410 www.ekasparova.eu（有效）的输出与进行比较mtr -6 -n --psize 1411 www.ekasparova.eu，可以表明问题出在您的主机 2a04:f310:100:3:f816:3eff:fea3:4553或其上游2a04:f310:100::125

您可以采取以下解决方法（除了联系上游）：

测试它在哪种数据包大小下会中断（即，它wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1500.dat可能不会为你工作，但wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1000.dat可以正常工作），然后：

（更糟糕的是）限制默认 IPv6 路由的 MSS（如我上面所做的）。请注意，这仅适用于 TCP；例如，UDP DNS 数据包仍将被破坏，或者
（更好）降低接口 MTU（例如 ifconfig eth0 mtu 1200）。这应该适用于所有数据包。问题是，如果途中的某些数据包的 MTU 更低，您将无法与它们通信。降低 MTU 会导致性能略有下降（除非您是一个大型站点，否则通常这不是什么大问题）
（最好）尝试移除 IPv6 防火墙（您的防火墙和您的上游防火墙）是否有帮助；当您发现它确实有帮助时，尝试逐步将其重新组合，而不会破坏 PMTU 发现，直到找到有问题的线路。问题是它需要您 ISP 的更多工作和合作（并且打开防火墙可能会让您暂时处于危险之中）。

NGINX SSL 没有通过 IPv6 响应

答案1

答案2

相关内容