我有幾個 Amazon Alexa 裝置（一個 Echo、兩個 Dots）和一個 Belkin WeMo 智慧開關。 Alexa 應用程式可讓您掃描智慧家庭設備，它會自動添加找到的任何內容。這通常是透過應用程式、Amazon 和裝置的網路雲之間的通訊來處理的，但顯然 WeMo 特別使用 SSDP 設備發現。 Alexa 幾乎每次都能找到 WeMo。
我實際上希望它失敗，同時允許從 IFTTT 遠端控制 WeMo。是的，我知道這是一個奇怪的用例 :) 我最初的嘗試是建立一個輔助網路並將 WeMo 粘在上面。但由於某種原因，WeMo 和路由器在該網路上保持連線的時間不會超過大約一分鐘。所以我放棄了這一點，並嘗試透過防火牆規則來做到這一點——這遠遠超出了我的舒適區。我也不熟悉 SSDP/UPNP，但我很快就明白了。我在路由器上使用DD WRT。我為每個 Alexa 裝置、我的手機和 WeMo 分配了一個靜態 IP 位址。
鑑於我不知道 Alexa 發現機制的細節，我認為我需要放棄從 Echo 接收 M-SEARCH 訊息和從 WeMo 發送 NOTIFY 公告。我希望設備發現在我的網路上正常運作；我使用 iTunes 遙控器和 Plex，並且可能會添加更多類似的設備。我也不確定哪個 Alexa/電話設備會發起發現，所以我很高興阻止所有這些設備。
因此，我需要的是一些路由器規則，這些規則可以丟棄兩個設備之間的 SSDP 通信，而不禁用到任一設備的整個協議或正常 HTTP 通信（我假設 IFTTT 正在使用）。
我嘗試過，其中 A 是 WeMo 的 IP 本地 IP 位址，B 是其他四個裝置的 IP 位址之一：
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。即使這樣似乎也不起作用。我不知道這些該死的設備是如何通訊的！我會嗅探資料包，但它是 wifi，而且我使用的是 Windows，所以顯然這很難。我在更通用的規則上有過一些運氣，例如，iptables -I FORWARD -d A -j logdrop但它們太激烈了，當然破壞了 IFTTT 的連接能力，而且即使在那時，我也很難弄清楚哪些規則發揮了魔力。
因此，經過兩個晚上的獨自嘗試後，是時候尋求幫助了。設定防火牆規則的正確方法是什麼？或者我對 SSDP 或路由規則（或理論上的 Alexa）有什麼根本誤解？
答案1
第一個問題是這些資料包不是路由的首先。
iptables -I FORWARD處理在 IP 層轉送的封包，即當裝置充當兩個 IP 網路之間的路由器。然而，數據包內相同的子網路甚至不會到達路由器 - 它們由 Wi-Fi AP 和乙太網路交換器本身在連結層轉送。
那麼你可能能夠過濾到達軟體的資料包ebtables- 例如，通常 Wi-Fi AP 和內建乙太網路交換器之間的資料包透過 Linux「橋接」接口，事實上有很多網站都在討論這一點（例如）。
例如，這塊全部透過ath*（Atheros 無線）介面退出的多播封包：
ebtables -A FORWARD -o ath+ -d Multicast -j DROP
不幸的是，您通常無法對硬體中轉送的資料包執行相同的操作 - 甚至 ebtables 也看不到這些資料包。
現在，如果涉及的所有封包都是常規單播，我建議設定第二個子網路並讓路由器在兩個網路之間路由內容。然而，當涉及多播時，這可能會很麻煩——大多數多播「轉發」或「代理」功能似乎是單向的；成熟的組播路由超出了 DD-WRT 的能力；最重要的是，許多發現封包的 TTL 甚至為 1，因此沒有路由器不會將它們傳遞到第一個網路之外。
（順便說一句，iTunes 通常不使用 SSDP – 它使用 mDNS 上的 DNS-SD。）
答案2
我的 Echo 點也有類似的問題。當他們進行發現時，我的索尼 SA-NS400 揚聲器會與網路斷開連接，通常不會恢復。它們都在同一個 wifi 介面上。這可以在 Wireshark 和 Intel Device Sniffer 中看到。亞馬遜的支援很有幫助，但沒有任何效果。我相信具體是 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 的情況下拾取對我的色調模擬器的更改。