Conexão de Cliente Java Recusada pelo Servidor Linux

Question

Eu tenho um servidor e cliente Java, que é um servidor simples que imprime uma mensagem quando o cliente se comunica com ela. Ele funciona perfeitamente quando o cliente e o servidor estão na mesma máquina. Quando coloco o cliente em uma máquina diferente, recebo a seguinte exceção:

java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method)
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
    at java.net.Socket.connect(Socket.java:579)
    at java.net.Socket.connect(Socket.java:528)
    at java.net.Socket.<init>(Socket.java:425)
    at java.net.Socket.<init>(Socket.java:208)
    at DateClient.main(DateClient.java:16)

Eu tentei executar o servidor em uma máquina diferente (que não é o cliente) e funciona bem. Portanto, há algo sobre a máquina que não permitirá que o cliente se conecte à porta. Eu tentei pingar o servidor do cliente e é capaz de alcançar o servidor. Eu desliguei o firewall usando sudo /etc/init.d/iptables stop , mas o cliente ainda não consegue se conectar ao servidor. Qualquer ajuda seria apreciada!

    

Answer 1

Esta exceção geralmente ocorre quando não há serviço escutando na porta que você está tentando se conectar. Qualquer uma dessas coisas pode estar acontecendo:

1. Você não iniciou seu servidor.
2. Seu servidor não está esperando para aceitar conexões.
3. Você está tentando se conectar ao número de porta errado.

Answer 2

"Conexão recusada" significa: A conexão TCP chega ao servidor (ou está sendo explicitamente bloqueada por um firewall entre o cliente e o servidor), assumindo que a última não é verdadeira - existem 3 possibilidades: 1. O IP ao qual o cliente está se conectando não é o IP ou a interface em que o processo do servidor está escutando, portanto, o sistema operacional rejeita a conexão. 2. O programa do servidor está rejeitando explicitamente a conexão porque está internamente filtrando a solicitação 3. Há outro processo de firewall no servidor que está rejeitando a solicitação.

Primeiro, verifique se o processo do servidor está escutando em um IP / PORT válido:

sudo netstat -apn | grep "server process name"

Você deve obter uma resposta como (para um exemplo de "nome do processo do servidor" do smbd - Samba):

user@host:~# sudo netstat -apn | grep smbd
tcp        0      0 192.168.10.1:139        0.0.0.0:*               LISTEN      7721/smbd

Observe o "192.168.10.1:139" - você vai querer ver o IP específico ao qual seu cliente está se conectando, ou 0.0.0.0:139 (o que significa todas as interfaces, todos os IPs locais). Se você vir 127.0.0.1 ou um IP que não pode ser acessado pelo cliente, seu problema está aí.

Em segundo lugar, verifique se o seu programa de servidor não bloqueia internamente as conexões de entrada de determinados hosts (já que você não deu nenhuma informação sobre o que é o servidor, eu vou ter que deixar isso para você)

Por último, se tiver certeza de que o processo do servidor está escutando em uma interface válida que pode ser acessada pelo cliente, e o programa do servidor não está filtrando conexões de entrada, volte para o básico:

1- Validar se o pedido está atingindo o servidor, onde eth0 e a porta tcp mudariam para se adequar ao seu ambiente:

sudo tcpdump -i eth0 -n -v tcp port 139

Você verá o tráfego de duas vias:

user@host:~# sudo tcpdump -i eth1 -n -v tcp port 139
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
12:27:45.339982 IP (tos 0x0, ttl 128, id 12153, offset 0, flags [DF], proto TCP (6), length 52)
  192.168.10.10.24411 > 192.168.10.1.139: Flags [S], (output cut)

Observe que o 192.168.10.10.24411 (o cliente) fala com ">" 192.168.10.1.139 (O servidor) Flags [S] com um pacote TCP SYN (- > [S])

O próximo pacote mostrado pelo TCP dump provavelmente terá sinalizadores de [R.] (Reset - conexão recusada)

Então, a partir daí, se você vir o SYN, o RST - Server está definitivamente bloqueando a conexão, talvez execute o programa do servidor no modo de depuração para mostrar o que está acontecendo.

Se você não vir aquele pacote SYN (e você verificou novamente a porta tcp e a interface que especificou para o tcpdump), então você tem um firewall ou talvez um problema de roteamento entre o cliente e o servidor.

Boa sorte.