Docker上的桥接网络和VMWare/VirtualBox上的桥接网络似乎非常不同。为什么？

Question

TL;DR - Docker为什么将其默认网络称为桥接网络，当它与NAT网络非常相似时？

让我们先看看-
1）VMWare或VirtualBox如何处理虚拟机的网络。 假设主机IP是随机的152.50.60.21，网络CIDR是152.50.60.0/24。
桥接网络 - 通过此接口连接的任何VM都可以在主机所连接的网络上拥有任何空闲IP。 因此，如果IP 152.50.60.30是空闲的，则VM可以绑定到此IP。 同样，第二个VM可以具有IP 152.50.60.32，如果此IP是空闲的。 桥接网络将VM连接到主机所连接的同一网络。 互联网上的任何机器都可以访问VM，并且VM可以直接访问互联网（当然，如果主机网络连接到互联网）。
NAT网络 - NAT是与主机所连接的网络分离的网络。 VMWare可以接受任何有效的CIDR（为了不使事情复杂，我只会引用专用保留块。 虽然，如果我没错，任何CIDR都可以）。 安全地创建在主机上并仅在主机上可访问的新NAT网络可以具有CIDR 10.0.0.0/8或172.16.0.0/12或192.168.0.0/16（或这些网络的任何子网）。 我选择10.0.0.0/8。 因此，在主机上旋转并通过NAT网络连接的两个VM可以具有IP 10.0.3.3和10.0.3.6。由于VM在NAT网络上，因此VM对于外部世界（除非通过主机上的DNAT/端口转发配置）不可见，即VM不可达到外部世界。但是，通过由主机提供的SNAT，VM可以访问外部世界/Internet/Intranet，即VM的IP地址永远不会暴露给外部世界。

VMWare文档参考：理解常见的网络配置

接下来，让我们看看Docker方面——
Docker默认网络
当使用Docker的默认网络（称为桥接网络）在主机上运行映像时（其IP从上面为152.50.60.21），新容器可以从网络-172.16.0.0/12（至少在我的环境中）中获得IP（例如）172.17.0.13。同样，第二个容器可以获得IP 172.17.0.23。为了访问互联网，这些容器依赖于主机提供的SNAT。除了主机提供的端口转发之外，任何互联网/内部网络上的计算机都无法访问容器。因此，容器对于外部世界来说不可见，除了主机。

基于以上情况，我认为Docker提供的默认网络是NAT网络，但Docker喜欢称其为桥接网络。

那么，有谁能说出问题在哪里或者我是如何看待桥接/NAT网络的呢？

- samshers

---

哎呀，这个问题写得真好。我很兴奋地向下滚动，想看到一些同样出色的答案。但现在感到有些失望 :( - wgrant

谢谢wgrant，如果有几个答案就太好了。问题不必永远是问题。希望有人能回答。 - samshers

3年过去了，还在等待。Docker的小伙伴们，你们在哪里？ - Aniket Kariya

非常好的问题。谁知道答案啊哈哈？ - Jibin

Answer 1

Docker的VMWare或VirtualBox桥接网络的等效物是macvlan。

来自文档：

...您可以使用macvlan网络驱动程序为每个容器的虚拟网络接口分配MAC地址，使其看起来像是直接连接到物理网络的物理网络接口。在这种情况下，您需要指定Docker主机上要用于macvlan的物理接口，以及macvlan的子网和网关。您甚至可以使用不同的物理网络接口隔离您的macvlan网络。

创建macvlan网络时，它可以是桥接模式或802.1q干线桥接模式。

在桥接模式下，macvlan流量通过主机上的物理设备。

在简单桥接示例中，您的流量通过eth0流动，并且Docker使用其MAC地址将流量路由到您的容器。对于您网络上的设备，您的容器似乎是物理连接到网络上的。

macvlan桥接模式示例：

$ docker network create -d macvlan \
  --subnet=172.16.86.0/24 \
  --gateway=172.16.86.1 \
  -o parent=eth0 \
  my-macvlan-net

这个命令会在eth0上创建一个名为my-macvlan-net的MacVLAN网络。

在802.1q trunk桥接模式下，流量通过Docker动态创建的802.1q子接口进行传输。这使您可以更精细地控制路由和过滤。

在802.1q trunked bridge示例中，您的流量通过eth0的子接口（在下面的示例中称为eth0.10）流动，并且Docker使用其MAC地址将流量路由到容器。对于您网络上的设备，您的容器看起来像是物理连接到该网络上。 macvlan 802.1q trunk bridge模式示例：

$ docker network create -d macvlan \
  --subnet=172.16.86.0/24 \
  --gateway=172.16.86.1 \
  -o parent=eth0.10 \
  my-8021q-macvlan-net

这将创建一个macvlan网络，其父级为eth0.10。

对于来自VMWare或VirtualBox的用户来说，这个命名可能会令人困惑，但确实存在。

您可以在这里查看另一个关于macvlan的教程（包括为容器分配IP地址）。

- Christophorus Reyhan

Answer 2

由于内容过长，因此我将其作为回答添加。

经过数小时的谷歌搜索和阅读文档，我认为区别在于没有任何标准定义这些虚拟接口，而物理接口是由IEEE和IETF定义的。在RedHat的Linux虚拟网络接口列表中列出了大多数docker和vmware/vbox中看到的网络接口类型，除了一些特殊的，例如只存在于docker中以连接不同主机上的容器的overlay网络。实际上，这些网络接口并非由Cisco、IETF或IEEE等定义，而是在操作系统/其他网络设备级别上实现的物理网络接口，并且它们是具有定义标准的。对于其他产品（如虚拟化平台（vmware/vbox）或容器化（docker）），它们需要实现自己的网络解决方案。此时，它们可以实现自己的接口，赋予其某些花哨的名称，或者它们可以称之为与操作系统级别相同的名称。因此，docker开发人员肯定不会愚蠢到不知道NAT和bridge之间的区别，他们可能知道他们称之为bridge的网络实际上是一个NAT网络，但出于某种原因决定称之为bridge。由于不存在桥接或NAT网络的集中定义，因此无法判断docker是否错误。他们希望称此网络为bridge，他们就称之为bridge。但是，对于从虚拟化/ Linux网络背景出发的人来说，这可能会令人困惑。关于docker中桥接等效物及其如何创建的更多信息，请参见Christophorus Reyhan的答案。至于为什么不同，我的回答基于一些假设，但这是我能想到的最接近原因。除非有一天某个docker开发人员看到了这篇文章并决定回复，否则无法确认该假设。另外，对于vmware/vbox，主机是主机物理机本身，因此在使用bridge模式时，它连接到主机的网络。但是对于容器而言，主机不是物理主机，而是docker主机/引擎。因此，在使用bridge模式时，容器连接到主机的网络，但这次主机是docker主机。因此，它仍然是一个bridge网络，但是层次结构这次不同了，即container -> docker host -> host os，而不是guest os -> host os。根据docker的文档，还有一件事：

在处理那些期望直接连接物理网络而不是经由 Docker 主机的网络栈路由的遗留应用时，macvlan 驱动有时是最佳选择。

"而不是通过 Docker 主机的网络栈"，并且

当您从 VM 设置迁移或需要您的容器看起来像网络上的物理主机，并且每个主机都具有唯一的 MAC 地址时，Macvlan 网络是最好的选择。

这表明在 Docker 的世界中，与 VM 相比，网络不同，尽管它们有时可能共享一些相似之处或相同的名称。

- Aniket Kariya