Изучив связанное руководство (https://pimylifeup.com/raspberry-pi-wifi-bridge/), я пришел к выводу, что это не руководство по мосту, а руководство по NAT/маршрутизатору. Даже в комментарии к нему также говорится:
Also, important to note that this setup is a wifi client NAT router, not technically a bridge.
Итак, чтобы использовать мост, следуйте инструкциям по мосту. Поскольку это Raspbian, Debian BridgeNetworkConnections должен быть достаточно хорошим. Упомянутый пакет bridge -utils на самом деле не нужен для его (устаревшей)brctl
команды, которую можно было бы полностью заменить современными iproute2 ip link
и (, если это действительно необходимо )bridge
, но для егоbridge-utils-interfaces
плагина для ifupdown конфигурации .
Таким образом, в конце концов, конфигурация может быть выполнена с помощью чего-то похожего на:
iface eth0 inet manual
iface eth1 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0 eth1
Не назначайте IP-адреса реальным интерфейсам, потому что теперь они становятся мостовыми портами, и их настройки уровня 3 будут игнорироваться. Также не обязательно, но мост должен унаследовать MAC-адрес своего первого интерфейса. Поэтому, если это действительно важно и вы предпочитаете использовать MAC-адрес eth1, укажите его первым в команде bridge_ports
(, это, вероятно, также изменит предложение DHCP маршрутизатора ).
Теперь измените любую ссылку на eth0
в различных настройках, которая вместо этого указывает интерфейс на br0
, но есть вероятность, что вам это даже не нужно, так как, например, вам больше не нужно dnsmasq
. Вот и все.
Дополнительная информация:
Если вы когда-либо использовали iptables
вместо или в дополнение к ebtables
, чтобы попытаться выполнить фильтрацию между двумя интерфейсами (подсказка :, вы, вероятно, не должны, теперь это мост, а не маршрутизатор, но это необходим для прозрачного моста брандмауэра с отслеживанием состояния ). Помните, что при активации br -netfilter специального взаимодействия между фильтрацией моста и уровнями IP-фильтрации:взаимодействие ebtables/iptables на Мост на базе Linux -. Это может привести к трудным результатам отладки с -по -, если об этом не знать.
Многиеtc qdisc
эффекты (, такие как netem
), работают только в исходящем направлении (на выходе ). Поскольку вы находитесь между обоими интерфейсами eth0
и eth1
, вы можете подумать, что вы всегда можете найти выходной интерфейс для определенного предполагаемого действия, но если это делается на eth0
, то сам RPi может быть затронут в Интернете. стороны, что, вероятно, не то, что хотелось бы. Этого можно избежать, подключив промежуточный функциональный блок (ifb0
)к eth1
:, что искусственно вставит интерфейс между входом и остальным сетевым кодом. Таким образом, этот интерфейс теперь является исходящим интерфейсом с точки зрения входящего потока данных eth1
и может успешно принимать исходящие функции, такие как netem
. Для любой другой интерпретации это часть входящего потока. Теперь вы можете применить TC к eth1
и ifb0
и не трогать eth0
. Больше информации в моем ответе:Моделирование потери пакетов на мостовом интерфейсе с использованием netem
В zsh
вы всегда можете сделать (какroot
)что-то вроде:
(cd tmp/ftp && tar cf - new-assests/) \
> >(USERNAME=user1; cd ~user1/tmp && tar xopf -) \
> >(USERNAME=user2; cd ~user2/html-stuff && tar xopf -)
При этом используются двеzsh
-особенности:
$USERNAME
изменяет процесс оболочки EUID, UID, GID, EGID и дополнительные gids на пользователя в соответствии с пользовательской базой данных (, как если бы пользователь вошел в систему с этим именем пользователя ). Обратите внимание, что если пользователь не существует в базе данных, это будет молча игнорироваться USERNAME=username
, но cd ~username
затем завершится ошибкой и вызовет выход подоболочки. tee
поведение для отправки вывода на две цели (, включенные с опцией mult_ios
, включено по умолчанию ). Это экономит чтение источника дважды. Обратите внимание, что если какой-либо из tar
процессов распаковки прекратит работу, это, скорее всего, прервет весь конвейер.
ksh
или bash
не имеют этого изменения -пользовательских функций, но вместо них можно использовать su
или sudo
, если они доступны, и tee
вместо функции multios
:
(cd tmp/ftp && tar cf - new-assests/) |
tee >(cd ~user1/tmp && sudo -u user1 tar xopf -) |
(cd ~user2/html-stuff && sudo -u user2 tar xopf -)
Это предполагает, что целевой пользователь имеет разрешение на запись в целевой каталог.
Некоторые реализации tar
имеют опции --owner
/--group
или -chown
/-chgrp
для переопределения имен пользователей и групп файлов, хранящихся в архиве. Таким образом, другим вариантом было бы сделать что-то вроде:
(cd tmp/foo && tar --owner=user1 --group="$(id -g user1)" -cf - new-assets) |
(cd ~user1/tmp && tar xpf -)
И повторить для user2
.
В любом из этих случаев вы можете подумать о том, что делать, если файлы имеют списки управления доступом, поскольку универсального решения для всех не существует.
Использованиеrsync
:
rsync -ai --chown=user1 tmp/ftp/new-assests/ ~user1/tmp/
Это скопирует каталог в указанное место и в то же время изменит владельца файлов на user1
, если это разрешено.
Общая форма аргумента для --chown
— USER:GROUP
, но вы также можете использовать просто USER
, чтобы установить конкретного пользователя в качестве владельца, как указано выше,или просто :GROUP
для установки конкретной группы (:
не является обязательным, если вы не указываете идентификатор пользователя ).