来自容器的 ping6 echo 请求部分丢失

来自容器的 ping6 echo 请求部分丢失

谢谢kasperd 对“ipv6 ping 主机无法到达目标主机,直到运行 tcpdump”的回应我了解到 tcpdump 将监听的接口置于混杂模式。使用 tcpdump 时,我总是收到重复的回复 –如果我收到回覆。

我有两台服务器(一台是提供商的虚拟服务器,另一台是不同数据中心的物理服务器),两台服务器都使用 IPv4 和 IPv6 配置。我可以在两种协议上 ping 两台服务器,没有任何问题。但在我的虚拟服务器上,我有一些容器(systemd-nspawn,但任何东西也应该适用于 Linux 容器 (LXC)),它们使用桥接设备 br0 进行联网,该设备桥接我的物理接口和所有容器接口(缩短列表):

bridge name bridge id       STP enabled interfaces
br0     8000.0af08597bb89   no      ens3
                            vb-blog
[…]
                            vb-ttrss-alt
                            vb-web-proxy

systemd-nspawn 使用 systemd-networkd 配置网络接口、路由和防火墙。使用 IPv4 时,容器内外一切都运行正常。但使用 IPv6 时,我遇到了严重的包丢失(?)。我目前的观察结果如下:

  • 容器中的 tcpdump 很无聊,所有数据包都离开接口
  • 在桥接至 br0 的 veth 接口上执行 tcpdump 可显示所有到达的数据包
[root@persephone: ~]# tcpdump -e -n -i vb-ttrss-alt icmp6 and host 2a01:4f8:192:8370::2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vb-ttrss-alt, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:26:32.145734 ea:eb:e8:a1:43:37 > 0a:f0:85:97:bb:89, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 1, length 64
13:26:32.145783 0a:f0:85:97:bb:89 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32::1 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 1, length 64
13:26:32.148557 10:0e:7e:26:f1:c0 > ea:eb:e8:a1:43:37, ethertype IPv6 (0x86dd), length 118: 2a01:4f8:192:8370::2 > 2a03:4000:59:b32:e8eb:e8ff:fea1:4337: ICMP6, echo reply, id 37732, seq 1, length 64
13:26:33.147017 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 2, length 64
13:26:34.149101 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 3, length 64
13:26:35.162442 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 4, length 64
13:26:36.175835 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 5, length 64
13:26:37.189173 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 6, length 64
13:26:38.202496 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 7, length 64
13:26:39.215765 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 8, length 64
13:26:40.229177 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 9, length 64
13:26:41.242498 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 10, length 64
13:26:45.298400 ea:eb:e8:a1:43:37 > 0a:f0:85:97:bb:89, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 14, length 64
13:26:45.298430 0a:f0:85:97:bb:89 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32::1 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 14, length 64
13:26:45.301201 10:0e:7e:26:f1:c0 > ea:eb:e8:a1:43:37, ethertype IPv6 (0x86dd), length 118: 2a01:4f8:192:8370::2 > 2a03:4000:59:b32:e8eb:e8ff:fea1:4337: ICMP6, echo reply, id 37732, seq 14, length 64
13:26:46.299646 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 15, length 64
13:26:47.325802 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 16, length 64
13:26:48.335803 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 17, length 64
13:26:49.349148 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 18, length 64
13:26:50.362468 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 19, length 64
13:26:51.375801 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 20, length 64
13:26:52.389144 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 21, length 64
13:26:53.402445 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 22, length 64
13:26:57.455790 ea:eb:e8:a1:43:37 > 0a:f0:85:97:bb:89, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 26, length 64
13:26:57.455842 0a:f0:85:97:bb:89 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32::1 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 26, length 64
13:26:57.458657 10:0e:7e:26:f1:c0 > ea:eb:e8:a1:43:37, ethertype IPv6 (0x86dd), length 118: 2a01:4f8:192:8370::2 > 2a03:4000:59:b32:e8eb:e8ff:fea1:4337: ICMP6, echo reply, id 37732, seq 26, length 64
13:26:58.457228 ea:eb:e8:a1:43:37 > 00:00:5e:00:02:02, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32:e8eb:e8ff:fea1:4337 > 2a01:4f8:192:8370::2: ICMP6, echo request, id 37732, seq 27, length 64
  • 在收到回声答复之前,会有几秒钟的延迟。
  • 成功 ping 的间隔在 12 秒到更长的时间之间变化。这似乎取决于我在其中一个连接的会话中执行的操作。空闲时,间隔在 12 到 13 秒之间。
  • br0 上的 tcpdump 基本相同。
  • 如果没有,-p我在容器中得到 DUP,在 tcpdump 中显示如下:
