7

UDPプロトコルを実装する必要があります。PCは、着信パケットを専用のUDPポートでリッスンする必要があります。また、パケット（回答）を送信します。アプリケーションはWindowsXP、7、8、...で実行されます。

Windowsファイアウォールは、着信パケットをブロックします。これは、UDPホールパンチングによって回避できます。だから私は傷つけてはいけない何かを送らなければなりません。しかし、私はできるだけ邪魔をしたくない。

  • ファイアウォールが穴を閉じるまでのタイムアウトをどのように判断できますか？
  • ファイアウォールがファイアウォールを閉じたため、パケットを開くために再送する必要があることを検出できますか？もちろん、ファイアウォールが閉じているときは何も受信しませんが、これには他の理由がある可能性があります。
4

3 に答える 3

4

これが私がnetcatでこれを測定した方法です：

私のUnixホスト（Mac OS X Darwin）では、ファイアウォールはありません（または、Windowsファイアウォールでnetcat "nc"実行可能ファイルがUDPポートでリッスンできるWindowsマシンでは）、リモートクライアントから提供される可変遅延でUDPサーバーを実行します。

WINHOST=10.116.140.69
mkfifo f
nc -u -p 2222 $WINHOST 6666 < f | \
(while read secs; do for sec in $secs; do echo sleep $sec 1>&2; sleep $sec; echo SLEPT $sec; echo SLEPT $sec 1>&2; done; done) > f

私のWindowsホスト（Windows 7 Professional SP1 64ビット）であるWindowsファイアウォールでは、シェルとネットキャットを提供するためにcygwinがインストールされており、UDPクライアントをインタラクティブに実行します。

UNIXHOST=192.168.181.1
nc -u -p 6666 $UNIXHOST 2222

cygwinを使用する必要はありません。Windows netcatは正常に動作するはずですが、コマンドラインは異なる場合があります。

次に、そのクライアントに一連のテスト間隔を入力し、サーバーがスリープしてから応答するのを観察し、クライアントが応答を受け取るかどうかを観察します。これらは機能しました：1、2、10、60、120、180。その後、これは失敗しました：240。180から240の間の二分探索を続行します。

例1：クライアント側で、次のように入力します。

10
60
120
180
240

そして、最大180の要求/応答遅延が機能するのに対し、240は機能しないことに注意してください。

例2：クライアント側で、次のように入力します。

180
181
182
182

そして、最大181の要求/応答遅延が機能するのに対し、182は機能しないことに注意してください。

例3：クライアント側で、次のように入力します（すべて同じ行に）：

180 180 180 181 181 181 182 182 182 183 183 183

これは、クライアントから1つのUDP要求を生成し、次に180、181、182、または183秒間隔で区切られた一連の応答を生成します。最大181の要求/応答遅延が機能し、さらに、最大181秒間隔での継続的な応答（新しい要求なし）も機能することが観察されました。

したがって、ファイアウォールホールには、非アクティブが初期応答の遅延であるか、その後の追加トラフィックの遅延であるかに関係なく、非アクティブタイマーがあります。

複数のマシンでの結果：

  • そのWindows7Professional SP1 64ビットデスクトップでは、UDP応答ホールが181秒間開いています。2つのシステムは別々のネットワーク上にあるため、2つのシステム間のネットワークファイアウォールも測定している可能性がありますが、ファイアウォールではなくルーティングされていると思います。いずれにせよ、このシステムではWindowsファイアウォールの穴は少なくとも181秒です。
  • 別のWindows7Professional SP1 64ビットラップトップ、同じネットワークセグメント（ファイアウォールが介在しないことは間違いありません）、UDP応答ホールは64秒間開いています。

さまざまなOSレベルとファイアウォール構成で他のWindowsマシンで同様の測定値を確認したいと思います。

于 2014-02-20T16:58:59.993 に答える
2

穴あけに関するいくつかのヒント：

  1. ほとんどのファイアウォール（私はWindowsファイアウォールも想定しています）では、穴あけは特定のIPのみが接続を許可します。ホールパンチングは、ファイアウォール/ NATをだまして、特定のIPと通信していると思い込ませ、そのIPからパケットが戻ってくるようにします。IPを聞きたい場合は、接続を調整できるブリッジコンピュータなしではホールパンチングを使用できません。
  2. タイミングはファイアウォールやNAT間で異なる場合があります。ソフトウェアファイアウォール（Windowsファイアウォールなど）だけでなく、ハードウェアファイアウォールやNATデバイスがある場合は、そのタイミングについても心配する必要があります。非常に特殊なネットワークとソフトウェアのセットアップがない限り、値のハードコーディングは機能しません。ファイアウォールが穴を塞いだことを検出することは素晴らしいアイデアのように聞こえますが、ほとんどのファイアウォール/ NATには、それらが穴を塞いだことを検出する方法がなく、私が知る限り、あなたにとって良い方法はありません。それを検出するプログラム。
  3. 穴あけを行うには、機能のないパケットを送信する必要があります。これらは通常、目的のないNOP（No OPeration）またはKEEP_ALIVEパケットであり、プログラムが1つを受信すると、それを破棄するだけです。

私の提案は、クライアントプログラムが無視するKEEP_ALIVEパケットを実装し、ファイアウォールを開いたままにするためにサーバーに定期的にKEEP_ALIVEパケットをクライアントに送信させることです。これは、クライアントのIPを知っていることを前提としているため、KEEP_ALIVEパケットを送信できます。クライアントのIPをまだ知らない場合は、公的にアクセス可能なブリッジコンピュータをセットアップするか、サーバープログラムのファイアウォールを無効にする必要があります。Windowsファイアウォールには、プログラムが接続をリッスンできるようにするために使用できるCOMAPIまたはnetshコマンドがあります。ハードウェアファイアウォール/NATの場合は、UPNPを使用してみてください。それでも問題が解決しない場合は、ユーザーにプログラムの特定のポートを開くように要求するのが最善の方法です。

于 2013-02-23T18:08:52.163 に答える
1

私自身の質問に答えるには：タイムアウトを決定する方法はありません。Windows7ファイアウォールがUDP接続に使用するタイムアウトを実験する必要があります。現在のエクスペリエンスでは4秒のタイムアウトが表示されますが、これは異なる場合があります。

穴あけの一般的なヒント：

  1. ネットワーク内の他のホストを妨害しないでください。害のない内容のパケットを送信します。
  2. 応答の送信者にしたいホストに送信する必要はありません。
  3. 送信者にしたいUDPポートに送信する必要はありません。任意のUDPポートに送信します。送信したものをすべて無視する破棄ポート（9）があります。
  4. パケットが実際に送信されていることを確認してください。前回見られなかったホストに送信しようとすると、IPスタックはARPプロトコルを使用してMACアドレスを取得します。IPスタックがARP応答を受け取らない場合、IPパケットを送信できず、穴が開けられません。この問題は、ネットワークブロードキャストアドレスに送信することで回避できます。
  5. 適切なアダプタのブロードキャストアドレスを使用して、必要なネットワークに穴を開けてください。
于 2013-02-23T19:25:41.697 に答える