conexão recusada no localhost

0

No CentOS 7 Eu estou tentando abrir conexões para alguns serviços no meu localhost usando HTTP e TCP / UDP direto (servidor web, db, etc) mas eu continuo recebendo conexão recusada em portas que não são 8080 ou 80 .. . (ps: ssh para a porta 22 funciona bem btw).

Aqui está o que eu tentei até agora:

Eu verifiquei o status do selinux ..:

[root@ ~]# sestatus
 SELinux status:                 disabled

Então eu verifiquei por firewalls

[root@ ~]# systemctl status firewalld
● firewalld.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
[root@ ~]# systemctl status iptables
● iptables.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

Então, se não é selinux nem firewalls, o que devo procurar?

Aqui está o que é a saída do netcat (observe que funciona bem em 8080 e 80) Nota: o ^C é apenas para indicar o sinal de interrupção porque nc conectou

[root@ ~]# nc localhost 8080
^C
[root@ ~]# nc localhost 80
^C
[root@ ~]# nc -v localhost 5544
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connection to ::1 failed: Connection refused.
Ncat: Trying next address...
Ncat: Connection refused.
[root@ ~]# nc -v 127.0.0.1 25544
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connection refused.

ss -vtnlp | grep :5544 também não me dá nada (e meu serviço do outro lado continua recusando conexão).

Obrigado por qualquer ajuda!

    
por Fawix 22.12.2016 / 21:46

1 resposta

1

Acontece que o serviço que deveria ouvir as conexões não estava escutando! Depois de mover o serviço para uma porta muito mais alta, agora está funcionando, mas não sei por que isso aconteceria. (O abaixo é truncado)

[root ~]# ss -tnlp | grep :35544
LISTEN     0      50          :::35544 

Talvez isso ajude os outros:

o principal indicador (que eu perdi totalmente) era que o comando ss -tnlp não estava listando a porta que eu esperava ser listada.

Além disso, ao fazer ss -tnlp | grep :port , o resultado estava vazio e isso significava que a porta não estava "aberta para conexões", portanto, a conexão recusava a mensagem de erro.

No meu caso, o processo foi logstash, que não causou um único erro sobre não ser capaz de ouvir a porta.

    
por 23.12.2016 / 16:44