여러 Amazon Alexa 장치(Echo, 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가 사용한다고 가정)을 비활성화하지 않고 두 장치 간의 SSDP 통신을 중단하는 일부 라우터 규칙입니다.
내가 시도한 것에서 A는 Wemo의 IP 로컬 IP 주소이고 B는 다른 4개 장치의 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 FORWARDIP 계층에서 전달된 패킷을 처리합니다. 즉, 장치가 두 IP 네트워크 사이에서 라우터 역할을 하는 경우입니다. 그러나 내부의 패킷은같은서브넷은 라우터에 도달하지도 않습니다. Wi-Fi AP 및 이더넷 스위치 자체에 의해 링크 계층에서 전달됩니다.
그래서 당신은~할 것 같다예를 들어 일반적으로 Wi-Fi AP와 내장 이더넷 스위치 사이를 통과하는 패킷 ebtables은 Linux '브리지' 인터페이스를 통과하며 실제로 이에 대해 설명하는 다양한 웹 사이트가 있습니다(예를 들어).
예를 들어, 이 블록은모두ath*(Atheros 무선) 인터페이스를 통해 나가는 멀티캐스트 패킷 :
ebtables -A FORWARD -o ath+ -d Multicast -j DROP
불행하게도 하드웨어로 전달된 패킷에 대해서는 일반적으로 동일한 작업을 수행할 수 없습니다. 심지어 ebtables도 이를 볼 수 없습니다.
이제 관련된 모든 패킷이 일반 유니캐스트라면 두 번째 서브넷을 설정하고 라우터가 두 네트워크 간에 항목을 라우팅하도록 하는 것이 좋습니다. 그러나 이는 멀티캐스트가 관련된 경우 문제가 될 수 있습니다. 대부분의 멀티캐스트 "전달" 또는 "프록시" 기능은 단방향으로 보입니다. 본격적인 멀티캐스트 라우팅은 DD-WRT의 능력을 뛰어넘습니다. 게다가 많은 검색 패킷의 TTL은 1이므로 어떤 라우터도 첫 번째 네트워크를 넘어 패킷을 전달하지 않습니다.
(참고로 iTunes는 일반적으로 SSDP를 사용하지 않고 mDNS보다 DNS-SD를 사용합니다.)
답변2
에코 도트와 비슷한 문제가 있었습니다. 발견 시 내 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
이는 점에서의 검색만 차단하고 다른 장치의 검색을 허용합니다. 실제로 점에서 검색을 수행해야 하는 경우 스크립트를 실행하여 ebtable을 변경한 다음 완료되면 다시 변경합니다. 나는 아직 이 문제를 해결하는 방법을 찾지 못했고 멀티캐스트가 다른 인터페이스를 통과하여 ebtable을 변경하지 않고도 색조 에뮬레이터에 대한 변경 사항을 선택할 수 있도록 허용했습니다.