我有一个运行在公司防火墙后面的Apache Server 14.04。 这一直在上个月工作正常，但现在服务器没有响应来自局域网外部的请求（由防火墙完成的端口转发）。 现在我最初的想法是认为对Apache的东西出了问题，但当我尝试访问使用内部地址（192.168.8.10）的服务器，一切工作正常。 当我尝试从本地networkingtelnet时：
$ telnet 192.168.8.10 80 Trying 192.168.8.10... Connected to 192.168.8.10. Escape character is '^]'. 服务器上的Netstat给了我以下输出：
$netstat -n -c | grep "192.168.8.19:80" tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV tcp 0 0 192.168.8.10:80 192.168.8.250:49728 SYN_RECV
当我在浏览器中访问http://192.168.8.10时，netstat产生：
$netstat -n -c | grep "192.168.8.19:80" tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 ESTABLISHED tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 FIN_WAIT2 tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 FIN_WAIT2 tcp6 0 0 192.168.8.10:80 192.168.8.252:63798 FIN_WAIT2
现在，当我从局域网之外尝试这个时，telnet不连接，浏览器刚刚超时。
$ telnet 78.xx.xx.245 80 Trying 78.xx.xx.245...
这只是无限期地挂起，但netstat仍然承认SYN_RECV数据包。
$ netstat -n -c | grep "192.168.8.19:80" tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV tcp 0 0 192.168.8.10:80 194.xx.xx.62:52721 SYN_RECV
浏览器testing不会在netstat中产生任何输出。
这导致我认为问题是在防火墙上的端口转发。 但是，当我尝试将端口80转发到Windows服务器时，它工作得很好。 当我改变端口80被转发回Ubuntu服务器，同样的问题。 telnettesting实际上通过防火墙到达服务器的事实表明，防火墙不是问题。
我的IT部门告诉我，过去几天防火墙的configuration没有改变，我也没有对服务器做任何修改。 事实上，试图将端口80转发到另一台运行apache的Ubuntu桌面机器上，结果相同（即使netstat输出，挂起的浏览器和telnet也不能连接）。
其他端口被成功转发到防火墙后面的Windows服务器（当转发到Windows服务器时80端口工作），所以我不认为这个问题是与ISP。 这似乎只是Ubuntu的一个问题。
有没有人有任何想法，这可能是因为这是我们现在的主要问题？
当主机可以与局域网通信但不在局域网之外时，最有可能的错误configuration是寻找不正确的网关IP地址。
如果网关configuration错误的主机是TCP连接的服务器端，则会出现这样的症状：接收和接受SYN数据包，但由于没有正确的网关地址，无法传送SYN-ACK数据包。 这符合您的问题中描述的症状。
一个糟糕的解决方法是在网关处对传入连接的源IP进行NAT转换，这似乎是IT部门所做的。 这不是一个好主意，因为您的日志文件中丢失了客户端IP地址，并且可能会引入其他连接跟踪。 但是，由于服务器不再将数据包发送到客户端IP地址，而是发送到网关IP地址，因为它位于直接连接的网段上，而不依赖于configuration错误的默认网关。
在这种情况下，正确的解决方法是在服务器上configuration正确的网关IP地址，并恢复在防火墙上应用的解决方法。
如果您的Ubuntu服务器configuration了静态IP地址，则IP地址和网关地址都位于/etc/network/interfaces 。 更改该文件在下次重新启动时生效。
尝试sudo ufw禁用
还要检查conf文件中的Apacheconfiguration。 /etc/apache2/apache2.conf中
例如： – / var / www
<Directory /var/www/> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory>
这是防火墙上的一个configuration问题。 显然，防火墙规则必须启用NAT才能使端口转发工作。 IT部门向我保证，以前这个function还没有开启（即使这个function已经运行过了），而且这只是一个问题，如果这些端口被转发到一个linux服务器（即windows服务器不需要启用NAT在相关的防火墙规则上，端口转发成功）。
编辑这是一个问题上的石膏。 正如kasperd指出的，问题是服务器上的网关configuration。