我读过这个问题，但对称 NAT 的解释不够详细。
请有人帮助我理解以下段落吗？
我阅读了有关对称 NAT 的内容：
从相同的内部 IP 地址和端口到特定目标 IP 地址和端口的每个请求都映射到唯一的外部源 IP 地址和端口，如果同一内部主机发送数据包即使具有相同的源地址和端口但发送到不同目的地，使用不同的映射。只有从内部主机接收数据包的外部主机才能发回数据包。
http://en.wikipedia.org/wiki/Network_address_translation#Types_of_NAT
这是关于UDP 打孔的：
UDP 打孔不适用于大型企业网络中的对称 NAT 设备（也称为双向 NAT）。在对称 NAT 中，与众所周知的 STUN 服务器的连接相关联的 NAT 映射仅限于从知名服务器接收数据，因此，知名服务器看到的 NAT 映射对端点来说不是有用的信息。
http://en.wikipedia.org/wiki/UDP_hole_punching
但我并没有真正吸收它。我觉得它告诉我（在客户端发起通信的客户端 - 服务器应用程序中）除非 NAT 设备明确允许，否则服务器无法以其他方式进行通信。我不明白为什么会这么说。如果可能的话，你能帮我稍微简化一下这个描述吗？
我们的环境存在一个问题，即知名的远程支持工具无法由同样知名的软件供应商使用来为我们提供支持。客户端是代理感知的，但出于某种原因，它认为不使用它并通过端口 1153 上的 UDP 做一些完全不同的事情可能是个好主意。
我们有一个 NetApp 存储系统，为几个 Hyper-V 集群提供 LUN。在 2008 R2 上运行系统性能跟踪（在 perfmon 中）时，会出现关于“高级别拆分 I/O”的警告。阅读拆分 I/OI 发现这很可能是由碎片驱动器引起的。
我发现很难相信传统意义上的驱动器是碎片化的，因为一切都是虚拟的（LUN 上的虚拟硬盘、卷上、聚合中、存储系统上的虚拟硬盘，在它认为合适的任何地方写入并进行重复数据删除那个数据也是）。所以我应该担心这个吗？我看不到任何存储问题的证据，例如延迟过大。
顺便说一句，在我们的一个 VM 上运行碎片整理分析显示约 50% 的碎片数据。我想我在某处读到，如果检测到碎片超过 20%，Windows 会自动拆分 I/O，这是真的吗？碎片整理任务被禁用，它怎么知道？
每次发布新版本的 Windows 时，我都会问自己为什么公司应该立即开始推出它。有可能会在服务包中修复错误，因此有些人会说最好等到服务包发布。还有“如果它没有坏就不要修复它”的态度，以及“用户感到困惑”、“支持新的操作系统噩梦”的观点。但这些似乎都没有和我一起洗。
以更全面的方式思考它，这些只是不改变流程（最终）处理方式的借口，因此这些问题是无关紧要的。
我想尽早采用是个好主意，但我无法解释原因。你能帮我吗？现在 MS 正在转向年度更新周期，组织是否必须改变他们对这些事情的看法？