連接到多個攝像頭,每個攝像頭都充當 WiFi 接入點
我有 7 個攝像頭,每個攝像頭都充當 WiFi 接入點,我無法更改它們的配置。
Camera1 SSID: camera1, pass: 1234, it has static IP: 192.168.42.1 and built-in DHCP server Camera2 SSID: camera2, pass: 1234, it has static IP: 192.168.42.1 and built-in DHCP server .. Camera7 SSID: camera7, pass: 1234, it has static IP: 192.168.42.1 and built-in DHCP server
在我的 Windows 筆記本上,通過使用內部 WiFi 適配器,我可以連接到 camera1 的 ssid 並獲取影片。然後我需要斷開它,連接到camera2的ssid以從camera2獲取影片,類似於3,4..7。
我想要的是從所有人那裡獲得同步影片。
我嘗試了什麼: 我嘗試將 7 個 USB WiFi 適配器插入我的筆記型電腦。並且每個適配器配置為連接不同的相機。在這種情況下,windows 顯示了 7 個不同的乙太網介面,每個介面都從相應的攝影機的 dhcp 伺服器獲取它們的 IP。但所有攝影機都使用相同的 IP,即 192.168.42.1。此外,據我所知,Windows 支持多個 USB WiFi 適配器,但 MACOS 不支持。
我需要一種通用的解決方案來解決這個問題,到目前為止我還不知道怎麼解決。非常感謝您的幫助和建議。
謝謝。
進一步測試: 我相信我已經接近解決方案。但仍然需要幫助。我拿了一個執行 Ubuntu 的樹莓派 4。我打算將它用作路由器。預設情況下,PI 硬體帶有 2 個乙太網介面;
eth0
-> 1Gbit 電纜連接wlan0
-> 嵌入式 WiFi 介面我插入了兩個額外的 USB WiFi 加密狗,現在它還有兩個名為wlxb8b7f16a0602和wlxb8b7f16a04cd的乙太網介面。每個 USB WiFi 加密狗都連接到不同的相機。這是
ifconfig
輸出:pi@pi:~$ ifconfig -a eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether dc:a6:32:48:55:70 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.205 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::2c43:aa7a:a4c8:47eb prefixlen 64 scopeid 0x20<link> inet6 2a02:aa14:c480:6c80:9deb:968e:785d:159c prefixlen 64 scopeid 0x0<global> inet6 2a02:aa14:c480:6c80:10b7:8a65:dce6:1f5c prefixlen 64 scopeid 0x0<global> ether dc:a6:32:48:55:71 txqueuelen 1000 (Ethernet) RX packets 10535 bytes 2218695 (2.2 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 44536 bytes 63167704 (63.1 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlxb8b7f16a0602: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.42.24 netmask 255.255.255.0 broadcast 192.168.42.255 inet6 fe80::6523:f6cd:520b:ee0 prefixlen 64 scopeid 0x20<link> ether b8:b7:f1:6a:06:02 txqueuelen 1000 (Ethernet) RX packets 9 bytes 1495 (1.4 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 47 bytes 9334 (9.3 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlxb8b7f16a04cd: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.42.170 netmask 255.255.255.0 broadcast 192.168.42.255 inet6 fe80::ad02:2e2e:cc11:c309 prefixlen 64 scopeid 0x20<link> ether b8:b7:f1:6a:04:cd txqueuelen 1000 (Ethernet) RX packets 60 bytes 6531 (6.5 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 130 bytes 19353 (19.3 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
在這種配置中;
eth0
-> 未連接wlan0
-> 連接到我的網際網路調製解調器(僅用於 ssh 到 pi)wlxb8b7f16a0602
-> 連接到 Camera1wlxb8b7f16a04cd
-> 連接到 Camera2即使每台攝影機的 IP 相同,即 192.168.42.1,但由於它們連接到不同的介面,我可以使用
-I
如下參數成功 ping 它們:對於相機 1:
pi@pi:~$ ping -I wlxb8b7f16a0602 192.168.42.1 PING 192.168.42.1 (192.168.42.1) from 192.168.42.24 wlxb8b7f16a0602: 56(84) bytes of data. 64 bytes from 192.168.42.1: icmp_seq=2 ttl=64 time=3.77 ms
對於相機 2:
pi@pi:~$ ping -I wlxb8b7f16a04cd 192.168.42.1 PING 192.168.42.1 (192.168.42.1) from 192.168.42.170 wlxb8b7f16a04cd: 56(84) bytes of data. 64 bytes from 192.168.42.1: icmp_seq=2 ttl=64 time=2.03 ms
從這裡開始,假設我為我的 eth0 介面分配了一個靜態 IP,即 192.168.42.250
我要轉發的請求來自
- 192.168.42.250: eth0的443到wlxb8b7f16a0602的192.168.42.1:443
- 192.168.42.250: eth0的444到wlxb8b7f16a04cd的192.168.42.1:443
如果你幫助我解決剩下的問題,我接受你的回答。
致@AB:
pi@pi:~$ iw phy phy0 |grep netns phy <phyname> set netns { <pid> | name <nsname> } <nsname> - change network namespace by name from /run/netns or by absolute path (man ip-netns) pi@pi:~$ ll /sys/class/ieee80211 total 0 drwxr-xr-x 2 root root 0 Mai 27 17:13 ./ drwxr-xr-x 78 root root 0 Jan 1 1970 ../ lrwxrwxrwx 1 root root 0 Jun 27 20:18 phy0 -> ../../devices/platform/soc/fe300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/ieee80211/phy0/ lrwxrwxrwx 1 root root 0 Mai 27 17:13 phy1 -> ../../devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:1.0/ieee80211/phy1/ lrwxrwxrwx 1 root root 0 Mai 27 17:13 phy2 -> ../../devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/ieee80211/phy2/
介紹
這個問題可以通過使用網路命名空間來解決,從而將單個 Pi 系統拆分為 X 路由器進行 NAT。這就是應該做的。唉,我不知道如何寫一個答案,不僅要包括如何將 Wifi 介面移動到新的網路命名空間(需要兼容的驅動程序而
iw phy phyX set netns ...
不是ip link set wlanX ... netns ...
),而且特別是它們的關聯wpa_supplicant
和 DHCP 客戶端守護程序以及相應的系統集成調整。這需要對特定係統如何配置無線和 DHCP 有很好的了解。相反,此答案避免使用網路名稱空間,並避免重新配置wpa_supplicant和 DHCP 客戶端的處理:它使用策略路由。
在這種情況下,策略路由中涉及標記是不可避免的,因為路由堆棧只會看到目標埠 443 而不是 4431/4432(DNAT 之前已經更改過它)。標記也將是使用者設置連接跟踪(回复)區域以確保處理多個攝影機將相同 IP 地址分配給其匹配主機介面的情況。
如果預設設置了嚴格,則必須將嚴格反向路徑轉發(SRPF)放鬆為鬆散 RPF,因為 ARP 處理不會收到標記並且可以保持阻塞。
由於攝影機可能沒有設置到客戶端的預設路由,但可能只有 LAN 路由,因此也將完成雙 NAT(源和目標)。
設置
由於 OP 沒有提供任何eth0設置,所以這裡沒有。答案盡量不依賴於此,但如果需要,OP 必須對其進行調整(特別是如果 7 個無線介面的名稱都不是以 開頭
wlx
)。讓我們調整目標:
192.168.42.0/24 代表多個重疊的 IP 網路,不能直接訪問這些網路,以保護外部客戶端免受所有可能的路由複雜性的影響。
所以地址 192.168.42.250 不會被使用。遠端客戶端將使用 Pi 的可見地址 192.168.0.205。
任何 HTTPS 訪問都將獲得錯誤的證書。處理它:我正在根據調整網路設置提供答案,但它不包括設置反向代理來隱藏證書問題。添加這樣的反向代理還需要更多的網路調整(最後作為選項添加)。可以從客戶端(但不是 RPi)通過以下方式進行測試:
curl --insecure https://192.168.0.205:4431/ curl --insecure https://192.168.0.205:4432/
另外為了展示下面的一些範例,我以兩台攝影機都為主機分配相同 IP 地址的情況為例,因此它出現在兩個介面上,以提高標準。沒關係。大多數這些設置必須在所有無線連接完成之後而不是之前完成。我不會討論如何將它與處理它的特定 Linux 作業系統集成。
所有命令都應以 root 身份執行。
範例基於:
# ip route default via 192.168.0.1 dev wlan0 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.205 192.168.42.0/24 dev wlxb8b7f16a0602 proto kernel scope link src 192.168.42.10 metric 600 192.168.42.0/24 dev wlxb8b7f16a04cd proto kernel scope link src 192.168.42.10 metric 600
用於選擇附加路由表的路由規則,這些路由表將重複的每個攝像頭 LAN 與另一個攝像頭 LAN 隔離開來:
ip rule add fwmark 1 lookup 4431 ip rule add fwmark 2 lookup 4432 ip route add 192.168.42.0/24 dev wlxb8b7f16a0602 table 4431 ip route add 192.168.42.0/24 dev wlxb8b7f16a04cd table 4432
這使得路由工作從客戶端到攝影機(如果 RPi 沒有預設路由,下面使用 192.0.2.2 測試路由的範例可以使用 192.168.0.101 代替):
# ip route get mark 2 from 192.0.2.2 iif wlan0 192.168.42.1 192.168.42.1 from 192.0.2.2 dev wlxb8b7f16a04cd table 4432 mark 2 cache iif wlan0
但如果啟用了 SRPF,仍然不會回复:
# ip route get mark 2 from 192.168.42.1 iif wlxb8b7f16a04cd 192.0.2.2 RTNETLINK answers: Invalid cross-device link
因此,必須在相機界面上設置一個幾乎沒有記錄的標誌:
sysctl -w net.ipv4.conf.wlxb8b7f16a0602.src_valid_mark=1 sysctl -w net.ipv4.conf.wlxb8b7f16a04cd.src_valid_mark=1
現在得到:
# ip route get mark 2 from 192.168.42.1 iif wlxb8b7f16a04cd 192.0.2.2 192.0.2.2 from 192.168.42.1 via 192.168.0.1 dev wlan0 mark 2 cache iif wlxb8b7f16a04cd
但實際上,無論如何ARP(從攝像頭到主機)在設置 SRPF 時仍然會中斷,因為 ARP 沒有得到 iptables 的標記。
所以只需使用 Loose RPF (
rp_filter=2
) 代替(然後src_valid_mark
不再需要上面的設置)來解決它。無論之前禁用 RPF 還是設置嚴格,這都有效:sysctl -w net.ipv4.conf.wlxb8b7f16a0602.rp_filter=2 sysctl -w net.ipv4.conf.wlxb8b7f16a04cd.rp_filter=2
添加 iptables 規則設置標記以完成路由部分,以及稍後通過設置回复區域選擇器來處理 NAT 中的衝突地址。
iptables -t raw -A PREROUTING ! -i wlx+ -p tcp --dport 4431 -j MARK --set-mark 1 iptables -t raw -A PREROUTING -i wlxb8b7f16a0602 -j MARK --set-mark 1 iptables -t raw -A PREROUTING -m mark --mark 1 -j CT --zone-reply 1 iptables -t raw -A PREROUTING ! -i wlx+ -p tcp --dport 4432 -j MARK --set-mark 2 iptables -t raw -A PREROUTING -i wlxb8b7f16a04cd -j MARK --set-mark 2 iptables -t raw -A PREROUTING -m mark --mark 2 -j CT --zone-reply 2
將這些規則添加到 NAT 到目標 IP 和埠(始終相同)。由於之前的設置,路由堆棧將選擇正確的介面:
iptables -t nat -A PREROUTING ! -i wlx+ -p tcp -m mark ! --mark 0 -j DNAT --to-destination 192.168.42.1:443 iptables -t nat -A POSTROUTING -o wlx+ -j MASQUERADE
如果添加名為 wlx3 的第三個介面,請執行以下步驟。它可以以同樣的方式概括為更多:
添加使用新標記 (3) 選擇的新 ip 規則,它將使用新的路由表 (4433):
ip rule add fwmark 3 lookup 4433
添加匹配的新路由表,其條目或多或少與主表 LAN 的新介面路由重複:
ip route add 192.168.42.0/24 dev wlx3 table 4433
如果作業系統的預設值是 SRPF,則在此界面上鬆開 RPF(如告知
src_valid_mark
最終不需要):sysctl -w net.ipv4.conf.wlx3.rp_filter=2
選擇一個新埠 (4433) 並添加 3 個新的 raw/PREROUTING iptables規則,包括新埠、新標記和新介面:
iptables -t raw -A PREROUTING ! -i wlx+ -p tcp --dport 4433 -j MARK --set-mark 3 iptables -t raw -A PREROUTING -i wlx3 -j MARK --set-mark 3 iptables -t raw -A PREROUTING -m mark --mark 3 -j CT --zone-reply 3
(如果新介面名稱不以相應
wlx
添加新的nat規則開頭。)下面是一個conntrack處理範例,當客戶端連接兩次(即使使用相同的源埠)到兩個埠,而 RPi 獲得分配給兩個 wlx 無線介面的相同 IP 地址時。conntrack區域包含在流選擇中,即使流的一側看到完全相同的地址和埠,也可以正確處理 NAT:
# conntrack -E [NEW] tcp 6 120 SYN_SENT src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4431 [UNREPLIED] src=192.168.42.1 dst=192.168.42.10 sport=443 dport=6666 zone-reply=1 [UPDATE] tcp 6 60 SYN_RECV src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4431 src=192.168.42.1 dst=192.168.42.10 sport=443 dport=6666 zone-reply=1 [UPDATE] tcp 6 432000 ESTABLISHED src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4431 src=192.168.42.1 dst=192.168.42.10 sport=443 dport=6666 zone-reply=1 [ASSURED] [NEW] tcp 6 120 SYN_SENT src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4432 [UNREPLIED] src=192.168.42.1 dst=192.168.42.10 sport=443 dport=6666 zone-reply=2 [UPDATE] tcp 6 60 SYN_RECV src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4432 src=192.168.42.1 dst=192.168.42.10 sport=443 dport=6666 zone-reply=2 [UPDATE] tcp 6 432000 ESTABLISHED src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4432 src=192.168.42.1 dst=192.168.42.10 sport=443 dport=6666 zone-reply=2 [ASSURED]
各種各樣的
- 雜項 1
為了使攝影機能夠 ping 主機或從主機接收 ICMP 錯誤,必須添加此(全域)設置:
sysctl -w net.ipv4.fwmark_reflect=1
否則 ICMP 答案不遵循策略路由。另一種更好的方法是使用CONNMARK / connmark,但這會使答案變得不必要地複雜。
- 雜項 2
無法從 RPi 本身正確測試工作結果,只能從 LAN 上的客戶端(或在 RPi 路由器支持的 Internet 上)進行測試。設置特定於路由案例。
可選地,為了使主機能夠工作(並允許放置反向代理),可以添加這些額外的設置:
甚至在 NAT 發生之前選擇正確的介面(需要核心> = 4.17),否則套接字稍後將選擇錯誤的源地址(另一個介面):
ip rule add iif lo ipproto tcp dport 4431 lookup 4431 ip rule add iif lo ipproto tcp dport 4432 lookup 4432
目的地必須在 nat/OUTPUT 中進行 DNATed。這裡不需要確切的 wlx 名稱,路由堆棧已經使用新的路由規則選擇了正確的傳出路由(回复仍然需要主要答案中的 iptables raw/PREROUTING 規則的一部分)。在 raw/OUTPUT 中也需要一個conntrack回复區來處理罕見的衝突情況。
iptables -t raw -A OUTPUT -o wlx+ -p tcp --dport 4431 -j MARK --set-mark 1 iptables -t raw -A OUTPUT -m mark --mark 1 -j CT --zone-reply 1 iptables -t raw -A OUTPUT -o wlx+ -p tcp --dport 4432 -j MARK --set-mark 2 iptables -t raw -A OUTPUT -m mark --mark 2 -j CT --zone-reply 2 iptables -t nat -A OUTPUT -p tcp -m mark ! --mark 0 -j DNAT --to-destination :443
這種情況下的測試應該通過 RPi 完成:
curl --insecure https://192.168.42.1:4431/ curl --insecure https://192.168.42.1:4432/
- 雜項 3
misc 2中的設置如果適用於 UDP 的本地處理,對於與 OP 不同的情況,對於某些極端情況可能是不夠的:在多宿主環境中,UDP 總是需要本地應用程序的支持。