0

サーバーアプリケーションの基礎を特定しようとしています..

1 tcp および/または udp パケットを「受信」
する 2 内容を解釈する (つまり、ヘッダー値)

さらに詳細を追加すると、このサーバーは「sip 招待」を受信し、「302 リダイレクト」で応答します。

私は Net::Pcap と perl の経験があり、フィルタリングされたパケットをループし、デコードし、Net::SIP のようなものを使用して応答することでこれを達成できることを知っています。

ただし、必要のないこれらのモジュール/アプリケーションの両方に多くの肥大化があります。サーバーには大きな負荷がかかります。TCPDUMP を単独で実行すると、サーバーの負荷が原因でカーネル内のパケットが失われるため、適切ではないのではないかと心配してください :(

ソケットを「リッスン」して (たとえば IO::Socket を使用して)、パケットをデコードすることで、同じことを達成できるはずですか?

残念ながら、デバッグでは、IO::Socket が生のパケットを見る機会を与えてくれるかどうかを判断するのは難しいですか? 代わりに、メッセージを読み取り可能な形式に自動的にデコードします。

tl;dr:たくさんの SIP Invites をキャプチャし、head の値を分析して、SIP 302 リダイレクトで応答したいと考えています。これを達成するために (Net::Pcap 経由で) tcpdump を使用するよりも良い方法はありますか?

ありがとう、ムース

4

1 に答える 1

1

これを達成するために (Net::Pcap 経由で) tcpdump を使用するよりも良い方法はありますか?

はい。libpcap を使用する (その質問で tcpdump の代わりに意味したことです) は、TCP ベースのサービスを実装するには悪い方法です。TCP の多くを自分で再実装する必要があるためです (libpcap は生のネットワーク層パケット提供します)。プログラムはマシンのインターネット プロトコル スタックにも配信されるため、次のようになります。

  • 他のマシンが接続しようとしている TCP ポートでリッスンしているマシンが何もない場合、接続要求は TCP コードから RST を取得し、接続の試行が失敗したと見なします。
  • そのポートでリッスンしているマシンに何かがある場合、おそらく接続を受け入れ、それとプログラムの両方が他のマシンと通信しようとします。これにより TCP スタックが混乱し、さまざまな悪いランダムなことが発生します。起こる。

UDP の場合はあまり良くありません。

  • 他のマシンが接続しようとしている UDP ポートをリッスンしているマシンが何もない場合、接続要求はおそらく UDP コードから ICMP Port Unreachable メッセージを取得し、接続試行が失敗したと見なす可能性があります。
  • そのポートでリッスンしているマシンに何かがある場合、おそらく接続を受け入れ、それとプログラムの両方が他のマシンと通信しようとします。これによりおそらく SIP スタックが混乱し、さまざまな悪いランダムなことが発生します。起こる。

IO:Socketおそらく生のパケットは提供されませんが、それは良いことです。独自の IP および TCP/UDP スタックを実装する必要はありません。マシンにリダイレクト サーバーを実装することが目標の場合、生のパケットを受信する必要はありません。マシンの IP/TCP/UDP スタックによってすべての下位レベルの処理が行われた SIP INVITE を受信したい場合。

マシンに既に SIP 実装があり、その「ファイアウォール」として機能させたい場合は、一部の INVITE に対して 302 リダイレクトを送り返し、マシンの SIP 実装が INVITE を認識しないようにします。問題は、特定の OS がファイアウォールを実装するために使用するのと同じメカニズムを使用する必要があることです。私の知る限り、これらのメカニズム用の libpcap のようなラッパーはありません。

于 2013-07-31T20:22:48.633 に答える