Презентация
Эту проблему можно решить, используя сетевые пространства имен, тем самым разделив единую систему Pi на X-маршрутизаторы, выполняющие NAT. Вот что следует сделать. Увы, я не знаю, как написать ответ, который не только должен включать, как переместить интерфейсы Wi-Fi в новое сетевое пространство имен (требуются совместимые драйверы и iw phy phyX set netns ... вместо ip link set wlanX...netns...) но и особенно связанные с ними wpa_supplicant и демоны DHCP-клиента с соответствующими настройками системной интеграции. Это требует хороших знаний о том, как конкретная система настроена с беспроводной связью и DHCP.
Вместо этого этот ответ избегает использования сетевых пространств имен и позволяет избежать перенастройки обработки wpa_supplicant и клиент DHCP: он использует маршрутизацию политики.
Использование меток в маршрутизации политики неизбежно в этом случае, когда стек маршрутизации будет видеть только порт назначения 443, а не 4431/4432 (DNAT уже изменил его ранее). Метки также будут использоваться пользователем для установки зон conntrack (ответа), чтобы быть уверенным в том, что они обработают случай, когда несколько камер назначают один и тот же IP-адрес своему соответствующему хост-интерфейсу.
Строгая переадресация обратного пути (SRPF) должен быть расслабленный к Свободный РПФ в случае, если Strict был установлен по умолчанию, потому что обработка ARP не получит отметки и может остаться заблокированной.
Поскольку камеры могут не устанавливать свой маршрут по умолчанию к клиенту, а могут иметь только маршрут LAN, также будет выполняться двойной NAT (источник и пункт назначения).
Настраивать
Поскольку ОП не предоставил никаких eth0 настройки, здесь их нет. Ответ пытается не слишком сильно зависеть от этого, но OP должен будет адаптировать его, если это необходимо (особенно если не все 7 беспроводных интерфейсов будут иметь свое имя, начинающееся с влкс).
Скорректируем цель:
192.168.42.0/24 представляет несколько перекрывающихся IP-сетей, к которым нельзя напрямую обращаться, чтобы защитить внешних клиентов от всех возможных сложностей маршрутизации.
Таким образом, адрес 192.168.42.250 использоваться не будет. Видимый адрес Pi 192.168.0.205 будет использоваться удаленными клиентами.
Любой доступ HTTPS получит неверный сертификат. Смиритесь с этим: я даю ответ, основанный на настройке параметров сети, но он не будет включать настройку обратного прокси-сервера, чтобы скрыть проблему с сертификатом. Добавление такого обратного прокси-сервера также требует дополнительных настроек сети (добавлено в качестве опции в конце). Тесты можно выполнять с клиента (но не с RPi) с помощью:
завиток --небезопасный https://192.168.0.205:4431/
завиток --небезопасный https://192.168.0.205:4432/
Кроме того, чтобы показать несколько примеров ниже, я взял случай, когда обе камеры назначили хосту один и тот же IP-адрес, чтобы он отображался на двух интерфейсах, чтобы поднять планку. Это не имеет значения. Большинство этих настроек необходимо выполнить после того, как будут установлены все беспроводные соединения, а не до этого. Я не буду говорить о том, как интегрировать это с конкретной ОС Linux, которая с этим справляется.
Все команды должны выполняться от имени root.
Примеры основаны на:
# ip маршрут
по умолчанию через 192.168.0.1 dev wlan0
192.168.0.0/24 dev wlan0 прото-область ядра ссылка src 192.168.0.205
192.168.42.0/24 dev wlxb8b7f16a0602 ссылка на область действия ядра src 192.168.42.10 метрика 600
192.168.42.0/24 dev wlxb8b7f16a04cd ссылка на область действия ядра src 192.168.42.10 метрика 600
Правила маршрутизации для выбора дополнительных таблиц маршрутизации, которые будут изолировать дублирующую локальную сеть каждой камеры от локальной сети другой камеры:
ip правило добавить fwmark 1 поиск 4431
ip правило добавить fwmark 2 поиск 4432
ip route add 192.168.42.0/24 dev wlxb8b7f16a0602 таблица 4431
ip route add 192.168.42.0/24 dev wlxb8b7f16a04cd таблица 4432
Это обеспечивает работу маршрутизации от клиента к камерам (если у RPi нет маршрута по умолчанию, в приведенных ниже примерах с использованием 192.0.2.2 для проверки маршрутов вместо этого можно использовать 192.168.0.101):
# ip route получить отметку 2 от 192.0.2.2 iif wlan0 192.168.42.1
192.168.42.1 из 192.0.2.2 dev wlxb8b7f16a04cd таблица 4432 метка 2
кеш iif wlan0
но все еще не для ответов, если SRPF включен:
# ip route get mark 2 from 192.168.42.1 iif wlxb8b7f16a04cd 192.0.2.2
Ответы RTNETLINK: недействительная ссылка между устройствами
Итак, почти недокументированный флаг должны быть установлены на интерфейсах камеры:
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 с 192.168.42.1 через 192.168.0.1 dev wlan0 метка 2
кэш 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 ПРЕДВАРИТЕЛЬНАЯ МАРШРУТИЗАЦИЯ -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 0 -j DNAT --к месту назначения 192.168.42.1:443
iptables -t nat -A POSTROUTING -o wlx+ -j MASQUERADE
Если будет добавлен третий интерфейс с именем wlx3, выполните следующие действия. Это может быть обобщено таким же образом для большего количества:
Добавьте новое правило ip, выбранное с новой отметкой (3), которое будет использовать новую таблицу маршрутизации (4433):
ip правило добавить fwmark 3 поиск 4433
Добавьте соответствующую новую таблицу маршрутизации с ее записью, более или менее дублирующей маршрут LAN основной таблицы для нового интерфейса:
ip route добавить 192.168.42.0/24 dev wlx3 таблица 4433
Ослабьте RPF на этом интерфейсе, если ОС по умолчанию использует SRPF (как сказано 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
(Если имя нового интерфейса не начинается с влкс Добавить новое нат правила соответственно.)
Вот пример коннтрек обработка, когда клиент дважды подключается, даже используя один и тот же исходный порт, к двум портам, в то время как RPi получил один и тот же IP-адрес, назначенный двум беспроводным интерфейсам wlx. коннтрек zone включена в выбор потока и позволяет корректно обрабатывать NAT, даже если одна сторона потоков видит точно такие же адреса и порты:
# коннтрек -E
[НОВОЕ] tcp 6 120 SYN_SENT 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
[ОБНОВЛЕНИЕ] 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
[ОБНОВЛЕНИЕ] 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]
[НОВОЕ] tcp 6 120 SYN_SENT 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
[ОБНОВЛЕНИЕ] 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
[ОБНОВЛЕНИЕ] TCP 6 432000 УСТАНОВЛЕНО 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
Разнообразный
разное 1
Чтобы камера могла пинговать хост или получать ICMP-ошибки от хоста, необходимо добавить этот (глобальный) параметр:
sysctl -w net.ipv4.fwmark_reflect = 1
в противном случае ответ ICMP не соответствует политике маршрутизации. Другой лучший способ - использовать СОЕДИНЕНИЕ/коннмарк, но это сделало бы ответ излишне сложным.
Разное 2
Рабочий результат не может быть правильно протестирован с самого RPi, а только с клиента в локальной сети (или в Интернете при поддержке маршрутизатора RPi). Настройки специфичны для случая маршрутизации.
При желании, чтобы хост мог работать (и чтобы можно было установить обратный прокси-сервер), можно добавить следующие дополнительные настройки:
Выберите правильный интерфейс еще до того, как произойдет NAT (требуется ядро > = 4.17), иначе позже сокет выберет неправильный исходный адрес (другого интерфейса):
ip правило добавить iif lo ipproto tcp dport 4431 поиск 4431
ip правило добавить iif lo ipproto tcp dport 4432 поиск 4432
Пункт назначения должен быть ДНКТирован в nat/OUTPUT. Здесь нет необходимости в точном имени wlx, правильный исходящий маршрут уже выбран стеком маршрутизации с новыми правилами маршрутизации (для ответа по-прежнему требуется часть правил iptables raw/PREROUTING из основного ответа). И коннтрек зона ответа также необходима в raw/OUTPUT для обработки редких случаев конфликта.
iptables -t raw -A ВЫВОД -o wlx+ -p tcp --dport 4431 -j MARK --set-mark 1
iptables -t raw -A ВЫВОД -m mark --mark 1 -j CT --zone-reply 1
iptables -t raw -A ВЫВОД -o wlx+ -p tcp --dport 4432 -j MARK --set-mark 2
iptables -t raw -A ВЫВОД -m mark --mark 2 -j CT --zone-reply 2
iptables -t nat -A ВЫВОД -p tcp -m отметка! --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
Настройки в разное 2 если он адаптирован для локальной обработки UDP, для случая, отличного от OP, вероятно, будет недостаточно для некоторых крайних случаев: UDP всегда нуждается в поддержке со стороны локального приложения в многосетевой среде.
