マシン 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 Connection
Linuxボックスに新しいを作成し、起動しました。
現在、Remminaは、VNC サーバー - VNC クライアントではありませんWindowsボックスでtightVNCサーバーを起動し、
attach listening viewer
LinuxボックスのIPアドレスとポートを選択して追加しました現在、私の Windows ボックスは、Remmina クライアントからリモートでアクセスされています。