我在网络运营商的 GGSN 和我们的数据中心之间建立了一个 Linux IPSec 隧道。IPSec 对所有流量都运行良好，但来自我们这边且标记为 ECN 位设置为 0x3（CE，拥塞经历）的 IP 数据包将不会加密并转发到隧道。
该隧道的设置没有 ECN 支持，但据我所知，这不会导致数据包丢失。
Linux 内核版本为 2.6.18-6-xen-amd64 #1 SMP Fri Dec 12 07:02:03 UTC 2008 x86_64 GNU/Linux（相当旧，但 xen 基础设施不允许较新的内核）
Keying Daemon 是 racoon 0.7.3
有什么提示可以解决此问题吗？
答案1
如果某些东西在隧道数据包外部将 ECN 设置为 0x3，而不首先检查到达的数据包是否具有 ECN 功能（ECN != 00），这将导致隧道出口丢弃内部 IP 头上 ECN == 00 的任何数据包，但外部 ECN == 0x3。
从问题来看，ECN 似乎在隧道之前设置为 0x3，在这种情况下，我无法解释为什么数据包会被丢弃。但问题有点混乱，所以它可能是在隧道内设置的，那么我的解释是正确的。
原始 IETF ECN 规范 [RFC3168] 为隧道出口指定了这种丢弃行为，这是有充分理由的。端点使用 ECN != 00 来告诉网络它们理解 ECN（ECN 功能传输或 ECT）。如果内部 ECN = 00，则意味着如果网络尝试使用 ECN，端点将无法理解网络的含义。因此，在 ECN==00 的数据包上设置 ECN == 0x3 被定义为非法转换。因此，如果隧道发现这样的数据包，则需要丢弃它们，以便将 ECN 信号转换为终端系统可以理解的拥塞信号（丢弃）。
早期的 IPsec VPN 不必符合这种丢弃行为 [RFC4301]，但 IPsec 在 2010 年与原始 ECN 规范相协调 [RFC6040]。
在问题中，不清楚是否在所有数据包上都设置了 ECN = 0x3（当然不应该）。ECN 通常只会在一小部分数据包上设置，随着拥塞的增加而增加。然后，如果隧道丢弃这几个数据包，终端系统将感知到低水平的拥塞。
答案2
如果您像我猜测的那样使用 Openswan，那么您将从 irc.freenode.net 上的 #openswan 最快获得答案——那是开发人员聚集的地方，他们经常会问很多好问题来帮助您调试您的情况。