我不确定这个问题是否更适合于stackoverflow或serverfault。 如果你认为它更适合于stackoverflow，让我知道，我会删除这个并移动它。
我有一个STUNT实现。 如果您不知道STUNT是什么，那么这是一个协议，用于在两个单独的NAT之间build立直接的TCP连接。 我将简要介绍一下，尽pipe我的问题并不直接涉及到协议。
这是通过使用第三方来预测每个对等体的NAT将映射其下一个出局连接的端口。 第三方然后告诉每个同行对方的预测端口，他们都试图在预测的端口上彼此连接。 当它们相互发送SYN数据包时，它会在该端口的NAT中打开一个“空洞”，从而允许SYN数据包通过和握手进行。
我的一位同事build议让对方启动STUNT连接，试图将SYN数据包发送到预测的端口以及接下来的四个端口，以防止其他应用程序（甚至是我们的应用程序）使用预测的端口连接尝试，但在预测之后。
一个例子就是预测另一个端口将从端口80连接到我们，但是另一个应用程序最终使用端口80，所以连接实际上来自端口81。 但是向五个不同的端口发射SYN数据包，如果它来自80,81,82,83或84，我们将（理论上）成功。
但是，情况并非如此; 经过testing，只有第一个SYN包有成功的机会。 即使第一个SYN数据包被发送到错误的端口，但是接下来的四个数据包中的一个被发送到正确的端口，它们都被悄悄丢弃了。 没有任何反应，连接尝试只是超时。
一个简单的例子：
对等体A正在发起到对等体B的STUNT连接。
对等体A预计从端口1000连接到对等体B.
对等体B预计从端口2000连接到对等体A.
服务器发送1000到对等B和2000到对等A.
Peer B的计算机上的另一个应用程序build立一个新的连接，接pipe端口2000。
Peer A的计算机上的另一个应用程序创build一个新的连接，接pipe端口1000。
对等端A同时尝试连接端口2000,2001,2002,2003和2004的端口B; 连接尝试来自端口1001,1002,1003,1004和1005。
对等体B尝试连接到端口1000上的对等体B; 连接尝试来自端口2001。
Peer A和Peer B的NAT在端口1001和2001分别创build一个空洞; 它应该允许SYN数据包通过。
我相信发生的事情是，Peer B的NAT不允许Peer A的SYN数据包通过端口2001，因为它期望连接来自1000，但它来自1002.这表明NAT正在validationSYN数据包。
然而，从我读到的，STUNT的一个缺陷是，当创build连接时，存在一个漏洞窗口，连接可能被另一个源劫持。 如果这是NAT的标准行为来validation传入连接的来源，那么我不明白这个漏洞窗口是如何存在的。
请注意，我的实现并非有缺陷。 如果其中任一个预测的端口是正确的，则连接将成功; 当两个预测的端口都是错误的，并且尝试同时尝试多个端口时，问题就会发生。
作为对协议熟悉的人的一个注意事项，我使用的方法涉及发送一个SYN，我希望在尝试实际连接之前默默地进行。 我没有使用低TTL的实现。
我的NAT是否拒绝SYN数据包，因为它们不是来自预期的端口，还是拒绝它的其他东西？ 如果这是我的NAT，这是预期的/标准的行为？ 请注意，被拒绝的意思是“无声地丢弃”，因为没有RST或任何响应正在返回，连接只是超时。
编辑：有问题的路由器都是你在沃尔玛家买的那种，而不是那种大的企业会使用的。
简短的回答：是的 – 你的NAT拒绝数据包，因为它们不是预期的。 这将从NAT实现到NAT实现有所不同。
编辑：我之前没有听说过STUNT（STUN，没有STUNT）。 噢，呃…多么骇人！ 这让我哭了，互联网已经变成了这个NAT拖车公园，我们正在诉诸这样的黑客。
读完这篇论文之后，我得到了他们正在做的事情。 它基本上是STUN，在每个“端点”上添加一些数据包嗅探，嗅探初始序列号，并通过可以接受任意传入TCP连接的第三方进行交易。 实际上这是一个可爱的伎俩。
你永远不会得到这样的100％可靠的沟通。 我看到，最初实施这个的研究人员的一些testing结果看起来相当不错，但是…这实际上是一个非常有趣的，尽pipe密集的小图表。 本文深入研究了所有的预测问题，并给出了一些成功的百分比。 实际上，他们做得很好，这让我很震惊。
任何理智的NAT打算至less要使用源IP，目标IP，协议，协议源端口和协议目标端口来标识“连接”。 （希望他们也跟踪顺序/确认号码。）
如果您的SYN不完全匹配存储在设备的NAT表中的这些属性的组合，那么NAT实现应该默默地放弃它。 那将是我期望的行为。