Tengo varios dispositivos Amazon Alexa (un Echo, dos Dots) y un interruptor inteligente Belkin Wemo. La aplicación Alexa le permite buscar dispositivos domésticos inteligentes y agregará automáticamente todo lo que encuentre. Esto normalmente se maneja mediante la comunicación entre la aplicación, Amazon y la nube de red del dispositivo, pero aparentemente Wemo en particular utiliza el descubrimiento de dispositivos SSDP. Alexa encuentra el Wemo casi siempre.
De hecho, quiero que falle y al mismo tiempo permita el control remoto del Wemo desde IFTTT. Sí, sé que es un caso de uso extraño :) Mi intento inicial fue configurar una red secundaria y colocar el Wemo en ella. Pero por alguna razón, el Wemo y el enrutador no permanecerán conectados durante más de un minuto en esa red. Así que renuncié a eso e intenté hacerlo mediante reglas de firewall, que están fuera de mi zona de confort. Tampoco estoy familiarizado con SSDP/UPNP, pero estoy entendiendo la idea rápidamente. Estoy usando DD WRT en el enrutador. Le asigné a cada dispositivo Alexa, mi teléfono y Wemo una dirección IP estática.
Dado que no conozco los detalles del mecanismo de descubrimiento de Alexa, supongo que debo dejar de recibir mensajes M-SEARCH del Echo y enviar anuncios NOTIFY del Wemo. Me gustaría que la detección de dispositivos siga funcionando en general en mi red; Utilizo controles remotos de iTunes y Plex y puedo agregar más dispositivos similares. Tampoco estoy seguro de qué dispositivo Alexa/teléfono iniciaría el descubrimiento, así que estoy feliz de bloquearlos a todos.
Entonces, lo que necesito son algunas reglas de enrutador que eliminen la comunicación SSDP entre dos dispositivos, sin deshabilitar todo el protocolo o la comunicación HTTP normal (que supongo que está usando IFTTT) en ninguno de los dispositivos.
Lo que he probado, donde A es la dirección IP local de Wemo y B es una de las direcciones IP de los otros cuatro dispositivos:
iptables -I FORWARD -s A -d B -j logdrop
iptables -I FORWARD -s B -d A -j logdrop
Se supone que las respuestas son de unidifusión, por lo que pensé que eso eliminaría la respuesta a M-SEARCH. ¿Quizás estoy usando la tabla equivocada?
iptables -I INPUT -s A -d B -j logdrop
iptables -I INPUT -s B -d A -j logdrop
repeat for OUTPUT, PREROUTING, POSTROUTING
No. Intenté agregar UDP (y TCP por separado, o ninguno, solo por si acaso, manteniendo las variaciones de la tabla anterior):
iptables -I FORWARD -p udp -s A -d B logdrop
iptables -I FORWARD -p udp -s B -d A logdrop
Entonces eso todavía no funcionó. ¿Quizás pueda intentar alterar la capacidad de multidifusión?
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
No.
Así que he probado muchas combinaciones (no todas las permutaciones de lo que he mostrado, pero sí muchas) y, por regla general, no he podido evitar que se encuentren entre sí. Diablos, incluso intenté deshabilitar UPNP por completo en el enrutador. Incluso eso no pareció funcionar. ¡No sé cómo se comunican estos malditos dispositivos! Rastrearía paquetes, pero es wifi y estoy en Windows, así que aparentemente eso es difícil. Tuve algo de suerte con reglas más generales, por ejemplo, iptables -I FORWARD -d A -j logdroppero son demasiado drásticas y, por supuesto, rompieron la capacidad de IFTTT para conectarse, y tuve dificultades para descubrir qué reglas estaban haciendo la magia incluso en ese momento.
Entonces, después de dos noches intentándolo por mi cuenta, es hora de pedir ayuda. ¿Cuál es la forma correcta de configurar las reglas del firewall? ¿O qué es lo que estoy entendiendo fundamentalmente mal sobre SSDP o las reglas de enrutamiento (o, en teoría, sobre Alexa)?
Respuesta1
El primer problema es que esos paquetes no sonenrutadoen primer lugar.
iptables -I FORWARDSe ocupa de los paquetes reenviados en la capa IP, es decir, cuando el dispositivo actúa como enrutador entre dos redes IP. Sin embargo, los paquetes dentro delmismoLa subred ni siquiera llega al enrutador: los propios AP Wi-Fi y conmutadores Ethernet los reenvían a la capa de enlace.
Vos tambienpodríapor ejemplo, normalmente los paquetes que se cruzan entre el AP Wi-Fi y el conmutador Ethernet incorporado pasan por una interfaz 'puente' de Linux y, de hecho , ebtableshay varios sitios web que hablan de esto (p.ej).
Por ejemplo, esto bloqueatodoPaquetes de multidifusión que salen a través de ath*interfaces (inalámbricas Atheros):
ebtables -A FORWARD -o ath+ -d Multicast -j DROP
Desafortunadamente, generalmente no se puede hacer lo mismo con los paquetes reenviados en hardware; ni siquiera ebtables los ve.
Ahora, si todos los paquetes involucrados fueran de unidifusión normal, sugeriría configurar una segunda subred y dejar que el enrutador enrute cosas entre las dos redes. Sin embargo, esto puede resultar problemático cuando se trata de multidifusión: la mayoría de las funciones de "reenvío" o "proxy" de multidifusión parecen unidireccionales; el enrutamiento de multidifusión completo está más allá de las capacidades de DD-WRT; y además de eso, muchos paquetes de descubrimiento incluso tienen un TTL de 1, por lo que ningún enrutador los pasará más allá de la primera red de todos modos.
(Como nota al margen, iTunes generalmente no usa SSDP; usa DNS-SD sobre mDNS).
Respuesta2
Tuve un problema similar con mis puntos Echo. Cuando hacen un descubrimiento, mis altavoces Sony SA-NS400 se desconectan de la red y normalmente no vuelven. Todos están en la misma interfaz wifi. Esto se puede ver en Wireshark e Intel Device Sniffer. El soporte de Amazon fue útil pero no llegó a ninguna parte. Creo que es específicamente el paquete urn:Belkin:device:** el que hace esto (aún no lo he recreado para confirmarlo). Mi solución fue poner esta regla para cada uno de mis puntos (XXXX es la IP de un punto):
ebtables -A FORWARD --protocol IPv4 --ip-source X.X.X.X --ip-destination 239.255.255.250 -j DROP
Esto bloquea sólo el descubrimiento desde los puntos y permite el descubrimiento mediante otros dispositivos. Cuando realmente necesito hacer un descubrimiento desde un punto, ejecuto un script para cambiar las ebtables y luego lo vuelvo a cambiar cuando termino. Todavía no he encontrado una manera de solucionar esto y permitir que la multidifusión llegue a otras interfaces, de modo que los cambios en mi emulador de tono se puedan recoger sin realizar cambios en ebtables.