13:30:09.885327 10:0e:7e:26:f1:c0 > ea:eb:e8:a1:43:37, ethertype IPv6 (0x86dd), length 118: 2a01:4f8:192:8370::2 > 2a03:4000:59:b32:e8eb:e8ff:fea1:4337: ICMP6, echo reply, id 37732, seq 216, length 64
13:30:09.885343 0a:f0:85:97:bb:89 > ea:eb:e8:a1:43:37, ethertype IPv6 (0x86dd), length 118: 2a01:4f8:192:8370::2 > 2a03:4000:59:b32:e8eb:e8ff:fea1:4337: ICMP6, echo reply, id 37732, seq 216, length 64
  • 随着-pDUP 的消失。
  • 在目标机器上只有一些数据包到达:
root@neptun3 ~ # tcpdump -e -n -i enp2s0 icmp6 and net 2a03:4000:59:b32::/64
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:34:49.698515 0c:86:10:ed:37:1a > 44:8a:5b:5d:cf:11, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32::1 > 2a01:4f8:192:8370::2: ICMP6, echo request, seq 8, length 64
13:34:49.698591 44:8a:5b:5d:cf:11 > 0c:86:10:ed:37:1a, ethertype IPv6 (0x86dd), length 118: 2a01:4f8:192:8370::2 > 2a03:4000:59:b32::1: ICMP6, echo reply, seq 8, length 64
13:35:02.871916 0c:86:10:ed:37:1a > 44:8a:5b:5d:cf:11, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32::1 > 2a01:4f8:192:8370::2: ICMP6, echo request, seq 21, length 64
13:35:02.871978 44:8a:5b:5d:cf:11 > 0c:86:10:ed:37:1a, ethertype IPv6 (0x86dd), length 118: 2a01:4f8:192:8370::2 > 2a03:4000:59:b32::1: ICMP6, echo reply, seq 21, length 64
13:35:16.045152 0c:86:10:ed:37:1a > 44:8a:5b:5d:cf:11, ethertype IPv6 (0x86dd), length 118: 2a03:4000:59:b32::1 > 2a01:4f8:192:8370::2: ICMP6, echo request, seq 34, length 64
13:35:16.045221 44:8a:5b:5d:cf:11 > 0c:86:10:ed:37:1a, ethertype IPv6 (0x86dd), length 118: 2a01:4f8:192:8370::2 > 2a03:4000:59:b32::1: ICMP6, echo reply, seq 34, length 64

容器主机上用于桥接网络的 systemd.network 文件是

[Match]
Name=br0

[Network]
Description=uplink interface
Address=202.61.199.186/22
Gateway=202.61.196.1
DNS=9.9.9.9
DNS=149.112.112.112

Address=2a03:4000:59:b32::1/64
Gateway=fe80::1
#IPv6AcceptRA=yes
DNS=2620:fe::fe
DNS=2620:fe::9

DHCPServer=yes
IPMasquerade=both
LLDP=yes
EmitLLDP=customer-bridge
IPv6SendRA=yes
DHCPPrefixDelegation=yes

[IPv6Prefix]
Prefix=2a03:4000:59:b32::/64

[DHCPServer]
ServerAddress=192.168.104.1/24
EmitDNS=yes
DNS=9.9.9.9 149.112.112.112
EmitRouter=yes
EmitTimezone=Europe/Berlin

veth接口的主机端:

# SPDX-License-Identifier: MIT-0
#
# This config file is installed as part of systemd.
# It may be freely copied and edited (following the MIT No Attribution license).
#
# To make local modifications, one of the following methods may be used:
# 1. add a drop-in file that extends this file by creating the
#    /etc/systemd/network/99-default.link.d/ directory and creating a
#    new .conf file there.
# 2. copy this file into /etc/systemd/network or one of the other paths checked
#    by systemd-udevd and edit it there.
# This file should not be edited in place, because it'll be overwritten on upgrades.

[Match]
OriginalName=*

[Link]
NamePolicy=keep kernel database onboard slot path
AlternativeNamesPolicy=database onboard slot path
MACAddressPolicy=persistent

容器侧

#  SPDX-License-Identifier: LGPL-2.1-or-later
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This network file matches the container-side of the virtual Ethernet link
# created by systemd-nspawn's --network-veth switch. See systemd-nspawn(1) for
# details.

[Match]
Virtualization=container
Name=host0

[Network]
DHCP=yes
LinkLocalAddressing=yes
LLDP=yes
EmitLLDP=customer-bridge

[DHCP]
UseTimezone=yes

我最好的猜测是:

  • 这不是防火墙问题,因为一些数据包仍能完成整个往返。
  • 这可能是由于 MAC 地址不匹配导致某些数据包错误路由的情况。
  • 我很早就犯了错误,现在都认不出来。FWIW,这是我对 IPv6 的第一次了解。我最近将此设置从另一台虚拟服务器移到了这台虚拟服务器,之前它在这里运行正常。或者至少我没有注意到它不工作了。
  • 纯粹的邪恶让我发疯!

有什么提示吗?

相关内容