问题[tunnel](computer)

我按照MikroTik 帮助文件中的 Hurricane Electric 示例在 MikroTik 上设置了 6to4 SIT 隧道。

它有效，但与某些资源的连接非常慢并且经常超时。例如，在升级和重新配置guix 期间，默认服务器的下载速度徘徊在 50 KiB/s 左右，并且在下载内核时通常最终失败，可能是因为它是一个大包。

隧道代理的技术支持建议1280的MTU太小，应该使用1480。事实上，如果我将隧道接口的 MTU 更改为该值，连接速度就会变得正常并以 MiB 为单位进行计数。我不知道为什么会这样，但可能是因为在某些时候网络设备不需要将较大的数据包分解成较小的片段，这需要一些开销。

但我遇到了另一个问题：与某些服务器的连接挂起。guix pull挂起。针对有问题的 URL运行curl -v会导致 TLS 协商超时 ( curl: (28) SSL connection timeout) 或加密库失败 ( curl: (35) gnutls_handshake() failed: Помилка у функції pull.)。

对服务器进行 ping 操作可以正常工作，但使用 MTU 大小（ping6 -s后跟八位字节数）的消息进行 ping 操作会收到Packet too big第一个 ping 操作的响应，然后丢弃其余的操作。TCP 连接成功，但 TLS 协商超时。MTU 对于与此服务器的连接来说太大。

RFC 4213规定：

使用静态隧道 MTU 的节点将隧道接口视为具有固定接口 MTU。默认情况下，MTU 必须介于 1280 和 1480 字节（含）之间，但它应该为 1280 字节。

RFC 6343有一个关于“PMTUD 失败”的部分，该部分链接到RFC 2923，建议 IPv6 回退到 MTU 1280，除非可以修复“ICMP 黑洞”。

MikroTik 的示例配置建议使用 1280 以避免 MTU 协商的必要性。还有一个clamp-tcp-mss默认打开的设置：

控制是否更改接收到的 TCP SYN 数据包的 MSS 大小。启用后，如果当前 MSS 大小超过隧道接口 MTU（考虑 TCP/IP 开销），路由器将更改接收到的 TCP SYN 数据包的 MSS 大小。接收到的封装后的数据包仍将包含原始的MSS，只有解封装后MSS才会发生变化。

这也许可以解释为什么 ping 偶尔允许我通过隧道成功发送高达 65527（显然是 65535 减 8）的大量消息。但是，这会尝试匹配隧道 MTU，而我需要确定每个连接的 MTU，该 MTU 可能小于隧道 MTU。我该如何做到这一点，这样我就不需要降低隧道 MTU？

我已经成功地在我的本地 FritzBox 7590 和我的办公室之间创建了一个 IPSEC 隧道，它正在运行一个带有 pfsense 2.4.5-RELEASE-p1 和 coreboot 固件 v4.11.0.6 的 pfsense 硬件防火墙 (APU2)。

但是，隧道仅在启用积极模式的情况下工作，这会产生以下 pfsense 日志条目：

/rc.newipsecdns：警告：设置 i_dont_care_about_security_and_use_aggressive_mode_psk 选项，因为第 1 阶段是使用具有预共享密钥的激进模式配置的。这不是一个安全的配置。

如何在这些位置之间创建安全隧道？

[编辑] 这似乎是一个 OpenVPN 错误 - 与 openvpn Tap 隧道的服务器端桥接会导致 ARP 数据包丢失，但与客户端（连接到 vpn 的任何客户端）的桥接效果很好。我通过与客户端而不是服务器桥接来解决该错误。错误报告过程是一项相当多的工作，因此我需要一段时间才能将其全部编写并提交给 Openvpn 项目。

我正在观察 Openvpn 不断丢弃某些数据包......

设想：

我搭建了一个广域二层网络（使用OpenVPN），支持Minecraft袖珍版（MCPE）玩家（只是一家人）在网络好友列表中看到对方，一起玩。有三个远程端点，都在不同的位置，还有一个中央 openvpn 服务器。每个远程端点广播桥接到 Openvpn Tap 接口的 Wi-Fi。这很好用，玩家可以互相看到。

最近我想在本地添加一个额外的 Wi-Fi 端点，在服务器位置。因此，我在网桥上添加了一个以太网端口，并连接了一个 Wi-Fi 网桥，以获得与现有 openvpn 网桥的第 2 层连接。乍一看，这似乎运作良好；客户端可以上网，L2 流量看起来很正常。

但是，当远程客户端端点上的玩家尝试与连接到本地 wi-fi 网桥的玩家对战时，玩家无法看到对方。

本地 Wi-Fi 桥接到 openvpn 隧道的 SERVER 端，这似乎是一个因素，但这是出乎意料的。

经过数小时的故障排除后，我将问题缩小到一个特殊的事实 - 桥接到服务器的 openvpn Tap 接口（名为 tapmc）的 Wi-Fi 无法与 VPN 另一端的玩家对战。

换句话说，如果任何两个玩家在同一个 Wi-Fi 上或在客户端 openvpn Wi-Fi 端点上，无论距离多远，他们都可以看到彼此。但是连接到连接到 SERVER 端 openvpn Tap 接口的 Wi-Fi 的玩家遇到了问题 - 他们无法看到隧道客户端的玩家，而远程玩家也看不到他们。

为了看到对方，游戏每 1-2 秒向端口 19132 (ipv4) 发送一个 UDP 广播数据包。网络上的所有玩家都会收到这些广播，如果他们的游戏是服务器，那么他们的游戏会向请求者发送一个单播数据包。此单播响应数据包包含游戏信息，因此正在网络上搜索活动游戏的玩家将看到它们出现在他们的朋友列表中，因此他们可以加入游戏。

附件是对丢失数据包的一小段时间的分析。数据包从分路隧道的一侧进入，而不是从另一侧出来。我已经通过对隧道的每一侧运行 tcpdump 来捕获数据包，在 openvpn tap 接口本身上，因此路径中没有网桥，尽管接口都是网桥的成员。

我看到的是 PLAYER2 在网络上搜索游戏时发送搜索广播，由 PLAYER1 的游戏接收，它想用单播游戏信息包响应但首先需要解析 PLAYER2 的 MAC 地址，所以它发送一个 ARP who-has。PLAYER1 接收并响应 who-has 数据包及其所有后续重传，但这些响应不会通过 Openvpn 隧道传输到 PLAYER1。因此，L2 ARP 解析永远不会成功，并且永远不会发送单播游戏信息数据包，并且 PLAYER2 永远不会看到 PLAYER1。

在隧道中丢失的还有游戏搜索广播包的第二个副本，但是这不会对过程造成不利影响，因为两个副本中的第一个已成功传输。但为什么只有一个？

Openvpn 服务器配置

server 192.168.251.0 255.255.255.0
verb 3
key ***
ca ***
cert ***
dh ***
tls-auth ***
key-direction 0
keepalive 10 60
persist-key
persist-tun
client-to-client
proto udp
port ***
dev tapmc
status ***
ifconfig-pool-persist ***
user nobody
group nobody

Openvpn 客户端配置

client
nobind
dev tapmc
remote-cert-tls server
remote ***    
<key>
***
</key>    
<cert>
***
</cert>    
<ca>
***
</ca>
<tls-auth>
***
</tls-auth>
key-direction 1
#redirect-gateway def1

Openvpn 版本：服务器：2.4.8-1，客户端：2.4.7-1