У меня есть несколько устройств Amazon Alexa (Echo, два Dots) и умный выключатель Belkin Wemo. Приложение Alexa позволяет вам сканировать устройства для умного дома, и оно автоматически добавляет все, что находит. Обычно это обрабатывается посредством связи между приложением, Amazon и сетевым облаком устройства, но, по-видимому, Wemo в частности использует вместо этого обнаружение устройств SSDP. Alexa находит Wemo почти каждый раз.
На самом деле я хочу, чтобы он не работал, но при этом разрешал удаленное управление Wemo из IFTTT. Да, я знаю, что это странный вариант использования :) Моя первая попытка состояла в том, чтобы настроить вторичную сеть и подключить Wemo к ней. Но по какой-то причине Wemo и маршрутизатор не будут оставаться подключенными в этой сети дольше минуты. Поэтому я отказался от этого и попытался сделать это через правила брандмауэра, которые находятся далеко за пределами моей зоны комфорта. Я также не знаком с SSDP/UPNP, но быстро схватываю идею. Я использую DD WRT на маршрутизаторе. Я назначил каждому устройству Alexa, моему телефону и Wemo статический IP-адрес.
Учитывая, что я не знаю подробностей механизма обнаружения Alexa, я предполагаю, что мне нужно отказаться как от получения сообщений M-SEARCH от Echo, так и от отправки объявлений NOTIFY от Wemo. Я хотел бы сохранить работу обнаружения устройств в целом в моей сети; я использую пульты iTunes и Plex и могу добавить больше похожих устройств. Я также не уверен, какое устройство Alexa/телефон будет инициировать обнаружение, поэтому я с удовольствием заблокирую их все.
Итак, мне нужны некоторые правила маршрутизатора, которые разрывают связь SSDP между двумя устройствами, не отключая весь протокол или обычную связь HTTP (которую, как я предполагаю, использует IFTTT) ни с одним из устройств.
Что я пробовал, где A — локальный IP-адрес IP-адреса Wemo, а 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 на маршрутизаторе. Даже это, похоже, не сработало. Я не знаю, как эти чертовы устройства взаимодействуют! Я бы перехватил пакеты, но это Wi-Fi, а я работаю в Windows, так что, по-видимому, это сложно. Мне немного повезло с более общими правилами, например, iptables -I FORWARD -d A -j logdropно они слишком радикальны и, конечно, сломали способность IFTTT подключаться, и мне было трудно понять, какие правила творили магию даже тогда.
Итак, после двух ночей попыток самостоятельно, пришло время обратиться за помощью. Как правильно настроить правила брандмауэра? Или что я принципиально не понимаю в SSDP или правилах маршрутизации (или теоретически в Alexa)?
решение1
Первая проблема в том, что эти пакеты неразосланныйв первую очередь.
iptables -I FORWARDимеет дело с пакетами, пересылаемыми на уровне IP – т.е. когда устройство действует как маршрутизатор между двумя сетями IP. Однако пакеты внутритакой жеподсети даже не доходят до маршрутизатора — они пересылаются на канальном уровне самими точками доступа Wi-Fi и коммутаторами Ethernet.
Так что вымощьиметь возможность фильтровать пакеты, которые достигают программного обеспечения, используя ebtables– например, обычно пакеты, проходящие между точкой доступа Wi-Fi и встроенным коммутатором Ethernet, проходят через интерфейс «моста» Linux, и на самом деле существуют различные веб-сайты, говорящие об этом (например).
Например, это блокируетвсемногоадресные пакеты, исходящие через ath*интерфейсы (Atheros wireless):
ebtables -A FORWARD -o ath+ -d Multicast -j DROP
К сожалению, вы, как правило, не можете сделать то же самое для пакетов, пересылаемых аппаратно — даже ebtables их не видит.
Теперь, если бы все задействованные пакеты были обычными одноадресными, я бы предложил настроить вторую подсеть и позволить маршрутизатору маршрутизировать все между двумя сетями. Однако это может быть проблематично, когда задействована многоадресная передача — большинство функций многоадресной «пересылки» или «проксирования» кажутся однонаправленными; полноценная многоадресная маршрутизация выходит за рамки возможностей DD-WRT; и, вдобавок ко всему, многие пакеты обнаружения даже имеют TTL 1, так что ни один маршрутизатор в любом случае не передаст их за пределы первой сети.
(Кстати, iTunes обычно не использует SSDP — он использует DNS-SD поверх mDNS.)
решение2
У меня была похожая проблема с моими точками Echo. Когда они выполняют обнаружение, мои динамики 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, а затем возвращаю его обратно, когда все сделано. Я пока не нашел способа обойти это и разрешить multicast проходить через другие интерфейсы, так что изменения в моем hue-emulator можно было бы подхватить без внесения изменений в ebtables.