-2

したがって、プライベート IP アドレスは 192.168.00 ～ 192.168.255.255 または 10.0.0.0 または 172.16.0.0 ～ 172.31.255.255 です。

サーバーソケットにクライアントを受け入れた場合、socket.getremotesocketaddress(); を使用してクライアントの remoteIp アドレスを取得できます。しかし、私がこの方法で取得した IP アドレスはパブリック IP アドレスのみであり、これと同じパブリック IP を使用する複数のクライアントが必要であると思われます (Web サイト www.whatismyip にアクセスしたときに表示されるようなもの)。 .com)。では、ある IP アドレスまたは個人を一意に識別するその他のものを使用して、パケットが適切な人に確実に配信されるようにするには、どうすればよいでしょうか?

4

4 に答える 4

2

この方法では、戻ってきたユーザーのマシンを確実に認識できるとは思いません。NATは、「プライベート」IP アドレスをサーバーが認識しているパブリック IP アドレスに置き換えます。MAC アドレスなどの代替識別子も、パケットがサーバーに到達するまでに失われます。

アプリケーション レベルの ID をアプリケーションに組み込む (ユーザーまたはクライアントを認証させる) か、あまり一意ではないコンテキスト識別子の組み合わせを使用します (例:ブラウザーのフィンガープリンティングなど) 。

于 2012-09-09T07:12:18.270 に答える
1

私の意見では、唯一の方法は HTTP の代わりに HTTPS を使用することです。HTTP は比較的脆弱なプロトコルです。なりすましやスパイがかなり簡単であるという評判があります。

于 2012-09-09T07:31:05.470 に答える
1

パブリック IP アドレスを使用して、パケットが適切なクライアントに配信されるようにするにはどうすればよいですか

質問は意味がありません。TCP 経由の接続を受け入れる場合、それは既に固有のクライアントに接続されています。そのクライアントと通信するために必要なことは、その接続を介してバイトを送信することだけです。正確な配信を保証するために必要なことは何もありません。

于 2012-09-09T07:13:58.043 に答える
1

では、ある IP アドレスまたは個人を一意に識別するその他のものを使用して、パケットが適切な人に確実に配信されるようにするには、どうすればよいでしょうか?

それを保証することはできません。技術的に不可能です。

できることは、パケットが間違った人またはマシンに配信された場合にパケットを読み取れないようにすることです。これは、さまざまな強力な暗号化スキームを使用して実装できます。また、アプリケーション レベルでは、HTTPS は次の条件を満たしていることを保証します。

  • クライアントは、サーバーによって提示された証明書を徹底的にチェックします。
  • サーバーの秘密鍵は漏洩しません。

通常の状況では、HTTPS サーバーにはクライアント マシンを明確に識別する方法がありません。クライアント証明書を使用してこれに対処できますが、設定には多くの労力が必要です。この IBM ノートでは、概要を説明しています。

そのため、通常の方法では、プレーンな HTTPS をアプリケーション レベルのスキームと組み合わせて使用​​し、ユーザーを認証します。たとえば、ユーザー名とパスワード、2 要素認証、バイオメトリクス、トークン ジェネレーターなどです。

しかし、このメソッドから取得している IP アドレスはパブリック IP アドレスのみであり、これと同じパブリック IP を使用する複数のクライアントが必要であると思われます...

ええ。IPv4 スペースが使い果たされていることを考えると、これは最近ますます一般的になっています。たとえば、NAT ゲートウェイは、「プライベート」IP アドレスを持つクライアントが NAT ゲートウェイ経由で外部サービスと通信できるようにします。外部サービスには、接続はクライアント アドレスとして NAT ゲートウェイの IP アドレスを持っているように見えます。「実際の」IP アドレスが何であるかを調べるためにサービスができることは何もありません。また、方法があったとしても、クライアントを一意に識別することはできません。

于 2012-09-09T09:36:08.553 に答える