失敗したローカル ネットワーク VNC 接続をトラブルシューティングするにはどうすればよいですか?

失敗したローカル ネットワーク VNC 接続をトラブルシューティングするにはどうすればよいですか?

マシン A で、Remmina (0.9.3) を起動し、VNC 着信接続プロファイルを作成します。ユーザー名とパスワードを使用してポート 5900 を選択しました。詳細設定または SSH では変更はありません。プロファイルを起動すると、「ポート 5900 で着信 VNCI 接続をリッスンしています...」と表示されます。

マシン B で、Remmina を起動し、VNC プロファイルを作成します。machinea.local:5900 をサーバーとして設定し、ユーザー名とパスワードを入力し、その他はすべてそのままにします。プロファイルを起動すると、「'username@machinea' に接続しています...」というメッセージが表示されます。

忍耐は美徳ですが、30 分経ってもメッセージ ウィンドウ以外は何も表示されません。

これまで私は次のことをやってきました:

  • UFWが有効になっていないことを確認しました
  • マシンAからマシンBへ、またその逆方向へpingとsshが実行できることを確認
  • 他のポートでも試してみた
  • ユーザー名とパスワードなしで試しました
  • 目的もなくグーグル検索
  • お茶を一杯淹れた

次は何ですか?

さらなる措置:

  • telnet machinea.local 5900マシン B から正常に実行できることを確認済み(Pavlos G. さん、ありがとうございます)
  • マシン A で実行してifconfigネットワーク IP アドレス (10.0.0.x) を取得します。
  • ホスト名の代わりにIPアドレスを使用してping、telnet、Remminaを試みる
  • リバースVNC接続を設定しようとしていないことを確認してください
  • クライアント ソフトウェアをサーバーとして使用しようとしていないことを確認してください (残念!)

答え1

プロトコル オプションがVNC - Incoming Connection期待どおりではないようです。

レミナのウィキページreverse VNC connectionサポートについて語ります。

これは、クライアントがサーバーに接続する通常の手順を逆にすることを意味します。
これは主に、ファイアウォール/NAT の問題が関係する場合に使用されます。

つまり、マシン A 上の remmina は、マシン B 上の VNC サーバーが接続するのを待機しています。
したがって、remmina は接続のクライアント側であり、サーバー側ではありません。

全体がどのように機能するかの例を示すために、次のテストを作成しました。

  • VNC - Incoming ConnectionLinuxボックスに新しいを作成し、起動しました。
    現在、Remminaは、VNC サーバー - VNC クライアントではありません

  • WindowsボックスでtightVNCサーバーを起動し、attach listening viewerLinuxボックスのIPアドレスとポートを選択して追加しました

  • 現在、私の Windows ボックスは、Remmina クライアントからリモートでアクセスされています。

関連情報