我在 LXC 中遇到了连接问题，这让我很抓狂。这些问题时断时续。它们会在某个时间出现，然后突然消失。
设想
主机内的 lxc。两者都运行 Debian GNU/Linux 8.3 在 lxc 中安装了 Piwik（用于统计的开源 PHP 软件，带有 apache、mysql）和 ssh 服务器。lxc apache 可通过主机中的 nginx 代理访问
lxc 配置：
lxc.tty = 6
lxc.pts = 1024
lxc.rootfs = /var/lib/lxc/hammond/rootfs
lxc.cgroup.devices.deny = a
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
# consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
lxc.cgroup.devices.allow = c 4:1 rwm
# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
# rtc
lxc.cgroup.devices.allow = c 254:0 rwm
# mounts point
lxc.mount.entry=proc /var/lib/lxc/hammond/rootfs/proc proc nodev,noexec,nosuid 0 0
lxc.mount.entry=devpts /var/lib/lxc/hammond/rootfs/dev/pts devpts defaults 0 0
lxc.mount.entry=sysfs /var/lib/lxc/hammond/rootfs/sys sysfs defaults 0 0
# networking
lxc.utsname = hammond
lxc.network.type = veth
#lxc.network.macvlan.mode = private
lxc.network.flags = up
lxc.network.link = br-hammond
lxc.network.ipv4 = 192.168.100.2/24
lxc.network.ipv4.gateway = 192.168.100.1
lxc.network.hwaddr = 00:1E:10:C1:6B:C9
lxc.start.auto = 1
# http://serverfault.com/questions/658052/systemd-journal-in-debian-jessie-lxc-container-eats-100-cpu
lxc.autodev = 1
lxc.kmsg = 0
问题：
1. 无法连接本地数据库
突然，Piwik 报告：
SQLSTATE[HY000] [2003] 无法连接到‘127.0.0.1’上的 MySQL 服务器 (111)
当然，数据库正在运行。
- 如果我从 lxc 内部（127.0.0.1:3306）进行 telnet，我可以连接到数据库
- 如果我从 lxc (127.0.0.1:80) 内部 telnet apache，Piwik 工作正常。它连接到数据库，照常呈现页面，并且不报告任何错误。
- 如果我从主机（192.168.100.2:80）telnet apache，Piwik 会报告数据库错误。
2. SSH 冻结
我正在使用隧道将 ssh 连接到 lxcProxyCommand
ProxyCommand ssh -q host nc -q0 192.168.100.2 22
在 ssh 协商阶段之后，连接冻结。如果我输入密钥，它们不会显示在控制台中。最后，连接超时，
packet_write_wait：连接到未知：管道损坏
我用 tcpdump 嗅探了数据包，SSH 密钥交换正常。然后，流量在 0.5 秒后停止
我认为这是上次 Debian 内核更新中的一个错误。它以前运行良好，但几周前我就遇到了这些问题。正如我所说，这些问题是间歇性的。突然间，一切都正常了。
欢迎就如何进一步调查提出建议
答案1
我也遇到过同样症状的问题。就我而言，在桥接器中使用的 VLAN 上还有另一个具有相同 IP 的主机。有时，另一台主机会更快地响应 ARP 请求（尽管是另一台物理机器），此时 lxc 客户机会在其 ARP 表中保存错误的 MAC 地址，并继续将以太网帧发送到错误的地址，直到另一个 ARP 请求“解决”了该问题。
我通过从主机到客户机的带时间戳的 ping 来诊断了这个问题：
# ping -n 10.70.70.10 | perl -nle 'BEGIN {$|++} print scalar(localtime), " ", $_' |tee -a ping10707010.log
[...]
Sun Jul 31 09:18:53 2016 64 bytes from 10.70.70.10: icmp_seq=3389 ttl=64 time=0.035 ms
Sun Jul 31 09:18:54 2016 64 bytes from 10.70.70.10: icmp_seq=3390 ttl=64 time=0.035 ms
Sun Jul 31 09:18:55 2016 64 bytes from 10.70.70.10: icmp_seq=3391 ttl=64 time=0.027 ms
Sun Jul 31 09:19:45 2016 64 bytes from 10.70.70.10: icmp_seq=3441 ttl=64 time=0.064 ms
Sun Jul 31 09:19:46 2016 64 bytes from 10.70.70.10: icmp_seq=3442 ttl=64 time=0.038 ms
Sun Jul 31 09:19:47 2016 64 bytes from 10.70.70.10: icmp_seq=3443 ttl=64 time=0.036 ms
以及主机和客户机上的 tcpdump：
# tcpdump -n -i brv3001 # on the host
[...]
09:18:55.724751 IP 10.70.0.1 > 10.70.70.10: ICMP echo request, id 26519, seq 3391, length 64
09:18:55.724768 IP 10.70.70.10 > 10.70.0.1: ICMP echo reply, id 26519, seq 3391, length 64
09:18:56.336109 ARP, Request who-has 10.70.70.10 tell 10.70.0.1, length 42
09:18:56.336147 ARP, Reply 10.70.70.10 is-at 00:16:3e:46:46:0a, length 28
[...]
09:19:44.728738 ARP, Request who-has 10.70.70.10 tell 10.70.0.1, length 28
09:19:44.728769 ARP, Reply 10.70.70.10 is-at 00:16:3e:46:46:0a, length 28
# tcpdump -n -i infra0 # on the guest
[...]
09:18:55.724757 IP 10.70.0.1 > 10.70.70.10: ICMP echo request, id 26519, seq 3391, length 64
09:18:55.724767 IP 10.70.70.10 > 10.70.0.1: ICMP echo reply, id 26519, seq 3391, length 64
09:18:56.336123 ARP, Request who-has 10.70.70.10 tell 10.70.0.1, length 42
09:18:56.336144 ARP, Reply 10.70.70.10 is-at 00:16:3e:46:46:0a, length 28
[...]
09:19:44.728745 ARP, Request who-has 10.70.70.10 tell 10.70.0.1, length 28
09:19:44.728766 ARP, Reply 10.70.70.10 is-at 00:16:3e:46:46:0a, length 28
这让我明白在网络断线和重新激活时，会发出 ARP 请求并回答。ARP 请求似乎是正确的（使用正确的 MAC），但我还是决定检查操作系统看到的事实，因此我在主机和客户机上记录了带有时间戳的 ARP 表：
# while true; do date; arp -n; sleep 1; done > arp.log 2>&1 # on the host
[...]
Sun Jul 31 09:18:55 CEST 2016
Address HWtype HWaddress Flags Mask Iface
10.70.70.10 ether 00:16:3e:46:46:0a C brv3001
Sun Jul 31 09:18:56 CEST 2016
Address HWtype HWaddress Flags Mask Iface
10.70.70.10 ether 00:16:3e:46:46:0a C brv3001
# while true; do date; arp -n; sleep 1; done > arp.log 2>&1 # on the guest
Sun Jul 31 09:18:55 CEST 2016
Address HWtype HWaddress Flags Mask Iface
10.70.0.1 ether 00:1e:68:4a:03:b0 C infra0
Sun Jul 31 09:18:56 CEST 2016
Address HWtype HWaddress Flags Mask Iface
10.70.0.1 ether c4:34:6b:22:b6:7c C infra0
这让我明白主机没有错误的客户机 MAC，但客户机以某种方式到达了错误的主机 MAC。令人恼火的是，这并没有反映在 tcpdump 信息中。（注意：libpcap 或 ip 堆栈中的某个地方可能存在竞争条件，调查一下会有所帮助）
找到错误的 MAC 地址后，我查找了错误的 MAC 地址属于哪个供应商，从而找到了有问题的机器。如果这些信息比较模糊，我相信我的交换机应该能够帮助我找到正确的交换机端口。
我认为，通过改变时间、略微不同的行为、其他网络服务处于活动状态等方式，升级/降级内核和某些用户空间工具可能会改变甚至消除全部或部分症状。例如，从客户机到主机的 ping 可以可靠地“修复”我的问题。
另外，请不要忘记，您可以看到的 IP 地址ifconfig并不是系统使用的所有 IP 地址。ip addr ls在 Linux 上会更全面，甚至一些更高级的iptables配置也可能发挥作用。如果您运气不好，响应 arp 的主机甚至可能有一个损坏的 IP 堆栈。如果您的网络没有正确隔离，您甚至可能会收到来自 ISP 其他客户的 ARP 回复。
我意识到这可能不是您的问题的确切解决方案，但我想留下一些调试指针，以便下一个人在 serverfault 上寻找并发现此问题。
答案2
我认为您的数据库问题可能是 Apache/Piwik/MySQL 的配置问题。
但是我们观察到 SSH（和其他应用程序）的连接问题，从“连接被拒绝”到您描述的情况（连接出现，提示显示，然后连接悄悄中断）。
类似地，几个应用程序（邮件、网络）“感觉很慢”（对我们和至少我们的一个根服务器客户来说），目前我猜测客户端（邮件客户端、网络浏览器）正在执行多次连接尝试和/或重新连接，足以减慢它们的速度，但还不至于严重到出现错误消息（或触发来自我们 3 个外部 Icange 监视器的警报）。
该设置并不新鲜，它与 Debian Wheezy + OpenVZ-Kernel + OpenVZ（来自 OpenVZ 的 debian repo 的 OpenVZ 产品）一起完美运行了 2 年。
我们最近（几天前）迁移到了 Debian Jessie + 反向移植内核（由于 DRBD 修复）+ LXC，没有改变其他任何东西（相同的两对超大服务器硬件、相同的住房中心、相同的虚拟化客户机）。
因此，作为第一个结论，我们也“感觉”有些地方不对劲，要么是内核错误，要么是一些与 TCP 相关的 LXC 限制，但没有人知道。
“感觉”这个词有点模糊，但目前很难准确描述。但我们确实知道，我们遇到了一个问题，它发生得太频繁了，以至于有太多不同的客户无法责怪其他任何事情。
顺便说一下，问题似乎主要打击那些已经闲置了一段时间、大部分时间什么都不做的客户端。
它似乎也有助于通过 SSH 连接以及 LAN/DMZ 和 WAN 网络活动（如 ping）来“唤醒它们”。
我们使用 veth/br0 风格的网络设置，并为客人的 eth 设置自定义 MAC。
有一次，我从一个已停止的 LXC 客户机（可从 MAC 识别）获得了一个幻影 IP，但我认为我犯了一个错误，即在该客户机启动和停止之间更改了 LXC 客户机的配置。
Debian 内核版本为：4.3.0-0.bpo.1-amd64 #1 SMP Debian 4.3.3-5~bpo8+1 (2016-01-07) x86_64
附言：
问题@Antonio Tapiador：您使用哪个内核版本？您使用 VLAN 吗？
我们正在讨论此补丁 我们发现 4.3.4 更新日志可能有帮助。
PPS：为什么我必须使用“答案”来评论？
PPPS，也就是我们的解决方案： 从内核 4.3.3 降级到 4.2.6（均在 jessie-backports 中）似乎解决了我们的问题。
当然，很难确定问题何时是间歇性的。如果你使用 jessie 的 3.16 内核，我建议你尝试从 jessie-backports 升级到 4.2，即软件包 linux-image-4.2.0-0.bpo.1-amd64。
4.2 也没有得到 kernel.org 的长期支持，但至少 Canonical 维护对 Ubuntu 15.10 的支持，并且基于 Debian 的虚拟化发行版 Proxmox 现在也使用 4.2（像我们一样，他们正在从 OpenVZ 切换到 LXC）。
更新 2016-04-07：问题并没有在 4.3 中完全解决。升级到 4.4（Kernel.org 和 Ubuntu 的 LTS）也没有完全解决。不过，我们将尝试使用临时 LTE 线路，以 100% 确保这不是我们的接入提供商...
更新 2016-08-29：我们现在确定存在问题。糟糕的 4.3 内核和我们即将抛弃的住房提供商。4.4/4.6 和 LXC/DRBD 还存在另一个严重问题，但这不是主题。