1. 如果导致 ACK 的原始 SYN 或数据包被允许通过，防火墙不允许 ACK 返回通过防火墙是非标准的（实际上，适得其反）。 TCP 甚至需要 ACK 才能形成连接。 您的网络管理员被误导或混淆。ACK 不会带来安全风险。

2. 您的下一步是证明您的防火墙正在接收初始 SYN，并返回 SYN ACK。如果您图片中的数据包捕获是从您的防火墙捕获的，那么您有足够的证据证明这一事实。特别是如果此捕获来自防火墙的外部接口（面向 Internet 的接口）

@Karyhead 提出了一个很好的观点，即“SSL 握手”发生了一些棘手的事情（当你读完这篇文章时，为什么用引号引起来是有道理的）。

几乎所有类型的 SSL 握手都会以 Client Hello（从客户端发送）开始，紧接着是 Server Hello（由服务器发送）。相反，您的数据包捕获表明在三向握手（这些是标记为 的数据包[SYN] [SYN,ACK] [ACK]）之后，客户端立即发送两个数据包。我们可以从这两个数据包中学到一些东西：

• 根据时间增量，第 2 个数据包在第 1 个数据包后 0.000002 秒发送，这告诉我们这不是重新传输的数据包
• 从服务器捕获的接下来的两个数据包包括 156 和 173 的 ACK#。这意味着第一个数据包可能是155 字节，第二个数据包可能是 17 字节。我说可能是因为我无法访问 PCAP 来进行明确验证，而且可能还有其他一些奇怪的事情发生。无论哪种方式，我们肯定知道的一件事是来自客户端的前两个数据包合并了172 个字节
• 这些不是Client Hello。我与笔记本电脑上的一些示例捕获进行了比较，大多数 Client Hello 大约为 200+~ 个字节。我没有看到少于 200 个。此外，如果它是 Client Hello，Wireshark 会这样解释它。此外，您可以在第一个和第二个数据包中看到 MSS 设置为 1432，这意味着 172 字节的 Client Hello 不必分成两个数据包。
• 服务器不向客户端发送数据。您可以判断，因为当服务器在倒数第二个数据包中发送其 FIN 时，序列号仅为 1。这意味着服务器发送的唯一需要确认的项目是服务器的“SYN”来自其原始“SYN” /确认”。这告诉我们这绝对不是SSL/TLS 握手。每次 SSL/TLS 握手都需要对话双方的信息。即使是简短的握手，也需要双方确认他们仍然拥有必要的身份验证和密钥材料。

注意：在这篇文章中，SSL 和 TLS 是完全相同的，并且可以

最后，您可能正在查看某人通过端口 443 隧道传输数据。无法从您发送的内容中判断可能是什么数据，但是如果该对话遇到了我的防火墙，该防火墙据说只允许 SSL 加密的 HTTP 通过端口 443 通过（又名，HTTPS），我肯定会仔细查看内容以找出可能是什么。它可能是恶意的，但也可能是无害的。即使它是无害的，我也想知道什么是......以及为什么他们觉得他们需要通过 TCP/443 传输流量而不是请求打开另一个应用程序端口。

当您说“支持公司说他们看不到我们这边的计算机”时，您的意思是支持公司正在从他们这边发起流量（可能是您之前提到的 RDP 连接）？如果是这种情况，我很好奇服务器上的 IP 是否相同。如果更改了，可能需要在防火墙上调整所需的访问权限，以允许从支持到新服务器 IP 的连接。我仍然需要深入研究 Wireshark，所以我无法在那里给你建议。如果您可以从服务器或 telnet 浏览到 HTTPS 网站到端口 443 上的支持 IP，则可以轻松确认允许 HTTPS 出站（尽管不准确）。

顺便说一下，对于端口 443，只要通过访问列表规则允许发起流量，大多数防火墙（有状态）就会允许返回流量。

在您提供的 pcap 截图中，您建立连接然后发送 2 个数据包。仅收到 1 个 ACK​​。这不是异常，因为 TCP 使用窗口缩放，但在第 6 帧中，知道这是对哪个帧的 ACK 可能会有所帮助。如果你点击这个框架，Wireshark 有一个 SEQ/ACK 分析部分。如果这是对第 5 帧的 ACK，那么支持公司就没有立足之地。如果它是第 4 帧的 ACK，您可能会错过第 5 帧的 ACK，但是当您收到第 4 帧的 ACK 时，您是否阻止了 ACK 值得怀疑。

看起来遥测服务是基于 HTTPS 的。基于此，它看起来像是一个失败的 SSL 握手。