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

Question

对于我的客户，我必须在不同的机器上安装停靠容器，这些机器在各种物理链接上运行各种服务。

我不能对我的码头集装箱使用“主机”模式。

到目前为止，我已经很高兴地使用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内核范围链接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作为码头容器中IP通信的网络接口？

对不起，3G标签:我没有足够的声誉来创建一个LTE标签.

谢谢！

Answer 1

我终于找到了一个可行的解决方案。但是孩子，我受苦了..。学会了..。

现在，我已经有了一个包装器脚本，围绕着“docker -d”，以及一个启动4(我不需要更多的)默认码头网络的单匹配-全对接-复合的all。

看起来是这样的：

network:
  test_net0:
  test_net1:
  test_net2:
  test_net3:

当提到时，这将为每个test_netX创建：

• 一个veth对:一个在容器名称空间中，一个在默认主机名称空间中
• 一座桥:这座桥奴役了主人那边的葡萄树

对于主机上的标准eth接口，没有问题:只是奴役它到你选择的桥梁。我可以用同样的方式奴役几个USB以太网管理员，而不会有任何问题。这是在bash中完成的(现在我希望我们在python中已经开始了)，奴役是在iproute2命令使用netns "up“之后完成的。

对于LTE来说，事情变得复杂多了。首先，LTE接口不会让自己受到适当的奴役。第二，尽管我们没有找到关于它的文档，但是经过大量的实验，我们发现在两个主机上看到的LTE接口之间的一些东西正在做大量的丢弃工作：

• 任何没有在"LTE网络“中的源或目标IP的数据包。
• (对此不确定，但怀疑)任何具有与LTE接口不同的源或目的地MAC地址的数据包(通过驱动程序动态分配这些地址的方式，可以使事情变得更有趣)

基本上，我们的LTE设置只从LTE接口和LTE接口发送数据包。

所以我们有了一个很棒的主意:让我们通过LTE隧道我们的交通。我们从ipip隧道开始，但很快意识到我们已经邀请了一头大象参加野餐，因为我们需要LTE从一个容器到另一个容器的多播，如果您有一百年的时间，这可能是可行的。

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

一旦我们将太低的TTL固定在我们的多播数据包上，我们就可以通过LTE链路在我们的容器之间平稳地运行各种类型的流量。

现在看起来很简单也很符合逻辑..。

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