☰

LinuxサーバーはJavaクライアント接続を拒否します。

tag-icon • tag-icon linux networking iptables java
LinuxサーバーはJavaクライアント接続を拒否します。

私はJavaサーバーとクライアントを持っていますが、クライアントが通信するときにメッセージを印刷する単純なサーバーです。クライアントとサーバーが同じマシン上にある場合は正常に動作します。クライアントを別のシステムにデプロイすると、次の例外が発生します。

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)

クライアント以外のコンピュータでサーバーを実行してみましたが、正常に動作しました。したがって、クライアントがそのポートに接続することを許可しないシステムにはいくつかの問題があります。クライアントがサーバーにpingしようとしましたが、サーバーに接続できました。ファイアウォールはオフsudo /etc/init.d/iptables stopですが、クライアントはまだサーバーに接続できません。どんな助けでも大変感謝します！

答え1

「接続が拒否されました」とは、TCP接続がサーバーに到達したことを意味します（またはクライアントとサーバー間のファイアウォールによって明示的にブロックされます）。後者が真実ではないと仮定すると、3つの可能性があります。 1. クライアントの IP がサーバー・プロセスではなく、プロセスが IP またはインターフェースを受信して​​いるため、オペレーティング・システムは接続を拒否します。 2. サーバープログラムは内部的に要求をフィルタリングするため、接続を明示的に拒否します。 3. サーバーに要求を拒否する別のファイアウォールプロセスがあります。

まず、サーバープロセスが有効なIP /ポートでリッスンしていることを確認してください。

sudo netstat -apn | grep "server process name"

次のような応答が必要です（例：smbd - Sambaの「サーバープロセス名」）。

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

「192.168.10.1:139」を参照してください。クライアントが接続している特定のIPまたは0.0.0.0:139（すべてのインターフェイス、すべてのローカルIPを意味）を確認したいと思います。 127.0.0.1またはクライアントが接続できないIPが表示された場合は、問題があります。

第二に、サーバープログラムが特定のホストからの着信接続を内部的にブロックしていないことを確認してください。 （サーバーが何であるかについての情報を提供していないため、これについてはあなたに任せる必要があります。）

最後に、サーバープロセスがクライアントにアクセスできる有効なインターフェースを受け取り、サーバープログラムが着信接続をフィルタリングしていないことが確認された場合は、デフォルトに戻ります。

1 - 要求がサーバーに到達していることを確認します。ここで、eth0 および tcp ポートは環境に合わせて変更されます。

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

2つの交通経路が表示されます。

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)

192.168.10.10.24411(クライアント)および">" 192.168.10.1.139(サーバー)は、TCP SYN(->[S])パケット表示[S]を使用します。

TCPダンプに表示される次のパケットには、[R.]フラグ（リセット - 接続拒否）が含まれている可能性があります。

したがって、SYNが表示されRSTが表示されると、サーバーは確実に接続をブロックしています。デバッグモードでサーバープログラムを実行して、何が起こっているのかを確認できます。

SYNパケットが表示されない場合（そしてtcpdumpで指定されたtcpポートとインターフェイスを再確認した場合）、ファイアウォールがあるか、クライアントとサーバー間にルーティングの問題がある可能性があります。

頑張ってください。

答え2

この例外は、通常、接続しようとしているポートでリッスンするサービスがない場合に発生します。次のことが発生する可能性があります。

  1. まだサーバーを起動していません。
  2. サーバーが接続の受け入れを待っていません。
  3. 無効なポート番号に接続しようとしています。

関連情報