OpenVPN 之后 VMware 桥接虚拟机失去了网络

一小时前还能通过桥接访问的虚拟机，现在所有连接都超时，而且没有人改过它的设置。在主机上，互联网仍然能通过隧道工作。这两点合在一起说明问题不在 VPN，而在虚拟机监控程序：主机和虚拟机已经不再走同一条路径。只要多出一块新的虚拟网卡，就足以造成这种局面。

变的是桥接，不是虚拟机

在 Windows 上安装 OpenVPN 客户端会增加一块虚拟网卡，隧道建立时服务会绑定到它。对操作系统来说，它看起来就是一块带链路状态的普通接口，而且往往有自己的地址。对 VMware 而言，这已经足够让它成为桥接的候选对象。

VMnet0 默认设为「自动」，也就是说，每次建立桥接时虚拟机监控程序都会挑选一块主机网卡。刚安装的虚拟网卡会进入这个候选池，一旦被选中，虚拟机发出的每一帧都会走向隧道设备，而不是物理交换机的端口。

固定桥接，还是给虚拟机做路由

如果虚拟机应当是物理局域网里的对等成员，那么第一种分支才是正确的：不要再让桥接自动挑选，而是明确指定网卡。如果虚拟机应当使用企业隧道，就属于第二种分支，此时桥接从来不是正确的设计，因为桥接的虚拟机不会继承主机的 VPN 路由。

先决定这一点，因为两种答案对应的工作不同。顺序颠倒的话，你会得到一个正确固定的桥接，却挂在一台本就不该桥接的虚拟机上。

第一种分支的做法是：在主机上打开虚拟网络编辑器，选中 VMnet0，把「自动」换成物理网卡。如果有多块网卡，就用自动设置列表，并把绝不应该承载虚拟机流量的对象取消勾选：OpenVPN 的 TAP 或 Wintun 设备，以及 Hyper-V、WSL、Docker 和回环网卡。在笔记本上，有线网卡和无线网卡要同时保持勾选，否则用户下次接上扩展坞时，虚拟机就会失去桥接。

决定选择的三个条件

是否适合用桥接，取决于虚拟机的用途。如果虚拟机要在局域网中作为独立主机出现，拥有自己的地址和自己的入站可达性，那么桥接就是正确的模型，固定网卡就是全部修复。如果虚拟机只需要出站访问，那么仅主机网络或 NAT 更简单，也不受网卡更换影响。

如果虚拟机必须使用与主机相同的隧道，桥接模式和固定网卡都帮不上忙，因为虚拟机的流量根本不会进入主机的路由决策。这种情况需要在主机上提供一条被路由或被转换的路径，网卡的选择也就无关紧要了。

VMware Player 的界面里没有网络编辑器，所以只装了 Player 的主机要使用这些设置，就需要独立的编辑器或安装 Workstation。有时仅凭这一条限制就决定了做法。

在虚拟机内部读取结果

重启虚拟网卡，或者重启虚拟机，让它重新申请租约。然后读取它实际收到了什么，而不是主机以为配置了什么。

ipconfig /all
ip addr
ip route

在输出里只看两个字段，其余先忽略。网关应当是该局域网的路由器，网卡描述应当写的是 VMware Ethernet 设备，而不是隧道。169.254.0.0/16 里的自分配地址意味着没有 DHCP 服务器应答，而建立在隧道网卡上的桥接，从虚拟机一侧看正是这个样子。

在改动其他东西之前，还值得再区分一种情况。能到路由器却上不了网的虚拟机，桥接是好的，问题在上游。拿到隧道网段地址的虚拟机，仍然接在错误的设备上。禁用 TAP 网卡对这两种情况都不是修复，因为 OpenVPN 服务需要它。