O dilúvio recusa todas as conexões não locais, apesar de conexões remotas estarem habilitadas

0

Eu instalei o Deluge hoje no meu Debian 8.0 VPS. Tudo está funcionando, exceto por conexões remotas. Eu habilitei explicitamente conexões remotas com config -s allow_remote true e depois de verificar o arquivo JSON, ele ainda é mostrado como true.

Apesar disso, recusará todas as conexões não originadas de loopback. O servidor está listado como offline no meu cliente remoto e um verificador de porta retorna Porto fechado , enquanto netstat -npl definitivamente mostra que há um soquete escutando naquela porta e ps -p que na verdade é Deluge escutando.

root@vps:~# netstat -npl
...
tcp        0      0 127.0.0.1:58846         0.0.0.0:*               LISTEN      946/python
...
root@vps:~# ps -p 946
  PID TTY          TIME CMD
  946 ?        00:00:19 deluged

Pode ser um problema com iptables, mas eu não estou familiarizado com isso nem nunca mudei nada nele.

— FallenWarrior
fonte

0

O problema está bem aqui no seu post

tcp        0      0 127.0.0.1:58846         0.0.0.0:*               LISTEN      946/python
                    /\

você está apenas ouvindo 127.0.0.1, você terá um arquivo de configuração em algum lugar, para o seu inundado aplicação, que especifica a quais endereços IP se ligar.

Se você estivesse ouvindo corretamente em todas as interfaces, seria algo parecido com isto

tcp        0      0 0.0.0.0:58846         0.0.0.0:*               LISTEN      946/python

editar

Olhando para alguma documentação , você também pode precisar definir

"allow_remote": true

Na tua $HOME/.config/deluge/core.conf Arquivo.

Depois de fazer essa alteração, tente reiniciar o serviço e veja se isso corrige a ligação.

— Matt Clark
fonte

Percebi a estranheza no netstat, essa foi a razão exata que eu perguntei aqui. Eu tentei tudo isso e posso confirmar que os valores são "allow_remote": true e listen_interface: "0.0.0.0" no arquivo de configuração localizado na página inicial dos usuários do dilúvio. Depois de confirmar isso eu reiniciei o serviço e olhei de novo, sem sucesso.

— FallenWarrior

Verificar novamente o problema parecia ser um serviço quebrado. Eu comecei manualmente e funcionou bem.

— FallenWarrior

0

Eu tive o mesmo problema que você. Acabei mudando o core.conf, como segue, para resolver o problema ...

"listen_interface": "", "allow_remote": true

— MikeA
fonte