4

.NETCF 3.5 で記述されたアプリケーションで Windows CE5 を実行するスマート デバイスがいくつかあります。スマート デバイスは、統合された GPRS モデムを使用してインターネットに接続されています。クライアントはリモート サポート オプションを希望していますが、VNC や同様のツールではその仕事ができないようです。VNC を機能させるには、いくつかの問題が見つかりました。まず、スマート デバイスで実行すると、深刻なパフォーマンスの問題が発生します。2 つ目の問題は、インターネット プロバイダーが、スマート デバイス自体から発信されたものではない場合、すべての着信要求をブロックするファイアウォールを持っていることです。したがって、要求がスマート デバイスから発信されたものではないため、スマート デバイスとのリモート デスクトップ セッションを開始できません。

独自の APN を取得することもできますが、それらは高すぎます。また、導入したスマート デバイスの量に対して毎月のコストが高すぎます。お客様は月々の高額な費用を嫌い、代わりに多額の前払いを行うため、製品の初期費用に開発費を上乗せできれば経済的です。リモート サポート ソリューションにより、オンサイト サポートを最小限に抑えることもできます。

そのため、多かれ少なかれ独自のリモート デスクトップ ソリューションを導入することにしました。スマート デバイスで画像をキャプチャするためのコードがあり、最後のサイクル以降に変更されたデータのみを取得します。必要なのは、logmein.com (WinCE5 をサポートしていません) のような通信ソリューションを作成することです。そこでは、スマート デバイスがサーバーに接続され、そこからデータをサポート担当者のクライアントにストリーミングできます。基本的に、スマート デバイスはサーバーへの接続を開始し、サーバーが要求したときに画面データの配信を開始します。サポート クライアントはサーバーに接続し、利用可能なストリームのリストを取得してから、リッスンするストリームを選択します。

スマート デバイスで .NETCF 3.5 でソリューションを実行する必要があることを考慮して、その方法について何か提案はありますか? 私たちは、単純な石鹸の Web サービスを超えた限られたコミュニケーション経験しかありません。

4

1 に答える 1

2

あなたは提案を求めているので、私はこれを提案します：

再発明しないでください。使えるものは再利用。SSH でトンネリングを実行できるので、スマート デバイスで GPRS 経由で SSH 接続 (たとえば、ループ内の PuTTY または plink のポート) を作成します。リモート ポートをローカル ポートに転送し、SSH サーバーのローカル アドレス (127.0.0.1 (sshd):4567 => localhost (smart_device_01):4567) にバインドします。クライアントは SSH サーバーに接続し、各デバイスに割り当てられたポートにアクセスします。

そうは言っても、それはおそらくあなたが探している答えではありません。以下 - あなたがおそらく探している答え。

LogMeIn の仕組みに関する私の分析に基づいて、スマート デバイスがデータをプッシュする HTTPS または TLS サーバーを作成する必要があります。これをトンネル サーバーと呼びましょう。

おそらく、トンネル サーバーへの接続 (指定された要件に従って、スマート デバイスからサーバーへのアウトバウンド接続) への接続を繰り返し試行する新しいスレッドを生成する必要があります。BEEP/BXXP のようなプロトコルを使用すると、メッセージ指向またはストリーム指向のセッションをカプセル化して多重化できます。BXXP/BEEP を TLS にラップし、トンネル サーバーにトンネリングします。BEEP を使用すると、ストリームを 1 つの接続に多重化できます。社内の LogMeIn ソリューションの全機能が必要な場合は、このようなものを使用することをお勧めします。

接続が確立されたら、新しい BEEP セッションを作成します。新しいセッションで、トンネル サーバーにシステム識別情報 (デバイス名、デバイス認証署名) を伝えます。この新しいセッションにハートビート データ (タイムスタンプを定期的に) を書き込みます。

BEEP コントロール セッションに接続するコールバック (または別のスレッド) をセットアップします。メッセージ要求サービスを監視します。このようなリクエストが届いたら、必要なスレッドを生成して、カスタム リモート表示プロトコルからデータをコピーし、このデータを同じチャネル経由でプッシュします。

これにより、スマート デバイスのプログラムの基本的な前提が設定されます。たとえば、LMI の IT Reach サブスクリプションが提供するものと一致するように、必要に応じてこれに機能を追加できます (リモート レジストリ、安全なトンネル Telnet、リモート ファイルシステム、リモート印刷、リモート サウンド...おわかりでしょう)。

クライアントの認証と承認のために、これらすべてのものを適切に保護する方法を知っていることを前提としています (ユーザー foo はスマート デバイス バーへのアクセスを許可されていますか?)。

トンネル サーバーで、接続とセッションを逆多重化するサーバー ソケット (インバウンド接続をリッスンするか、スマート デバイスの観点からはスマート デバイスのアウトバウンド接続をリッスンする) を開始します。接続が開かれたら、BEEP を起動してコールバックを登録し、認証/ハートビート セッションを待機するスレッドを開始します。スマート デバイスへの AAA に必要なチェックを実行します。これらのデバイスは許可されているか、認識されているか、コストはどれくらいかなど です。トンネル サーバーは、スマート デバイスに代わってデータを転送します。 BEEP セッションごとに、AAA 手順が成功した後で BEEP セッションに名前 (デバイス名) を付加します。失敗した場合は、接続を閉じて AAA メカニズムに知らせます (攻撃者をブロックするため)。トンネル サーバーは、フロントエンドとのやり取りに必要なものもセットアップする必要があります。つまり、BEEP とやり取りして、リモート表示データのストリームを逆多重化するコードが必要です。

フロントエンド サーバー (トンネル サーバーと同じボックスでもかまいません) に、AAA のルーチンをインストールします。ユーザーが既知かどうか、ユーザーが許可されているかどうか、ユーザーに請求する金額などを確認します。が渡されたら、フロントエンド サーバーからトンネル サーバーへの安全な接続を確立します。ユーザーがアクセスを許可されていることをトンネル サーバーが認識しているデバイス名を取得します。この時点で、デバイス名に基づいて、トンネル サーバーから「プレーンテキスト」ストリームを取得できるはずです。このストリームを (たとえば TLS を介して、または再び BEEP over TLS を介して) ユーザーに転送するか、リモート ディスプレイ クライアントがトンネル サーバーに接続するために必要な構成を送信し、リモート ディスプレイ プロトコルのストリームにアクセスするために必要なパラメーターを指定します。

于 2012-12-25T05:22:03.680 に答える