Bài thuyết trình
Vấn đề này có thể được giải quyết bằng cách sử dụng các không gian tên mạng, do đó chia hệ thống Pi đơn lẻ thành các bộ định tuyến X thực hiện NAT. Đó là điều nên làm. Than ôi, tôi không biết cách viết câu trả lời không chỉ bao gồm cách di chuyển giao diện Wifi sang không gian tên mạng mới (yêu cầu trình điều khiển tương thích và iw phy phyX set netns ... thay vì đặt liên kết ip wlanX ... netns ...) nhưng cũng đặc biệt liên kết của họ wpa_supplicant và trình nền máy khách DHCP với các tinh chỉnh tích hợp hệ thống tương ứng. Điều này đòi hỏi kiến thức tốt về cách cấu hình hệ thống cụ thể với mạng không dây và DHCP.
Thay vào đó, câu trả lời này tránh sử dụng các không gian tên mạng và tránh phải cấu hình lại việc xử lý wpa_supplicant và máy khách DHCP: nó sử dụng định tuyến chính sách.
Liên quan đến các dấu trong định tuyến chính sách là không thể tránh khỏi trong trường hợp này khi ngăn xếp định tuyến sẽ chỉ nhìn thấy cổng đích 443 thay vì 4431/4432 (DNAT đã thay đổi nó trước đó). Marks cũng sẽ được người dùng đặt vùng conntrack (reply) để đảm bảo xử lý trường hợp nhiều camera gán cùng một địa chỉ IP cho giao diện máy chủ phù hợp của chúng.
Chuyển tiếp đường dẫn ngược nghiêm ngặt (SRPF) sẽ phải là thoải mái đến RPF lỏng lẻo trong trường hợp Nghiêm ngặt được đặt theo mặc định, vì việc xử lý ARP sẽ không nhận được điểm và có thể bị chặn.
Vì các camera có thể không đặt tuyến mặc định cho máy khách mà có thể chỉ có tuyến LAN, nên NAT kép (nguồn và đích) cũng sẽ được thực hiện.
Cài đặt
Vì OP không cung cấp bất kỳ eth0 cài đặt, không có ở đây. Câu trả lời cố gắng không phụ thuộc quá nhiều vào điều này, nhưng OP sẽ phải điều chỉnh nó nếu cần (đặc biệt nếu 7 giao diện không dây sẽ không có tên bắt đầu bằng wlx).
Hãy điều chỉnh mục tiêu:
192.168.42.0/24 đại diện cho nhiều mạng IP chồng chéo không được tiếp cận trực tiếp để bảo vệ các máy khách bên ngoài khỏi mọi phức tạp định tuyến có thể xảy ra.
Vì vậy, địa chỉ 192.168.42.250 sẽ không được sử dụng. Địa chỉ hiển thị của Pi 192.168.0.205 sẽ được sử dụng từ các máy khách từ xa.
Mọi truy cập HTTPS sẽ nhận được chứng chỉ không hợp lệ. Giải quyết vấn đề: Tôi đang cung cấp câu trả lời dựa trên việc điều chỉnh cài đặt mạng, nhưng nó sẽ không bao gồm việc thiết lập proxy ngược để ẩn vấn đề về chứng chỉ. Việc thêm proxy ngược như vậy cũng yêu cầu nhiều chỉnh sửa mạng hơn (được thêm vào dưới dạng tùy chọn ở cuối). Các thử nghiệm có thể được thực hiện từ máy khách (chứ không phải RPi) với:
cuộn tròn --không an toàn https://192.168.0.205:4431/
cuộn tròn --không an toàn https://192.168.0.205:4432/
Ngoài ra, để hiển thị một số ví dụ bên dưới, tôi lấy trường hợp cả hai camera đã gán cùng một địa chỉ IP cho máy chủ để nó xuất hiện trên hai giao diện, để nâng cao tiêu chuẩn. Nó không quan trọng. Hầu hết các cài đặt này phải được thực hiện sau khi tất cả các kết nối không dây được thực hiện thay vì trước đó. Tôi sẽ không bàn về cách tích hợp điều này với hệ điều hành Linux cụ thể đang xử lý nó.
Tất cả các lệnh nên được chạy với quyền root.
Các ví dụ dựa trên:
# lộ trình ip
mặc định qua 192.168.0.1 dev wlan0
192.168.0.0/24 dev wlan0 liên kết phạm vi kernel proto src 192.168.0.205
192.168.42.0/24 dev wlxb8b7f16a0602 liên kết phạm vi hạt nhân proto src 192.168.42.10 số liệu 600
192.168.42.0/24 dev wlxb8b7f16a04cd liên kết phạm vi hạt nhân proto src 192.168.42.10 số liệu 600
Các quy tắc định tuyến để chọn các bảng định tuyến bổ sung sẽ cách ly từng mạng LAN của camera khỏi mạng LAN của camera khác:
quy tắc ip thêm fwmark 1 tra cứu 4431
quy tắc ip thêm tra cứu fwmark 2 4432
tuyến ip thêm 192.168.42.0/24 dev wlxb8b7f16a0602 bảng 4431
tuyến ip thêm 192.168.42.0/24 dev wlxb8b7f16a04cd bảng 4432
Điều này làm cho việc định tuyến hoạt động từ máy khách đến máy ảnh (nếu RPi không có tuyến mặc định, các ví dụ bên dưới sử dụng 192.0.2.2 để kiểm tra các tuyến có thể sử dụng 192.168.0.101 thay thế):
# ip route lấy dấu 2 từ 192.0.2.2 iif wlan0 192.168.42.1
192.168.42.1 từ 192.0.2.2 dev wlxb8b7f16a04cd bảng 4432 đánh dấu 2
bộ đệm iif wlan0
nhưng vẫn không trả lời nếu SRPF được bật:
# tuyến ip nhận điểm 2 từ 192.168.42.1 iif wlxb8b7f16a04cd 192.0.2.2
RTNETLINK trả lời: Liên kết thiết bị chéo không hợp lệ
Vì vậy, một cờ gần như không có giấy tờ sẽ phải được đặt trên giao diện máy ảnh:
sysctl -w net.ipv4.conf.wlxb8b7f16a0602.src_valid_mark=1
sysctl -w net.ipv4.conf.wlxb8b7f16a04cd.src_valid_mark=1
để có được ngay bây giờ:
# tuyến ip nhận điểm 2 từ 192.168.42.1 iif wlxb8b7f16a04cd 192.0.2.2
192.0.2.2 từ 192.168.42.1 qua 192.168.0.1 dev wlan0 mark 2
bộ đệm iif wlxb8b7f16a04cd
Nhưng trên thực tế, dù sao ARP (từ camera đến máy chủ) vẫn bị gián đoạn khi SRPF được đặt vì ARP không nhận được dấu iptables.
Vì vậy, chỉ cần sử dụng Loose RPF (rp_filter=2) thay vào đó (và sau đó là cài đặt cho src_valid_mark ở trên không còn cần thiết nữa) để giải quyết nó. Điều này hoạt động cho dù RPF đã bị vô hiệu hóa hay được đặt nghiêm ngặt trước đó:
sysctl -w net.ipv4.conf.wlxb8b7f16a0602.rp_filter=2
sysctl -w net.ipv4.conf.wlxb8b7f16a04cd.rp_filter=2
Thêm các dấu thiết lập quy tắc iptables để hoàn thành phần định tuyến cũng như xử lý các địa chỉ xung đột trong NAT sau này bằng cách đặt bộ chọn vùng trả lời.
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
Thêm các quy tắc đó vào NAT vào IP và cổng đích (luôn giống nhau). Giao diện chính xác sau đó sẽ được chọn bởi ngăn xếp định tuyến nhờ các cài đặt trước đó:
iptables -t nat -A PREROUTING ! -i wlx+ -p tcp -m dấu ! --mark 0 -j DNAT --to-destination 192.168.42.1:443
iptables -t nat -A POSTROUTING -o wlx+ -j MASQUERADE
Nếu thêm giao diện thứ 3 có tên wlx3, đây là các bước. Nó có thể được khái quát hóa theo cùng một cách cho nhiều hơn:
Thêm quy tắc ip mới được chọn bằng dấu mới (3) sẽ sử dụng bảng định tuyến mới (4433):
quy tắc ip thêm tra cứu fwmark 3 4433
Thêm bảng định tuyến mới phù hợp với mục nhập của nó ít nhiều trùng lặp với tuyến đường LAN của bảng chính cho giao diện mới:
tuyến ip thêm 192.168.42.0/24 dev wlx3 bảng 4433
Nới lỏng RPF trên giao diện này nếu mặc định của hệ điều hành là SRPF (như đã nói src_valid_mark cuối cùng không cần thiết):
sysctl -w net.ipv4.conf.wlx3.rp_filter=2
Chọn một cổng mới (4433) và thêm 3 raw/PREROUTING mới iptables các quy tắc bao gồm cổng mới, nhãn hiệu mới và giao diện mới:
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
(Nếu tên giao diện mới không bắt đầu bằng wlx thêm mới tự nhiên quy tắc tương ứng.)
Đây là một ví dụ về theo dõi xử lý khi máy khách kết nối hai lần, thậm chí sử dụng cùng một cổng nguồn, với hai cổng trong khi RPi có cùng một địa chỉ IP được gán cho hai giao diện không dây wlx. Các theo dõi zone được bao gồm trong lựa chọn luồng và cho phép NAT được xử lý chính xác ngay cả khi một bên của luồng nhìn thấy chính xác các địa chỉ và cổng giống nhau:
# conntrack -E
[MỚI] 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
[CẬP NHẬT] 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
[CẬP NHẬT] tcp 6 432000 ĐÃ THÀNH LẬP 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 [ĐẢM BẢO]
[MỚI] 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
[CẬP NHẬT] 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
[CẬP NHẬT] tcp 6 432000 ĐÃ THÀNH LẬP 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 [ĐẢM BẢO]
Điều khoản khác
linh tinh 1
Để máy ảnh có thể ping máy chủ hoặc nhận lỗi ICMP từ máy chủ, phải thêm cài đặt (toàn cầu) này:
sysctl -w net.ipv4.fwmark_reflect=1
mặt khác, câu trả lời ICMP không tuân theo định tuyến chính sách. Một cách khác tốt hơn là sử dụng CONNMARK/đánh dấu, nhưng nó sẽ làm cho câu trả lời phức tạp hơn một cách không cần thiết.
linh tinh 2
Kết quả làm việc không thể được kiểm tra chính xác từ chính RPi mà chỉ từ một máy khách trên mạng LAN (hoặc trên Internet với sự hỗ trợ từ bộ định tuyến của RPi). Cài đặt dành riêng cho trường hợp định tuyến.
Tùy chọn để máy chủ có thể hoạt động (và cho phép đặt proxy ngược), có thể thêm các cài đặt bổ sung này:
Chọn đúng giao diện ngay cả trước khi NAT xảy ra (yêu cầu kernel >= 4.17), nếu không socket sẽ chọn sai địa chỉ nguồn (của một giao diện khác) sau:
quy tắc ip thêm iif lo ipproto tcp dport 4431 tra cứu 4431
quy tắc ip thêm iif lo ipproto tcp dport 4432 tra cứu 4432
Điểm đến phải được DNATed trong nat/OUTPUT. Không cần tên wlx chính xác ở đây, tuyến đi chính xác đã được chọn bởi ngăn xếp định tuyến với quy tắc định tuyến mới (trả lời vẫn yêu cầu một phần của quy tắc iptables raw/PREROUTING từ câu trả lời chính). Và một theo dõi vùng trả lời cũng cần thiết trong raw/OUTPUT để xử lý các trường hợp xung đột hiếm gặp.
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 đánh dấu ! --mark 0 -j DNAT --to-destination :443
Các thử nghiệm trong trường hợp này nên được thực hiện từ RPi với:
cuộn tròn --không an toàn https://192.168.42.1:4431/
cuộn tròn --không an toàn https://192.168.42.1:4432/
linh tinh 3
Các cài đặt trong linh tinh 2 nếu được điều chỉnh để xử lý UDP cục bộ, đối với trường hợp khác với OP, có thể sẽ không đủ đối với một số trường hợp góc: UDP luôn cần hỗ trợ từ ứng dụng cục bộ khi ở trong môi trường nhiều nhà.
