主页 / server / 问题 / 1052560
Accepted
FLBzh
Asked: 2021-02-06 13:09:50 +0800 CST

如何在 docker 容器内使用 LTE 接口？

  • 772

对于我的客户，我必须在不同的机器上设置 docker 容器，这些机器在各种物理链路上运行各种服务。

我不能对我的 docker 容器使用“主机”模式。

到目前为止，我已经愉快地使用 macvlan 驱动程序在我的容器中生成了新的网络接口。

例如：

networks:
  good_net:
    driver: macvlan
    driver_opts:
      parent: eno0
  slow_net:
    driver: macvlan
    driver_opts:
      parent: eno0
  high_latency_net:
    driver: macvlan
    driver_opts:
      parent: eno0

我在容器启动时有一个脚本：

  • 给一个唯一的mac地址
  • 培养
  • dhcp 或静态地址
  • 应用 tc 过滤器来调整每个网络的流量

工作正常：我可以在各个链接上运行 ping 和 iperf3 以测试它们是否按预期工作。

问题：现在真正的界面来了，它们破坏了我的设置。

其中一个链接现在是 LTE。

lte_net:
  driver: macvlan
  driver_opts:
    parent: lte0

在 PC1（主机，而不是容器）上：

4: lte0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
   link/ether 7e:c4:d2:6a:e3:07 brd ff:ff:ff:ff:ff:ff
   inet 10.0.250.1/30 brd 10.0.250.3 scope global noprefixroute lte0
      valid_lft forever preferred_lft forever

在 PC2（主机，而不是容器）上：

4: lte0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
   link/ether b6:30:cb:12:31:16 brd ff:ff:ff:ff:ff:ff
   inet 10.0.250.5/30 brd 10.0.250.7 scope global noprefixroute lte0
      valid_lft forever preferred_lft forever

主机可以通过 LTE 链路愉快地相互 ping 和 iperf3。

但是：在容器中，使用 macvlan 方法，它们不能：

  • 我为每个容器中的接口分配了同一子网中的 IP 地址：10.100.10.1/24 和 10.100.10.2/24
  • 我已经关闭了所有其他接口，所以只剩下一条路线：10.100.10.0/24 dev lte0 proto kernel scope link src 10.100.10.1
  • 从 pc1 上的容器，我尝试在 pc2 上的容器中 ping 通 LTE 接口的 IP
  • 在主机上使用 tcpdump，我可以看到 lte 接口上的 ARP 数据包： 02:2d:6d:ad:63:62 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.100.10.2 tell 10.100.10.1, length 28

但是我看不到它们到达 pc2，甚至在主机级别也看不到。

原因很可能是来自 LTE 调制解调器无法识别的 MAC 地址的数据包被丢弃。这类似于 WLAN 发生的情况。

所以我尝试使用 ipvlan l2 代替，正如有时建议的那样：

lte_net:
  driver: ipvlan
  driver_opts:
    ipvlan_mode: l2
    parent: lte0

容器中的 lte0 接口与其在主机上的父接口具有相同的 MAC 地址。但是没有变化：仍然没有跨越 LTE...

ipvlan l3 甚至没有出现，但我认为这不是我需要的。

所以我的问题是：我做错了什么？如何正确访问我的物理 LTE 作为 docker 容器中 IP 流量的网络接口？

对 3G 标记感到抱歉：我没有足够的声誉来创建 LTE 标记...

谢谢 ！

linux networking wifi 3g docker

1 个回答

  1. Best Answer

    我终于找到了一个可行的解决方案......但是男孩我受苦了......并且学会了......

    我现在有一个围绕“docker-compose up -d”的包装脚本和一个万能的 docker-compose.yml，它从 4 个（我不需要更多）默认 docker 网络开始。

    它看起来像这样：

    network:
  test_net0:
  test_net1:
  test_net2:
  test_net3:

    启动后，这将为每个 test_netX 创建：

    • 一个 veth 对：一个在容器命名空间中，一个在默认主机命名空间中
    • 一座桥：奴役了东道主的veth

    对于主机上的标准 eth 接口，没有问题：只需将其奴役到您选择的网桥即可。我可以毫无问题地以同样的方式奴役几个 USB 以太网适配器。这是在 bash 中完成的（现在我希望我们真的是在 python 中开始的）并且奴役是在使用 netns 的 iproute2 命令“up”之后完成的。

    对于 LTE，事情变得复杂得多。首先，LTE 接口不会让自己被正确地奴役。其次，虽然我们找不到关于它的文档，但经过大量实验后，我们发现在 2 台主机上看到的 LTE 接口之间的某些东西做了很多丢弃：

    • 任何具有不在“LTE 网络”中的源或目标 IP 的数据包
    • （不确定但怀疑）任何具有与我们的 LTE 接口不同的源或目标 MAC 地址的数据包（顺便说一下，这些似乎是由驱动程序动态分配的，让事情变得更有趣）

    基本上，我们的 LTE 设置只在 LTE 接口之间传输数据包。

    所以我们有了一个绝妙的主意：让我们通过 LTE 隧道传输我们的流量。我们从一个 ipip 隧道开始，但很快意识到我们邀请了一头大象参加我们的野餐，因为我们需要通过 LTE 从容器到容器的多播，如果你有一百年的空闲时间，这可能是可行的......

    然后，当我们在 LTE 链路上设置 GRETAP 而不是 ipip 隧道时，事情终于成功了。最大的优势是 GRETAP 接口可以被奴役，并且它的行为类似于标准以太网接口。

    一旦我们修复了多播数据包上的 TTL 太低，我们的容器之间的所有类型的流量都可以通过 LTE 链路顺利运行。

    现在它看起来很容易和合乎逻辑......

    Linux、iproute2、docker，你们都愿意嫁给我吗？

    • 1

相关问题