序言：所以，在我真正提出这个问题之前，我想指出的是，我对发布这个问题有些担心，因为即使我input了这个内容，感觉就像我要求某人告诉我我需要切换configuration，而不是这种情况。 我已经完成了主交换机configuration并准备好回到客户端，但是他们要求我validation他们实际应用到交换机的/ entire / config，而不仅仅是应用特定的东西，因此下面的问题。 无论如何，现在已经结束了，到了真正的问题。
我一直在为一个客户端开发一个应用程序，这个应用程序可以运行在一系列运行Debian 7.5的负载均衡的AWS服务器上，这些服务器只能从所有地址的80端口访问应用程序，端口22只能从我们的办公室以及客户外包的AWSpipe理团队的办公室。
客户端的安全策略是有限制的，因为服务器将包含敏感的业务数据，因此需要尽可能locking来自所有服务器的入站和出站连接的networkingconfiguration。 我已经概述了这个部分的要求，并且我自己和AWS团队已经达成一致。 但是，他们要求我validation他们要应用的最终configuration，这包括以下几行：
Source Destination Protocol Ports Service Action Description 0.0.0.0/0 192.168.0.0/16 TCP 1024-65535 Ephemeral Ports Allow Allows inbound return traffic from the Internet 192.168.0.0/16 0.0.0.0/0 TCP 32768-65535 Ephemeral Ports Allow Allows outbound responses to clients on the Internet (for example, serving web pages to people visiting the web servers in the subnet) 不幸的是，networking层是我所知道的OSI模型的一个方面。 我隐约知道有些服务使用临时端口的实际工作人员的连接后，初步请求到服务的知名端口已经build立，但我不知道哪些服务实际上需要这些端口打开公共接口服务器才能使这些服务器正常运行。 这个评论意味着networking服务器需要32768-65535的function，但是我过去有过权威的回应，后来certificate是错误的，所以我想证实这个说法。
nginx或sshd中的任何一个都需要打开临时端口才能正确执行其function，或者所有活动总是只发生在已configuration使用的端口上（例如分别为80和443以及22） ？ closures临时端口通信阻止像apt这样的服务正常运行（我相信通常在端口80上使用HTTP与其源进行交互）？
此外，他们添加了以下两行有关DNS查询的信息：
Source Destination Protocol Ports Service Action Description 0.0.0.0/0 192.168.0.0/16 TCP/UDP 53 DNS Allow Allows inbound DNS query from anywhere 192.168.0.0/16 0.0.0.0/0 TCP/UDP 53 DNS Allow Allows outbound DNS queries to anywhere
现在，我们并没有在这些服务器上运行DNS守护进程，所以我敢肯定我们可以完全折扣第一行，但是将53closures到进出stream量阻止服务器正确parsing主机名？ 我不得不承认，我从来没有真正了解DNS如何实际工作，这是我从来没有需要的。 ：s假设现在是开始的好时机！
但是，是的，博士总结：
将端口1024-65535closures到入站和出站的所有stream量，阻止任何nginx，sshd，DNS查询或任何核心操作系统实用程序在Debian服务器上正常运行？
定义一个套接字对 ：
通信本地和远程套接字称为套接字对。 每个套接字对由一个由源IP地址和目的IP地址和端口号（即本地和远程套接字地址）组成的唯一4元组来描述。[3] [4] 在TCP情况下，每个唯一的套接字对4元组被分配一个套接字号，而在UDP情况下，每个唯一的本地套接字地址被分配一个套接字号。
在服务器端，端口通常由正在使用的协议/应用程序修复。 例如，SSH 22和DNS 53。
在客户端，一个发起到服务器的连接，它必须select一个源端口来完成它所需要的4元组的唯一标识连接的一部分。 客户通常在1025-65535范围内select一个随机端口。 我相信这就是他们称之为短暂的端口？
有些协议（如RPC portmap）会有一个监听固定端口的服务器，客户端会连接并请求一个特定的服务，监听器会提供一个客户端应该连接的端口（通常是随机的，在一个范围内）并产生服务在那个港口 这只是一个更复杂的服务器端口安排的例子，但绝不要求使用客户端的特定源端口。 他们应该是随机的。
过滤源端口是有点尴尬。 发布的列表不会显示是否过滤源端口或目标端口。 如果你真的想加强你的防火墙，默认为一个block = all策略，只允许有必要的端口。我不会限制哪些源端口可以使用，除非你正在寻找麻烦（例如，客户端不能连接）或额外的工作（即复杂的防火墙规则）。
看起来在第一个列表中，他们指定了随机端口的随机数，客户端可以使用。 他们为什么在意？