使用 smcroute 連接不同物理介面上的兩個客戶端
我對網路很陌生。我有兩個客戶端連接在兩個不同的物理介面上,它們上執行了 upnp。我想將它們都添加到同一個多播組中,以便它們都能相互發現並且我將能夠相互 ping 通。那可能嗎?如何使用 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) #
問題出在 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 並開始工作。
網路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 級別 3)而不是橋接(OSI 級別 2)。
寫入(或在啟動時將發行版的配置文件設置為等效文件)啟用路由,
1
如果自動添加的路由不足,則允許您檢查和添加路由。/proc/sys/net/ipv4/ip_forward``ip route
這是針對單播流量的,對於多播流量,您確實需要類似
smcroute
.arp 代理是一種非常特殊的情況,由於某種原因您無法橋接(例如 3 地址模式和乙太網中的 WLAN),但想要進行某種橋接。這通過欺騙 arp 消息和路由單播流量來向每個網段假裝其他網段上的設備確實在同一網段中。它不適用於廣播 (DHCP),也不適用於多播。
如果您使用 arp 代理而沒有您沒有告訴我們的特殊情況,那麼您可能做錯了。如果您在網橋上使用 arp 代理,那麼您幾乎可以肯定是做錯了(您可以只橋接所有內容),除非您遇到了一些您沒有告訴我們的非常瘋狂的情況。
所以:
- 決定是否可以橋接兩個客戶端(或僅使用交換機)。如果您無法橋接,請更新問題並解釋原因。
- 如果無法橋接,請啟用 IP 轉發,檢查路由並測試是否
ping
有效。然後就可以設置了smcroute
。ssmping
用or測試它asmping
,而不用ping
. 一旦ssmping
/asmping
工作,請嘗試 SSDP 是否被路由,儘管根據定義具有本地範圍(我沒有嘗試)。如果沒有,可能會有更多的擺弄。- 如果您確實必須使用 arp 代理,請編輯問題並完整徹底地解釋情況,並提供所有詳細資訊。
編輯
因此,假設在伺服器上進行以下設置:
- eth1 與 10.0.0.1/24
- 帶有 10.0.1.1/24 的 eth2
- 客戶端 1 位於 eth1 後面,地址為 10.0.0.2
- eth2 後面的客戶端 2,地址為 10.0.1.2
殺死 arp 代理。
啟用轉發:
echo "1" | sudo tee /proc/sys/net/ipv4/ip_forward
檢查路線
ip route
,您應該看到到eth1
和的路線eth2
。在客戶端 1 上,執行
ping 10.0.0.1
,然後ping 10.0.1.1
,然後ping 10.0.1.2
。檢查所有 3 個工作。與客戶端 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 eth2
測試 UPNP 發現是否有效。我剛剛使用兩個額外的網路命名空間對此進行了測試,它在這裡執行良好minidlna
。gupnp-universal-cp
一旦它工作,根據需要設置配置文件。
編輯
我查了RFC3927,清楚地說
如果目標地址在 169.254/16 前綴中
$$ … $$,然後發送方必須 ARP 獲取目標地址,然後將其數據包直接發送到同一物理鏈路上的目標。
主機不得將帶有 IPv4 鏈路本地目標地址的數據包發送到任何路由器進行轉發。
和 AFAIK,這是在 Linux 核心中強制執行的,完全使用額外的 ARP 規則(必須是相同的介面)所以不可能路由 169.254.. 地址。如果我們試圖對它們進行路由,我們將不得不在整個過程中與 Linux 核心作鬥爭。也許這是可能的,但我什至不想嘗試。這僅適用於單播,甚至不適用於多播。
具有 169.254..、UPNP、Apple Bonjour 等的設備應在同一 LAN 網段上使用。這也適用於所有想要使用它們的設備。這就是來龍去脈。
您有以下選擇:
- 觸摸設備並配置靜態 IP,或說服它們接受 DHCP。我所有的媒體設備都可以做到這一點。你沒有說你有哪些設備,所以我不能幫你。
- 將一個或兩個媒體設備放在某種隧道、VLAN、額外的 SSID 或其他後面,這樣您就不必橋接所有內容,但可以將所有需要查看媒體設備的設備保留在一個 LAN 網段中。儘管我多次詢問,您沒有解釋您的網路設置,所以我無法幫助您找到解決方案。
- 實現您自己的網路堆棧(在使用者空間中,如 arp-proxy,或者然而)忽略 RFC 和網路實踐並做您想要的。您不僅必須傳遞 ARP,還必須傳遞廣播和多播,因此它已經是自行實現的 NIH 網橋的大部分內容。
- 實際上橋接一切,但使用
ebtables
etc. 根據您的管理問題強制分離。儘管我多次詢問,但您沒有解釋您的管理問題,所以我無法幫助您。如果這些選項都不適合您,那麼您想要的就是不可能的。時期。