Servidor não está respondendo de fora da LAN

Question

Eu tenho um Ubuntu Server 14.04 executando o Apache que está por trás de um firewall corporativo. Isso tem funcionado bem no último mês, mas agora o servidor não está respondendo a solicitações vindas de fora da LAN (encaminhamento de porta feito pelo firewall). Agora meu pensamento inicial era pensar que algo no apache estava errado, mas quando tento acessar o servidor usando o endereço interno (192.168.8.10), tudo funciona bem. Quando tento fazer telnet da rede local:

$ telnet 192.168.8.10 80
Trying 192.168.8.10...
Connected to 192.168.8.10.
Escape character is '^]'.

Netstat no servidor está me dando a seguinte saída:

$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

e quando visito http://192.168.8.10 em um navegador, o netstat produz:

$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

Agora, quando eu tento isso de fora da LAN, o telnet não se conecta e o navegador apenas expira.

$ telnet 78.xx.xx.245 80
Trying 78.xx.xx.245...

Isso apenas trava indefinidamente, mas o netstat ainda reconhece os pacotes 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

O teste do navegador não produz nenhuma saída no netstat.

Isso me levou a pensar que o problema era o encaminhamento de porta no firewall. No entanto, quando tentei encaminhar a porta 80 para um servidor Windows, ela funciona perfeitamente bem. Quando eu mudei a porta 80 para ser encaminhado de volta para o servidor Ubuntu, mesmo problema. O fato de que o teste de telnet realmente chega ao servidor através do firewall indica que o firewall não é o problema.

Meu departamento de TI me diz que não houve alterações na configuração do firewall nos últimos dias e que não fiz alterações no servidor. De fato, tentar encaminhar a porta 80 para outra máquina de desktop Ubuntu com o apache rodando produziu os mesmos resultados (não foi possível conectar o navegador e o telnet, apesar da saída netstat).

Outras portas são encaminhadas com êxito para um Windows Server atrás do firewall (e 80 funcionavam quando encaminhadas para o servidor do Windows), portanto, não acho que o problema seja com o ISP. Parece ser apenas um problema com o Ubuntu.

Alguém tem alguma idéia do que isso poderia ser, já que é um grande problema para nós agora?

    

Answer 1

Quando um host pode se comunicar com a LAN, mas não fora da LAN, o mais provável erro de configuração é um endereço IP de gateway incorreto.

Os sintomas se o host com um gateway mal configurado for o lado do servidor de uma conexão TCP será que os pacotes SYN são recebidos e aceitos, mas os pacotes SYN-ACK não podem ser entregues devido a não ter um endereço de gateway correto. Isso se alinha aos sintomas descritos na sua pergunta.

Uma solução ruim seria o NAT, o IP de origem das conexões de entrada no gateway, que parece ser o que seu departamento de TI fez. Não é uma boa ideia porque você perde o endereço IP do cliente em seus arquivos de log e, potencialmente, introduz o rastreamento de conexão adicional. Pode parecer funcionar muito bem, já que o servidor não envia mais pacotes para o endereço IP do cliente, mas sim para o endereço IP do gateway, que, por estar em um segmento de rede conectado diretamente, não depende do gateway padrão mal configurado.

A correção apropriada neste caso é configurar o endereço IP correto do gateway no servidor e reverter a solução que foi aplicada no firewall.

Se o seu servidor Ubuntu estiver configurado com um endereço IP estático, o endereço IP e o endereço do gateway estarão em /etc/network/interfaces . A alteração desse arquivo entra em vigor na próxima reinicialização.

    

Answer 2

Experimente sudo ufw disable

Verifique também a configuração do Apache no arquivo conf. /etc/apache2/apache2.conf

Por exemplo: - / var / www

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted </Directory>

    

Answer 3

Este era um problema de configuração no firewall. Aparentemente, a regra de firewall tinha para ter o NAT ativado para o encaminhamento de porta funcionar. Eu fui assegurado pelo departamento de TI que isso não era ativado antes (embora tenha funcionado antes) e isso só parece ser um problema se as portas forem encaminhadas para um servidor linux (isto é, servidores windows não exige que o NAT esteja habilitado nas regras de firewall relevantes para o encaminhamento de portas funcionar com êxito).

EDITAR Este foi um gesso no problema. Como kasperd observou, o problema era a configuração do gateway no servidor.