失敗したローカルネットワークVNC接続をトラブルシューティングするにはどうすればよいですか？
マシンAでRemmina（0.9.3）を起動し、VNC Incoming Connectionプロファイルを作成します。ユーザー名とパスワードを使用して、ポート5900を選択しました。アドバンストまたはSSHでは変更はありません。プロファイルを開始すると、「ポート5900で着信VNCI接続をリッスンしています...」と表示されます。
マシンBでRemminaを起動し、VNCプロファイルを作成します。 machinea.local：5900をサーバーとして設定し、ユーザー名とパスワードを入力し、その他はすべてそのままにします。プロファイルを開始すると、「「username @ machinea」に接続しています...」と表示されます
忍耐は美徳ですが、30分後もまだメッセージウィンドウ以外はありません。
これまでのところ：
- UFWが有効になっていないことを確認しました
- マシンAからマシンBへ、またはその逆にpingおよびsshできることを確認しました
- 他のポートで試してみた
- ユーザー名とパスワードなしで試した
- 目的もなくグーグル
- お茶を一杯作りました
次は何ですか？
さらに実行されたアクション：
- 成功したことを確認しました
telnet machinea.local 5900マシンBから（パブロスGに感謝） - マシンAで
ifconfigを実行して、ネットワークIPアドレス（10.0.0.x）を取得します - ホスト名の代わりにIPアドレスを使用してping、telnet、およびRemminaを試行します
- 逆VNC接続をセットアップしようとしていないことを確認します
- クライアントソフトウェアをサーバーとして使用しないで使用していることを確認します（doh！）
プロトコルオプションVNC - Incoming Connectionは期待したものではないようです。
Remminaの wikiページreverse VNC connectionサポートについて説明しています。
これは、サーバーに接続するクライアントの通常の手順を逆にすることを意味します。
主にファイアウォール/ NATの問題が関係している場合に使用されます。
そのため、マシンAのremminaは、マシンBのVNCサーバーが接続するのを待っています。
したがって、remminaはサーバー側ではなく、接続のクライアント側のままです。
全体がどのように機能するかの例を示すために、次のテストを行いました。
Linuxボックスに新しい
VNC - Incoming Connectionを作成して開始しました。
今、remminaはVNCサーバーからの着信要求を待っています-VNCクライアントではありませんWindowsボックスでtightVNCサーバーを起動し、
attach listening viewerを選択し、LinuxボックスのIPアドレスとポートを追加しましたこれで、私のWindowsボックスにremminaクライアントからリモートでアクセスできます。