更新：
暂时离开这个问题之后，我意识到有一件事我可以检查或测试，而我还没有这样做过。
恢复到旧版本的 Linux 使我能够解决这个问题，但仍然重要的问题是：在新版本的 Linux 上，缺少什么才能使这个功能正常工作？
Linux nas 4.19.13-1-lts #1 SMP 2018 年 12 月 30 日星期日 07:38:47 CET x86_64 GNU/Linux
原文：
问题：我还应该检查什么来尝试隔离和修复这个问题，以便桥接网络到 LXC 'vm' 再次工作？
为了调试此问题，我禁用了正常的 LXC 容器启动。相反，我使用附加日志手动运行它们。
lxc-start --logfile=/var/log/lxc/debug.$(date +%Y%m%d-%H%M%S).log --logpriority=DEBUG -F -n 容器名称
LAN 主机可以 ping 通/与主机通信 主机可以 ping 通/与 LAN 主机通信
两条不同的痕迹
在桥上：正如预期的那样
tcpdump -pi bridge port 67 or port 68 or icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply
(time) IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from (mac) (oui Unknown)...
但它并没有被中继/转发到物理网络设备：
tcpdump -i bridge_IF port 67 or port 68 or icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply
(no dhcp packets)
这座桥看起来正确
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.bridgemac no enpNs0
enpNs0
vethXXXXXX
那里的一切看上去基本都符合预期。
(provided by iptables-nft)
ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
nft list ruleset
table bridge filter {
chain INPUT {
type filter hook input priority -200; policy accept;
}
chain FORWARD {
type filter hook forward priority -200; policy accept;
}
chain OUTPUT {
type filter hook output priority -200; policy accept;
}
}
table ip filter {
chain INPUT {
type filter hook input priority 0; policy accept;
}
chain FORWARD {
type filter hook forward priority 0; policy accept;
}
chain OUTPUT {
type filter hook output priority 0; policy accept;
}
}
还有 sysctl 和模块配置项。
# cat /etc/sysctl.d/*
net.bridge.bridge-nf-call-iptables=0
kernel.unprivileged_userns_clone=1
# lsmod | grep table
nf_tables 147456 2 nft_reject_ipv6,nft_reject
nfnetlink 16384 1 nf_tables
x_tables 49152 1 ip6t_REJECT
# cat /etc/modprobe.d/*
blacklist ip_tables
blacklist iptable_filter
blacklist iptable_nat
blacklist ip6_tables
blacklist ip6table_filter
blacklist x_tables
install br_netfilter
--
到目前为止，一切看上去都应该正常，但事实并非如此。
(container) # ip addr add x.x.x.x/y dev z
(container) # ping VMHOST
Works, ping reply.
(container) # ping ROUTER-GW
Nope, Destination Host Unreachable
然而，现在发生了一些真正出乎意料的事情（或者说，没有发生）。
(VHMOST) # ping ROUTER-GW
Nope, Destination Host Unreachable
Also, the connection to the VMHOST (often) times out at this point.
最后的转折似乎指向一个我至今还没有检查过的问题，我不确定 Linux 命名空间中是否有任何内容与这个问题有关。
查看 LXC 日志没有发现任何明显的东西，但我复制了我认为可能相关的所有内容。实际上没有说明，但我确实怀疑命名空间是否以某种方式被弄乱了。
lxc-start VM TIMESTAMP.390 DEBUG network - network.c:setup_hw_addr:2767 - Mac address "REDACTED" on "eth0" has been setup
lxc-start VM TIMESTAMP.393 INFO conf - conf.c:mount_entry:2039 - No such file or directory - Failed to mount "/sys/fs/fuse/connections" on "/usr/lib/lxc/rootfs/sys/fs/fuse/connections" (optional)
lxc-start VM TIMESTAMP.510 INFO utils - utils.c:lxc_mount_proc_if_needed:1239 - I am 1, /proc/self points to "1"
lxc-start VM TIMESTAMP.536 WARN conf - conf.c:lxc_setup_devpts:1641 - Invalid argument - Failed to unmount old devpts instance
lxc-start VM TIMESTAMP.536 DEBUG conf - conf.c:lxc_setup_devpts:1678 - Mount new devpts instance with options "gid=5,newinstance,ptmxmode=0666,mode=0620,max=1024"
lxc-start VM TIMESTAMP.537 INFO conf - conf.c:setup_personality:1741 - Set personality to "0x0"
lxc-start VM TIMESTAMP.537 DEBUG conf - conf.c:setup_caps:2550 - Dropped mac_admin (33) capability
lxc-start VM TIMESTAMP.537 DEBUG conf - conf.c:setup_caps:2550 - Dropped mac_override (32) capability
lxc-start VM TIMESTAMP.537 NOTICE conf - conf.c:lxc_setup:3745 - The container "VM" is set up
Linux salt 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64 GNU/Linux
# pacman -Qs lxc
local/lxc 1:3.1.0-1
答案1
嘿，关注电子邮件中的所有链接，以确保其他点击此链接的人知道该做什么。
申请： https://marc.info/?l=linux-netdev&m=154696956604748&w=2
已帮我修复，与 fq 节奏有关