Não é possível conectar-se aos serviços vinculados a 127.0.0.1

1

Eu tenho um servidor wheezy do Debian rodando alguns aplicativos web, um banco de dados MongoDB e um servidor Redis atrás de um servidor NGinx. Apenas o servidor NGinx está voltado para o público e os outros serviços estão com proxy reverso por trás dele. Essa configuração funcionou perfeitamente até dois dias atrás, quando houve uma queda de energia temporária no datacenter em que meu servidor está localizado. Após a reinicialização e a manutenção regular após o travamento (exclusão de arquivos de bloqueio, reparo do banco de dados, etc.), observei que o NGinx estava expirando em todos os serviços que ele procura. Aqui estão os passos que tomei para tentar resolver o problema:

  1. Verificar registros
    Eu verifiquei os logs de cada serviço e tudo está limpo sem erros (outros que o NGinx relatou o tempo limite da conexão upstream).

  2. Os serviços de verificação estão sendo executados
    Todos os processos para o aplicativo WSGI, MongoDB, etc. estão em execução e também verifiquei o netstat:

    # netstat -ntple
    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
    tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      0          21730537    1469/nginx      
    tcp        0      0 0.0.0.0:2525            0.0.0.0:*               LISTEN      1000       21730714    1511/python     
    tcp        0      0 0.0.0.0:9090            0.0.0.0:*               LISTEN      1000       21730931    1627/python     
    tcp        0      0 0.0.0.0:2022            0.0.0.0:*               LISTEN      0          21730651    1553/sshd       
    tcp        0      0 0.0.0.0:9000            0.0.0.0:*               LISTEN      1000       21730885    1624/python     
    tcp        0      0 127.0.0.1:27017         0.0.0.0:*               LISTEN      104        21730531    1376/mongod     
    tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      105        21730621    1532/redis-server *
    tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1000       21730731    1500/python     
    tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          21730536    1469/nginx      
    tcp6       0      0 :::2022                 :::*                    LISTEN      0          21730654    1553/sshd       
    tcp6       0      0 :::6379                 :::*                    LISTEN      105        21730619    1532/redis-server *
    
  3. Verifique a interface de loopback e o ping 127.0.0.1
    A interface de loopback está configurada corretamente em /etc/network/interfaces e ifconfig informa e executa. Eu também posso pingar 127.0.0.1 e localhost sem problemas.

  4. Desativar firewall
    Desativar o firewall não alterou a situação. A conexão ainda está expirando.

  5. Tente se conectar via telnet
    Eu tentei telnet para um dos serviços e é aí que eu notei um padrão estranho:

    # telnet 127.0.0.1 6379
    Trying 127.0.0.1...
    telnet: Unable to connect to remote host: Connection timed out
    
    # telnet ::1 6379
    Trying ::1...
    Connected to ::1.
    Escape character is '^]'.
    

Quando tento conectar-me a um serviço (Redis nesse exemplo) via IPv4, ele acaba, mas se eu tentar conectar via IPv6 ele se conecta instantaneamente. Existe algum arquivo relacionado à conectividade IPv4 que poderia causar esse tipo de comportamento? Existe uma maneira de corrigir isso sem ter que recriar a imagem do servidor?

Atualizar

Depois de ler a resposta do SYN, tentei conectar-me ao mesmo serviço (veja acima), mas usando o IP público do meu servidor (e ainda de dentro do servidor) e ele se conecta instantaneamente. O meu entendimento é que funciona porque ouve 0.0.0.0 que aceita conexões em qualquer interface. Mas conectar a partir de 127.0.0.1 ainda não funciona e nem se conectar a um serviço que escuta especificamente em 127.0.0.1. Minha conclusão seria, então, que há de fato um problema com minha interface de loopback (no IPv4). Aqui está a saída de ifconfig :

# ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:7984 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7984 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:711801 (695.1 KiB)  TX bytes:711801 (695.1 KiB)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:127.0.0.2  P-t-P:127.0.0.2  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:35812 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47530 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2568793 (2.4 MiB)  TX bytes:34332070 (32.7 MiB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:*public ip*  P-t-P:*public ip*  Bcast:*public ip*  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

Existe algo que explicaria o mau funcionamento da interface de loopback? Existe outro arquivo de log ou de configuração que eu tenha esquecido que poderia explicar ou potencialmente corrigir os problemas que estou tendo com essa interface?

Atualização 2

Uma rápida atualização para adicionar que meu servidor é um VPS no OpenVZ. De minhas (continuas) pesquisas no Google, descobri que o OpenVZ faz networking de forma um pouco diferente de outras plataformas, então estou incluindo essa informação aqui para nos guiar na direção certa. Pelo que vi, ninguém que teve um problema remotamente semelhante ao meu parece ter encontrado a solução ... (por exemplo, este post do Unix & Linux StackExchange).

    
por J-F Desrochers 09.11.2016 / 19:32

1 resposta

1

Eu apostaria que você pode se conectar ao seu IPv4. A menos que os redis atendam em 127.0.0.1:6379 , você não pode se conectar (nem telnet) ao host local.

Não está familiarizado o suficiente com o IPv6 para explicar por que isso funcionaria.

Então, novamente, eu duvido que o tráfego de proxies nginx para redis. Você pode nos mostrar o seu virtualhost (s) está / estão habilitados? É normal que seus processos python escutem 0.0.0.0 ? Em caso afirmativo, você provavelmente deve ativar as regras de firewall que você desativou.

Atualizar, lendo as atualizações do OP:

É bom ver que você encontrou algo. Enquanto isso, minha primeira observação sobre a conexão com o host local foi simplesmente errada, desculpas.

    
por 10.11.2016 / 02:16