web-dev-qa-db-ja.com

WebRTCおよびSTUNのファイアウォールルール

企業のファイアウォールを介して、WebRTCサービスを実行しようとしています。サービスはローカルネットワーク上で機能しますが、ファイアウォールによってグローバルに機能しなくなっているようです。

Pythonaiortcパッケージのコード例を使用していますが、 here 、クライアント側とサーバー側の両方にSTUNサーバーURLを少し追加します。

クライアント側は正常に機能しているように見え、外部IPをICE候補として正しく送信します。

ただし、サーバー側はローカルアドレスを持つ候補のみを送信します。 STUNがブロックされているようです。stunclientは以下を返します。

$ stunclient --verbosity 9 --mode full --localaddr eno1 
stun.stunprotocol.org
Resolved stun.stunprotocol.org to 52.15.67.208:0
config.fBehaviorTest = true
config.fFilteringTest = true
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 52.15.67.208:3478
socketconfig.addrLocal = <MyLocalIp>:0
Sending message to 52.15.67.208:3478
Continuing to wait for response...
...
Continuing to wait for response...
Sending message to 52.15.67.208:3478
Continuing to wait for response...
...
Continuing to wait for response...
Binding test: fail
Behavior test: fail
Filtering test: fail

他のSTUNサーバーも失敗します。

これは、ファイアウォールがHTTPSに使用するポートでTCP以外の何かをブロックしていることが原因であると考えられます。

STUNとWebRTCを許可するには、ファイアウォールをどのように構成する必要がありますか？

ありがとう！

networkingfirewallweb-serviceswebrtc
2
Soren

私はstun.stunprotocol.orgおよびスタントマンコード自体のメンテナーです。たまたまここであなたの質問を少し遅れて見つけました。私は通常、stackoverflow.comで気絶する質問を監視しますが、たまにserverfaultにします。

はい、ファイアウォールがstunサーバーへのトラフィックをブロックしているようです。これは、大企業の環境では予期しないことではありません。

STUNは、デフォルトでは、TCPではなくUDPポートで動作します。 stunclientコマンドラインで--protocol tcpを指定して、違いがあるかどうかを確認できます。ただし、WebRTCはUDPモードのみを使用します。 UDPポート53（DNSと同じ）で独自のスタンサーバーをホストし、それが機能するかどうかを確認することは、おもしろいアイデアの1つです。この場合も、企業はDNSトラフィックを既知のサーバーまたは内部サーバーに制限する場合があります。

IT管​​理者への質問は、「UDPポート3478および3479でリッスンするリモートサーバーへのオープンアクセス」です。それらがこれらのポートを開いた場合、エンタープライズファイアウォールは対称的に機能するNATであり、WebRTC接続を有効にする上で優れた機能を発揮しないことがあります。YMMV。

1
selbie