☰

smcroute를 사용하여 서로 다른 물리적 인터페이스에서 두 클라이언트 연결

tag-icon • tag-icon routing interface multicast
smcroute를 사용하여 서로 다른 물리적 인터페이스에서 두 클라이언트 연결

저는 웹을 처음 접했습니다. upnp가 실행되는 두 개의 서로 다른 물리적 인터페이스에 두 개의 클라이언트가 연결되어 있습니다. 두 사람이 서로를 발견하고 서로 핑할 수 있도록 동일한 멀티캐스트 그룹에 추가하고 싶습니다. 그게 가능합니까? smcroute를 사용하여 이를 어떻게 달성할 수 있습니까?

내가 시도한 것은 다음과 같습니다.

두 개의 브리지 인터페이스(요구사항)를 생성하고 이를 해당 물리적 ​​인터페이스에 연결했습니다.

smcroute.conf에 다음 규칙을 추가했습니다.

mgroup from br1 group 239.255.255.250
mgroup from br2 group 239.255.255.250
mroute from br1 group 239.255.255.250 to br2
mroute from br2 group 239.255.255.250 to br1

ip -s mroute는 이것을 보여줍니다

# ip -s mroute
(x.x.x.x, 239.255.255.250) Iif: br2    Oifs: br1
  242 packets, 46509 bytes
(x.x.x.x, 239.255.255.250) Iif: br1     Oifs: br2
  243 packets, 46740 bytes
(x.x.x.x, 239.255.255.250) Iif: unresolved
#

하지만 내 고객은 서로를 발견할 수 없습니다. 내가 이 일을 잘못하고 있는 걸까?

/proc/net/ip_mr_vif는 br1 및 br2 인터페이스에 들어오고 나가는 패킷이 있음을 보여줍니다.

이는 요구사항입니다. 두 개의 물리적 인터페이스가 있는데 일부 조직적 제한으로 인해 동일한 브리지에 태그가 지정되는 것을 원하지 않습니다. 이러한 인터페이스에 연결된 일부 클라이언트가 있으며 upnp 스택은 이러한 인터페이스에서 실행됩니다. 나는 그들이 서로를 발견하기를 바랍니다.

여기서 시도한 해결책은 arp 프록시와 smcroute를 사용하는 것입니다. 두 클라이언트가 다른 클라이언트를 감지할 수 있도록 arp 프록시를 사용하고 있습니다. 나는 smcroute를 사용하여 두 인터페이스에 연결된 모든 클라이언트를 멀티캐스트 그룹 239.255.255.250에 태그하고 패킷을 앞뒤로 전달했습니다. 이것이 올바른 접근 방식입니까?

내 설정 다이어그램을 추가합니다.

        Device 1                      Router                   Device 2
+-----------------+     +----------------------------+    +-----------------+
|                 |     |                            |    |                 |
|           eth1  |     | br2                    br1 |    |  wlan0          |
|   169.254.10.10 |-----| 169.254.50.1      10.0.0.1 |----| 169.254.168.11  |
| (self assigned) |     |                            |    | (self assigned) |
+-----------------+     +----------------------------+    +-----------------+

프록시 arp를 활성화하는 명령:

arp -i br2 -Ds 169.254.168.11 br1 pub
arp -i br1 -Ds 169.254.10.10 br2 pub
ip route add 169.254.168.0/24 dev br1
ip route add 169.254.10.0/24 dev br2

ip -s mroute에서 패킷을 볼 수 있지만 장치가 서로를 발견하지 못합니다.

# ip -s mroute
(169.254.10.10, 239.255.255.250) Iif: br2    Oifs: br1
  3 packets, 549 bytes
(169.254.168.11, 239.255.255.250) Iif: br1    Oifs: br2
  12 packets, 2196 bytes
(169.254.168.11, 239.255.255.250) Iif: unresolved
(169.254.10.10, 239.255.255.250) Iif: unresolved
#

라우터의 Tcpdump:

