私は Amazon Alexa デバイスをいくつか (Echo 1 台、Dot 2 台) と Belkin Wemo スマート スイッチを持っています。Alexa アプリを使用すると、スマート ホーム デバイスをスキャンでき、見つかったものはすべて自動的に追加されます。これは通常、アプリ、Amazon、デバイスのネットワーク クラウド間の通信によって処理されますが、どうやら Wemo では特に SSDP デバイス検出が使用されるようです。Alexa はほぼ毎回 Wemo を見つけます。
実際、IFTTT から Wemo へのリモート コントロールを許可している間は、失敗してほしいと思っています。はい、奇妙な使用例であることは承知しています :) 最初に試したのは、セカンダリ ネットワークをセットアップして Wemo をそこに接続することでした。しかし、何らかの理由で、Wemo とルーターはそのネットワーク上で 1 分以上接続されたままになりません。そのため、私はそれをあきらめて、ファイアウォール ルールを使用して実行しようとしましたが、これは私の得意分野からは程遠いものでした。SSDP/UPNP にも詳しくありませんが、すぐに理解できました。ルーターでは DD WRT を使用しています。Alexa デバイス、電話、Wemo のそれぞれに静的 IP アドレスを割り当てました。
Alexa の検出メカニズムの詳細がわからないため、Echo からの M-SEARCH メッセージの受信と Wemo からの NOTIFY アナウンスの送信の両方をやめる必要があると思います。デバイス検出をネットワーク上で通常どおり機能させたいと考えています。iTunes リモートと Plex を使用しており、同様のデバイスをさらに追加する可能性があります。また、どの Alexa/電話デバイスが検出を開始するかわからないため、すべてをブロックしてもかまいません。
したがって、必要なのは、プロトコル全体またはどちらのデバイスへの通常の HTTP 通信 (IFTTT が使用していると想定) も無効にせずに、2 つのデバイス間の SSDP 通信をドロップするルーター ルールです。
私が試したのは、A が Wemo の IP ローカル IP アドレスで、B が他の 4 つのデバイスの IP アドレスの 1 つである場合です。
iptables -I FORWARD -s A -d B -j logdrop
iptables -I FORWARD -s B -d A -j logdrop
応答はユニキャストであるはずなので、M-SEARCH への応答はドロップされると思います。間違ったテーブルを使用しているのでしょうか?
iptables -I INPUT -s A -d B -j logdrop
iptables -I INPUT -s B -d A -j logdrop
repeat for OUTPUT, PREROUTING, POSTROUTING
いいえ。UDP を追加してみました (念のため、TCP を別途追加したり、どちらも追加しなかったりしましたが、上記の表のバリエーションはそのままです)。
iptables -I FORWARD -p udp -s A -d B logdrop
iptables -I FORWARD -p udp -s B -d A logdrop
それでもまだうまくいきませんでした。マルチキャスト機能を試してみるといいかもしれません。
iptables -I FORWARD -p udp -s A -d 239.255.255.250 -j logdrop
iptables -I FORWARD -p udp -s 239.255.255.250 -d A -j logdrop
iptables -I FORWARD -p udp -s B -d 239.255.255.250 -j logdrop
iptables -I FORWARD -p udp -s 239.255.255.250 -d B -j logdrop
also the INPUT/OUTPUT/PRE/POSTROUTING tables
いいえ。
そこで、私は多くの組み合わせを試しましたが（私が示したすべての順列ではありませんが、多くの組み合わせを試しました）、原則として、それらがお互いを見つけないようにすることはできませんでした。なんと、ルーターで UPNP を完全に無効にすることさえ試しました。それでもうまくいかなかったようです。これらの厄介なデバイスがどのように通信しているのかわかりません！パケットスニッフィングを試しましたが、Wi-Fi であり、Windows を使用しているため、どうやら難しいようです。たとえば、より一般的なルールでうまくいったこともありますiptables -I FORWARD -d A -j logdropが、それらは極端すぎて、もちろん IFTTT の接続機能を壊し、どのルールが魔法のように機能しているのかを理解するのに苦労しました。
2 晩独力で試した後、助けを求める時が来ました。ファイアウォール ルールを設定する正しい方法は何ですか? または、SSDP またはルーティング ルール (または理論的には Alexa) について私が根本的に誤解している点は何ですか?
答え1
最初の問題は、それらのパケットがルーティングそもそも。
iptables -I FORWARDIP層で転送されるパケットを扱います。つまり、デバイスが2つのIPネットワーク間のルーターとして機能する場合です。ただし、同じサブネットはルーターに到達せず、Wi-Fi AP とイーサネット スイッチ自体によってリンク層で転送されます。
だからあなたはかもしれないソフトウェアに到達するパケットをフィルタリングできるebtables– たとえば、通常、Wi-Fi AP と内蔵イーサネット スイッチの間を移動するパケットは Linux の「ブリッジ」インターフェイスを通過しますが、実際にこれについて説明している Web サイトがいくつかあります (例えば）。
例えば、これはブロックします全てath*(Atheros ワイヤレス) インターフェイス経由で送信されるマルチキャスト パケット:
ebtables -A FORWARD -o ath+ -d Multicast -j DROP
残念ながら、ハードウェアで転送されるパケットに対しては通常同じことはできません。ebtables でもそれらは認識されません。
さて、関係するパケットがすべて通常のユニキャストである場合、2 番目のサブネットを設定し、ルーターで 2 つのネットワーク間のルーティングを行うことをお勧めします。ただし、マルチキャストが関係する場合は問題が発生する可能性があります。ほとんどのマルチキャスト「転送」または「プロキシ」機能は単方向のようです。本格的なマルチキャスト ルーティングは DD-WRT の能力を超えています。さらに、多くの検出パケットの TTL は 1 であるため、ルーターはパケットを最初のネットワークの先に渡すことはありません。
(ちなみに、iTunes は通常 SSDP を使用せず、mDNS 経由の DNS-SD を使用します。)
答え2
私の Echo dot でも同様の問題が発生しました。検出を行うと、Sony SA-NS400 スピーカーがネットワークから切断され、通常は復帰しません。これらはすべて同じ Wi-Fi インターフェイス上にあります。これは Wireshark と Intel Device Sniffer で確認できます。Amazon サポートは役立ちましたが、解決には至りませんでした。urn:Belkin:device:** パケットがまさにこれを引き起こしていると思います (まだ自分で再作成して確認していません)。私の解決策は、各ドットに次のルールを設定することでした (XXXX はドットの IP です)。
ebtables -A FORWARD --protocol IPv4 --ip-source X.X.X.X --ip-destination 239.255.255.250 -j DROP
これにより、ドットからの検出のみがブロックされ、他のデバイスによる検出が可能になります。実際にドットからの検出を行う必要がある場合は、ebtables を変更するスクリプトを実行し、完了したら元に戻します。この問題を回避して、マルチキャストが他のインターフェイスに届くようにする方法はまだ見つかっていません。そのため、ebtables を変更せずに、hue エミュレーターへの変更を取得できます。