VNC ポート ガイド: ポート 5900 でのリモート デスクトップ アクセス

VNC を使用すると、視聴者はネットワーク経由でリモート グラフィカル デスクトップを制御できます。ビューアは VNC サーバーに接続し、RFB プロトコルをネゴシエートして認証し、画面の更新、キーボード入力、マウス入力、クリップボード データ、およびサーバーの実装に応じてファイル転送機能を交換します。

VNC は、Linux デスクトップ、macOS 画面共有、組み込みシステム、ラボ マシン、ジャンプ ホスト、およびリモート サポートに使用されます。 TigerVNC、TightVNC、RealVNC、UltraVNC、x11vnc、noVNC などのさまざまな実装では、さまざまなデフォルトとセキュリティ オプションを使用できるため、実際のリスナーと構成を常に確認してください。

通常の VNC ポートは、ディスプレイ :0 の TCP 5900 です。従来の VNC 表示表記では、表示番号が 5900 に追加されます。つまり、:1 は 5901 にマップされ、:2 は 5902 にマップされます。一部のビューアでは、クライアント インターフェイスに応じて、ユーザーが host:5901 または host:1 を入力できます。

すべての VNC サーバーが表示規則に従っていると想定しないでください。多くのサーバーは、カスタム TCP ポート、リバース接続モード、Web プロキシ、または SSH トンネルを使用して構成できます。サーバー設定、ファイアウォール ルール、およびリスナー チェックを使用して、実際のポートを確認します。

VNC、RDP、SSH は、さまざまなリモート アクセスの問題を解決します。 VNC は、RFB プロトコルを使用して、通常はポート 5900 でグラフィカル デスクトップを共有または作成します。 RDP は Microsoft リモート デスクトップで、通常はポート 3389 を使用します。 SSH はポート 22 のセキュア シェル プロトコルであり、VNC のトンネルを作成するためによく使用されます。

Windows リモート デスクトップ ワークフローの場合、通常、RDP はより統合されています。クロスプラットフォームのグラフィカル アクセスの場合、VNC は柔軟性があります。安全な管理を実現するには、特に VNC 自体がローカルホストにバインドされ、SSH トンネル経由でアクセスされる場合、SSH がより安全な外部アクセス パスとなることがよくあります。

信頼できるユーザー、サポート ツール、自動化ワークフロー、ラボ ネットワーク、またはプライベート管理パスがグラフィカル リモート デスクトップ アクセスを必要とする場合にのみ、VNC を開きます。一般的なケースには、リモート Linux デスクトップ サポート、キオスク メンテナンス、組み込みデバイス管理、プライベート ラボ アクセスなどがあります。

VNC をインターネット全体に公開することは避けてください。パブリック VNC ポートは、ブルート フォース攻撃、弱いパスワード攻撃、デスクトップ乗っ取りの試み、古いサーバーのスキャンを引き起こす可能性があります。リモート アクセスが必要な場合は、VNC を VPN、SSH トンネル、ゼロトラスト アクセス レイヤー、要塞、またはソース IP ホワイトリストの背後に配置します。

まず、どの VNC サーバーが実行されているか、どのインターフェイスでリッスンしているか、どの VNC サーバーが使用しているディスプレイ ポートまたは TCP ポートを確認します。次に、信頼できる送信元ネットワークからの正確なポートのみを許可します。表示:0 の場合、通常は TCP 5900 です。表示:1 の場合、通常は TCP 5901 です。

ルーターでは、強力な理由と狭い送信元ポリシーがある場合にのみ、外部ポートを内部 VNC ホストに転送します。サーバー上で、ホスト ファイアウォール、クラウド セキュリティ グループ、VPN ポリシー、および VNC サーバー バインド アドレスを調整し、意図したパス経由でのみサービスに到達できるようにします。

まず、パブリック ホスト名または IP アドレスとポート 5900、または構成したカスタム VNC ポートに対する外部ポート チェックを行います。ポートが開いている場合、リモート クライアントは TCP リスナーに到達できます。次に、実際の VNC ビューアを使用してテストして、プロトコル ネゴシエーション、認証、デスクトップ アクセス、画面の更新を確認します。

サーバー上で、ss、netstat、lsof、PowerShell、または VNC サーバー ステータス ページを使用してリスナーを確認します。 VNC が SSH 経由でトンネリングされている場合は、最初に SSH 接続をテストし、次にローカルの転送ポートとビューア ターゲットを確認します。

VNC ポートが閉じている場合、サーバーは停止するか、ローカルホストのみにバインドされるか、別のディスプレイでリッスンするか、ホストのファイアウォールによってブロックされる可能性があります。チェックがタイムアウトした場合、ルーター、クラウド ファイアウォール、VPN ポリシー、ISP フィルター、または送信元 IP 制限により、パケットがホストに到達する前にパケットがドロップされている可能性があります。

ポートは開いているがビューアが接続できない場合は、ディスプレイ番号、プロトコル バージョン、パスワード ポリシー、暗号化要件、サーバー側のアクセス ルール、デスクトップ セッション状態、および VNC サーバーがビューア ネットワークからの接続を許可しているかどうかを確認してください。一部のサーバーは、デスクトップ セッションが使用できない場合にクライアントを拒否します。

インターネットへのアクセスには VNC パスワードのみに依存しないでください。 VPN、SSH トンネル、プライベート ネットワーク、またはゼロトラスト アクセスを優先し、トンネリング時に VNC をローカルホストにバインドします。強力な一意の認証情報を使用し、未使用のアカウントを無効にし、VNC サーバーにパッチを適用した状態に保ちます。

サーバーとビューアが暗号化をサポートしている場合は暗号化を有効にし、ソース IP を制限し、失敗したログインを監視し、クリップボード、ファイル転送、または無人アクセスを無効にする必要があるかどうかを確認します。 VNC を単純なステータス エンドポイントとしてではなく、完全なデスクトップ アクセスとして扱います。