私は次のように成功しました。
ip netns add quarantine
ip link add eth0-q type veth peer name veth-q
ip link add br0 type bridge
ip link set veth-q master br0
ip link set br0 up
ip link set veth-q up
ip link set eth0-q netns quarantine
ip netns exec quarantine ip link set lo up
ip netns exec quarantine ip link set eth0-q up
ip netns exec quarantine ip address add 192.168.66.5/24 dev eth0-q
ip netns exec quarantine dnsmasq --interface=eth0-q --dhcp-range=192.168.66.10,192.168.66.50,255.255.255.0
ip link set eno1 master br0
これにより、ネットワーク管理者を中断することなくdnsmasqインスタンスを実行でき、プライマリイーサネットインターフェイス（eno1）を介して接続されたデバイスに192.168.66.0/24からIPを取得できます。
その後、インターネットへのアクセスを許可することにしました。
ip address add 192.168.66.1/24 dev br0
iptables -A FORWARD -i wlp58s0 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -o wlp58s0 -o br0 -j ACCEPT
iptables -A FORWARD -j LOG
iptables -t nat -A POSTROUTING -o wlp58s0 -j MASQUERADE
sysctl -w net.ipv4.ipforward=1
sysctl -p
そのうち、wlp58s0は私たちの家のWiFiに接続されたWiFiインターフェイスです。また、前述のdnsmasqを終了し、次に置き換える必要がありました。
ip netns exec quarantine dnsmasq --interface=eth0-q \
--dhcp-range=192.168.66.10,192.168.66.50,255.255.255.0 \
--dhcp-option=3,192.168.66.1 --dhcp-option=6,8.8.8.8
これにより、eno1を介して接続されたデバイスはゲートウェイを見つけ、Google DNSサーバー8.8.8.8にDNSクエリを要求する方法を知ることができます。
これらすべてがうまくいきました。コンピュータを再起動した後、すべての設定が期待どおりに消え、すべてがうまくいきました。
しかし、最初の試みでは、パケット転送を有効にするためにインターネット上で見つけたアドバイスに従い、sysctlを使用する代わりに次のことを行いました。
echo 1 > /proc/sys/net/ipv4/ip_forward
私のデバイスをeno1（すでにIPがある）に接続した後、インターネットアクセスが許可されました。
ただし、マイコンピュータを再起動すると、対応するIP転送設定は続行されます。そして：1を書いたところに0を書くことは耐久性がありません。さらに悪いことは、初期設定（インターネットアクセスなし、IP展開のみ）が破損しているため、eno1のマイデバイスが最初に説明した設定からIPを取得できなくなることです。私はWiresharkを使用しています。 IPの要求はbr0で見ることができますが、veth-qでは消えて、見知らぬ人にも現れます。 veth-qではIPv6トラフィックのみが表示され、ipv4トラフィックは完全に消えました。 /proc/sys/net/ipv4/ip_forwardに0を書き込んでIP転送を手動で無効にしても役に立ちません。最後に、Linuxディストリビューション（Ubuntu）を再インストールし、echoコマンドを使用しないように注意し、sysctlを使用して作業を行いましたが、問題は発生しませんでした。
なぜこれが起こるのですか？私のコンピュータの他のすべてがうまく動作しているようですので、これは非常に奇妙で珍しい動作です。インターネットにアクセスでき、すべてが正常に戻ったようですが、ブリッジとvethの間のやりとりが失われました。
これに対する悟りは大変感謝します！
ベストアンサー1
したがって、私の初期の考えとは異なり、/proc/sys/net/ipv4/ip_forwardに1を書くことはいいえ質問。
問題はドッカーにあるようです。
ドッカーを無効にした後、ブリッジと仮想イーサネットでより正常な動作を観察しました。
私はこの答えのコメントで見つけることができるすべてを書く予定です（より正確にはdockerで問題を引き起こした原因）。しかし、少なくとも/proc/sysに1を手動で書くことは/net/ipv4/と安全に言うことができます。問題はip_forwardですか？これは技術的に私の問題を解決すると思います。