# tcpdump -i br2 -vvv port 1900
tcpdump: listening on br2, link-type EN10MB (Ethernet), capture size 262144 bytes
21:29:20.867399 IP (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.10.10.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
21:29:21.368865 IP (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.10.10.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
21:29:21.869556 IP (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.10.10.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
21:29:24.614276 IP (tos 0x50, ttl 3, id 6384, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.168.11.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
21:29:25.114268 IP (tos 0x50, ttl 3, id 6393, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.168.11.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
21:29:25.614997 IP (tos 0x50, ttl 3, id 6680, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.168.11.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

# tcpdump -i br1 -vvv port 1900
tcpdump: listening on br1, link-type EN10MB (Ethernet), capture size 262144 bytes
21:29:40.869434 IP (tos 0x50, ttl 3, id 0, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.10.10.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
21:29:41.371016 IP (tos 0x50, ttl 3, id 0, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.10.10.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
21:29:41.871953 IP (tos 0x50, ttl 3, id 0, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.10.10.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
21:29:44.616742 IP (tos 0x0, ttl 4, id 17080, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.168.11.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
21:29:45.138486 IP (tos 0x0, ttl 4, id 17334, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.168.11.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
21:29:45.622226 IP (tos 0x0, ttl 4, id 17487, offset 0, flags [DF], proto UDP (17), length 183)
    169.254.168.11.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
#

명령 출력:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         x.x.x.x         0.0.0.0         UG    0      0        0 erouter0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 br1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 br2
169.254.168.0   0.0.0.0         255.255.255.0   U     0      0        0 br1
239.255.255.250 0.0.0.0         255.255.255.255 UH    0      0        0 br1
#

# ifconfig br2
br2       Link encap:Ethernet  HWaddr xxxxxxxx
          inet addr:169.254.50.1  Bcast:169.254.255.255  Mask:255.255.0.0
          inet6 addr: fe80::d02d:5dff:fe68:8e60/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:24012 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23477 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4779091 (4.5 MiB)  TX bytes:5154708 (4.9 MiB)
#

# ifconfig br1
br1       Link encap:Ethernet  HWaddr xxxxxxxx
          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: xxxxxxxxxxxxxxxxxxxxxxxxxx/64 Scope:Global
          inet6 addr: fe80::16b7:f8ff:fefe:faf6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:44444 errors:0 dropped:0 overruns:0 frame:0
          TX packets:55860 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:6780562 (6.4 MiB)  TX bytes:11041592 (10.5 MiB)
#

답변1

네트워크 ABC:

LAN 네트워크의 기본 단위는부분. 원래의10Base5 이더넷긴(보통 노란색) 동축 케이블과 뱀파이어 탭을 사용하면 섹션이 다음과 같이 보입니다.

... ----------------------------- ...
        |         |         |
     Client 1  Client 2  Client 3

구성에 따라 네트워크 세그먼트의 모든 장치는 해당 네트워크 세그먼트의 모든 장치에서 모든 이더넷 패킷을 볼 수 있고 관심 있는 패킷만 필터링할 수 있습니다. 이를 통해방송(세그먼트의 모든 장치에 대해) 및멀티캐스트(특정 네트워크 세그먼트의 특정 장치의 경우) 따라서 LAN 세그먼트라고도 합니다.브로드캐스트 도메인. 네트워크 세그먼트에는 다음에 의해 결정되는 IP 주소 범위가 할당됩니다.넷마스크. 따라서 위의 예에서 세그먼트는 192.168.1.0/24(즉, "세그먼트 이름"은 24비트이고 각 클라이언트의 끝에는 8비트가 있음)를 가질 수 있고 클라이언트 1은 192.168.1.1이 될 수 있고 클라이언트는 192.168이 될 수 있습니다. . 1.2 등

이더넷이 뱀파이어 탭 대신 지점간 연결로 바뀌자,변화세그먼트를 형성하는 데 사용됩니다.

      +-----------------------+
      |         Switch        |
      +-----------------------+
        |         |         |
     Client 1  Client 2  Client 3

개념적으로 스위치는 단순히 한 포트에서 수신된 패킷을 다른 모든 포트로 보냅니다. (실제로는 최적화가 있습니다).

따라서 두 클라이언트가 서로 멀티캐스트를 보낼 수 있도록 연결하는 가장 쉬운 방법은 위 이미지에 표시된 것처럼 스위치를 사용하여 동일한 네트워크 세그먼트에 두는 것입니다.

Linux 컴퓨터에 여러 개의 이더넷 포트가 있고 이를 스위치에 넣으면 스위치 역할을 할 수 있습니다.다리:

    +-------------- Linux PC---------------+
    |                                      |
    |              192.168.1.4             |
    |  <------------  br0 ------------>    |
    |    eth0         eth1         eth2    |
    |     |            |            |      |
    +--------------------------------------+
          |            |            |
      Client 1     Client 2     Client 3
     192.168.1.1  192.168.1.2  192.168.1.3

브리지는 원래 이 구조가 두 개의 LAN 세그먼트를 연결하는 데 사용되었기 때문에 브리지라고 부르지만 여기서는 스위치로 사용됩니다. 브리지는 선택적인 "내부" 인터페이스를 가질 수 있으므로 개념적으로 이는 다음과 같습니다.

      +------------------------------------------------+
      |                     Switch                     |
      +------------------------------------------------+
          |            |            |           |
      Client 1     Client 2     Client 3     Linux PC
     192.168.1.1  192.168.1.2  192.168.1.3  192.168.1.4

따라서 두 클라이언트가 Linux PC에서 서로를 보려면 다음을 사용할 수 있습니다.하나브리지(왜 두 개를 사용했는지, 왜 이것이 필수 사항인지 모르겠습니다).

클라이언트가 두 개의 서로 다른 세그먼트에 있어야 하는 경우(조직적 목적을 위해 당사에 알리지 않음) 브리지하면 안 됩니다(OSI 레벨 2).노선(OSI 레벨 3).

작성(또는 시작 1시 배포의 구성 파일을 /proc/sys/net/ipv4/ip_forward이에 상응하는 것으로 설정)하면 라우팅이 가능해지며, ip route자동으로 추가된 경로가 충분하지 않은 경우 경로를 확인하고 추가할 수 있습니다.

이는 유니캐스트 트래픽을 위한 것이며, 멀티캐스트 트래픽의 경우 실제로 유사한 것이 필요합니다 smcroute.

하나arp 프록시어떤 이유로 브리지할 수 없지만(예: 삼중 주소 모드의 WLAN 및 이더넷) 브리지를 원하는 매우 특정한 경우에 대한 장애물입니다. 이는 arp 메시지를 스푸핑하고, 다른 네트워크 세그먼트의 장치가 실제로 동일한 네트워크 세그먼트에 있는 것처럼 각 네트워크 세그먼트를 가장하고, 유니캐스트 트래픽을 라우팅하는 방식으로 작동합니다. 브로드캐스트(DHCP)나 멀티캐스트에서는 작동하지 않습니다.

arp 프록시를 사용할 때 우리에게 알려주지 않은 특별한 경우가 발생하지 않는다면 아마도 잘못하고 있는 것일 수 있습니다. 브리지에서 arp 프록시를 사용하는 경우 우리에게 말하지 않은 정말 말도 안되는 상황에 직면하지 않는 한 거의 확실히 잘못하고 있는 것입니다(모든 것을 브리지할 수 있음).

그래서:

  1. 두 클라이언트를 연결할 수 있는지(또는 스위치만 사용할 수 있는지) 결정하십시오. 연결할 수 없는 경우 질문을 업데이트하고 이유를 설명하세요.

  2. 브리징이 불가능한 경우 IP 전달을 활성화하고 라우팅을 확인하고 ping작동하는지 테스트하십시오.그 다음에설정할 수 있습니다 smcroute. 또는 로 ssmping테스트asmping아니요그리고 ping. 작업 한 ssmping후 asmping정의에 따라 로컬 범위가 있음에도 불구하고 SSDP가 라우팅되고 있는지 확인해보세요(시도하지는 않았습니다). 그렇지 않으면 더 많은 혼란이 있을 수 있습니다.

  3. 만약 당신이 정말로가지다arp 프록시를 사용하려면 질문을 편집하고 상황을 완전하고 철저하게 설명하고 사용하십시오.모두세부 사항.

편집하다

따라서 서버에서 다음 설정을 가정합니다.

  • eth1 및 10.0.0.1/24
  • eth2 및 10.0.1.1/24
  • 주소 10.0.0.2의 eth1 뒤에 있는 클라이언트 1
  • 주소 10.0.1.2의 eth2 뒤에 있는 클라이언트 2

arp 에이전트를 죽입니다.

전달 활성화:

echo "1" | sudo tee /proc/sys/net/ipv4/ip_forward

방향을 확인하면 및 방향이 표시됩니다 ip route.eth1eth2

클라이언트 1에서 , , 을 ping 10.0.0.1차례로 실행합니다 . 3개 항목이 모두 유효한지 확인하세요. 적절한 주소를 가진 클라이언트 2에도 동일하게 적용됩니다.ping 10.0.1.1ping 10.0.1.2

그래도 작동하지 않으면 tcpdump -ni eth1한 창에서 사용하고 tcpdump -ni eth2다른 창에서 ping을 실행하여 무엇이 잘못되었는지 확인하십시오.

작동하면 ssmping두 클라이언트 모두에 설치하십시오. sudo smcrouted -n메시지를 볼 수 있도록 새 창에서 서버를 시작합니다 . 우리는 테스트를 위해 멀티캐스트 그룹을 사용합니다 226.1.1.234. sudo smcroutectl add eth1 226.1.1.2 eth2마. ssmpingd클라이언트 1에서 실행한 다음 asmping -4 10.0.0.2 226.1.1.234클라이언트 2에서 실행합니다. 다시 ssmpingd클라이언트 2에서 실행한 다음 asmping -4 10.0.1.2 226.1.1.234클라이언트 1에서 실행합니다. 그래도 안되면 위와 같이 디버깅을 해보세요.

마지막으로 sudo smcroutectl add eth1 239.255.255.250 eth2UPNP 검색이 작동하는지 테스트해 보세요. 방금 두 개의 추가 네트워크 네임스페이스를 사용하여 이것을 minidlna테스트 했는데 gupnp-universal-cp여기서는 제대로 작동했습니다.

제대로 작동하면 필요에 따라 구성 파일을 설정하십시오.

편집하다

나는 올려다본다RFC3927, 그리고 명확하게 언급됨

대상 주소가 169.254/16 접두사에 있는 경우 보낸 사람은 ARP를 통해 대상 주소를 조회하고 해당 패킷을 동일한 물리적 링크의 대상으로 직접 보내야 합니다.

호스트는 전달을 위해 IPv4 링크-로컬 대상 주소가 포함된 패킷을 어떤 라우터에도 보내서는 안 됩니다.

그리고 내가 아는 한, 이는 추가 ARP 규칙(동일한 인터페이스여야 함)을 사용하여 Linux 커널에서 완전히 시행되므로 169.254.*.* 주소 라우팅은 불가능합니다. 우리가 그들을 라우팅하려고 한다면, 우리는 리눅스 커널과 끝까지 싸워야 합니다. 어쩌면 가능할지도 모르지만, 난 심지어 그렇지도 않아생각하다시도 해봐. 이는 멀티캐스트가 아닌 유니캐스트에서만 작동합니다.

169.254.*.*, UPNP, Apple Bonjour 등이 포함된 장치는 동일한 LAN 세그먼트에서 사용해야 합니다. 이는 다음에도 적용됩니다.이를 사용하려는 모든 장치. 이것이 전체 이야기입니다.

다음과 같은 옵션이 있습니다.

  • 장치를 터치하고 고정 IP를 구성하거나 DHCP를 수락하도록 설득하세요. 내 모든 미디어 장치가 이 작업을 수행할 수 있습니다. 어떤 기기를 가지고 있는지 알려주지 않으셨기 때문에 도움을 드릴 수 없습니다.

  • 일종의 터널, VLAN, 추가 SSID 또는 기타 장치 뒤에 하나 또는 두 개의 미디어 장치를 배치하면 모든 장치를 브리지할 필요가 없지만 하나의 LAN 세그먼트에서 미디어 장치를 확인해야 하는 모든 장치를 유지할 수 있습니다. . 여러번 문의했는데도 네트워크 설정에 대해 설명을 안해주셔서 해결방법을 도와드릴수가 없네요.

  • arp-proxy 등과 같은 사용자 공간에서 자신만의 네트워크 스택을 구현하고 RFC 및 네트워크 관행을 무시하고 원하는 대로 수행하세요. ARP를 통과해야 할 뿐만 아니라 브로드캐스트와 멀티캐스트도 통과해야 하므로 이미 대부분 자체 구현된 NIH 브리지입니다.

  • 실제로 모든 것을 연결하지만 ebtables관리 문제에 따라 강제로 분리하는 등의 방법을 사용합니다. 거듭된 문의에도 불구하고 행정적인 문제에 대해 설명을 해주지 않으셔서 도움을 드릴 수가 없습니다.

이러한 옵션 중 어느 것도 효과가 없다면 원하는 것이 불가능합니다. 기간.

답변2

문제는 rp_filter에 있습니다. rp_filter가 켜져 있습니다. 따라서 이 커널은 사용자 공간에 도착하는 모든 멀티캐스트 패킷을 필터링합니다. 따라서 smcroute는 멀티캐스트 패킷을 라우팅할 수 없습니다.

echo 0 > /proc/sys/net/ipv4/conf/br1/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/br2/rp_filter

위와 같이 rp_filter를 끄고 작업을 시작하세요.

관련 정보