我不确定这个问题更适合用 stackoverflow 还是 serverfault。如果你认为它更适合用 stackoverflow，请告诉我，我会删除它并将其移过去。
我有一个 STUNT 实现。如果您不知道 STUNT 是什么，它是一种用于在单独的 NAT 后面的两个对等体之间建立直接 TCP 连接的协议。我将简要介绍一下，尽管我的问题与该协议没有直接关系。
这是通过使用第三方来预测每个对等方的 NAT 将映射其下一个传出连接的端口来实现的。然后第三方会告诉每个对等方对方的预测端口，然后双方都会尝试通过预测端口相互连接。当它们向对方发送 SYN 数据包时，它会在该端口的 NAT 中打开一个“漏洞”，从而允许 SYN 数据包通过并进行握手。
我的一位同事建议让发起 STUNT 连接的对等端尝试向预测端口以及接下来的四个端口发送 SYN 数据包，以防在我们尝试连接之前但在做出预测之后，另一个应用程序（甚至是我们的应用程序）使用了预测端口。例如，
预测另一个对等端将从端口 80 连接到我们，但另一个应用程序最终使用了端口 80，因此连接实际上来自端口 81；但是向五个不同的端口发送 SYN 数据包，如果来自 80、81、82、83 或 84，我们（理论上）会成功。
但事实并非如此；测试时，只有第一个 SYN 数据包有成功的机会。即使第一个 SYN 数据包发送到错误的端口，但接下来的四个数据包中有一个发送到正确的端口，它们都会被默默丢弃；没有响应，连接尝试只是超时。
一个简单的例子：
对等点 A 正在发起与对等点 B 的 STUNT 连接。
预计对等点 A 将从端口 1000 连接到对等点 B。
预计对等点 B 将从端口 2000 连接到对
等点 A。服务器向对等点 B 发送 1000，向对等点 A发送 2000。对等
点 B 计算机上的另一个应用程序建立新连接，接管端口 2000。
对等点 A 计算机上的另一个应用程序建立新连接，接管端口 1000。
对等点 A 同时尝试通过端口 2000、2001、2002、2003 和 2004 连接到对等点 B；连接尝试来自端口 1001、1002、1003、1004 和 1005。
对等点 B 尝试通过端口 1000 连接到对等点 B；连接尝试来自端口 2001。
在对等体 A 和对等体 B 的 NAT 中分别在端口 1001 和 2001 处创建一个洞；它应该允许 SYN 数据包通过。
我认为正在发生的情况是，对等体 B 的 NAT 不允许对等体 A 的 SYN 数据包通过端口 2001，因为它期望连接来自 1000，但它来自 1002。这向我表明 NAT 正在验证 SYN 数据包的来源。
然而，据我所知，STUNT 的一个缺陷是，在创建连接时，存在一个漏洞窗口，该漏洞窗口可能被另一个源劫持。如果 NAT 验证传入连接的来源是标准行为，那么我不明白这个漏洞窗口怎么会存在。
请注意，我的实现没有缺陷。如果任何一个预测端口正确，连接就会成功；当两个预测端口都错误时，就会出现问题，并且需要同时尝试多个端口。
顺便提一下，对于熟悉该协议的人来说，我使用的方法是在尝试实际连接之前发送一个我期望悄无声息的 SYN。我没有使用低 TTL 实现。
我的 NAT 拒绝 SYN 数据包是因为它们不是来自预期的端口，还是有其他原因拒绝了它们？如果是我的 NAT，这是预期/标准行为吗？请注意，我所说的拒绝是指“默默丢弃”，因为没有返回 RST 或任何响应，连接只是超时。
编辑：所讨论的路由器都是您在沃尔玛购买的家用路由器，而不是大型企业使用的路由器。
答案1
简短回答：是的——您的 NAT 拒绝数据包，因为它们不符合其预期。这会因 NAT 实施而异。
编辑点评：我以前没听说过 STUNT……（是的，STUNT——不是 STUNT）。哦，真恶心……真是个黑客。互联网已经变成了这个 NAT 拖车公园，我们竟然要诉诸这样的黑客手段，这让我很伤心。
看完之后报纸我知道他们在做什么。它基本上就是 STUN，在每个“端点”上添加一些数据包嗅探，以嗅探初始序列号，并通过网络上可以接受任意传入 TCP 连接的第三方进行交换。实际上，这是一个很巧妙的技巧。
你永远不可能获得 100% 可靠的通信。我发现最初实施这项技术的研究人员有一些检测结果不过，在港口预测方面看起来相当不错……这实际上是一个非常有趣的小图表，尽管有些密集。这篇论文更深入地探讨了所有预测问题，并给出了一些成功率。事实上，他们做得这么好让我很震惊。
任何合理的 NAT 实现至少都会使用源 IP、目标 IP、协议、协议源端口和协议目标端口来识别“连接”。 （希望它们也能跟踪序列/确认号。）
如果您的 SYN 与设备 NAT 表中存储的这些属性的组合不完全匹配，则 NAT 实现实际上应该默默地将其丢弃。这是我所期望的行为。