踩坑序章

由于之前使用的N5105搭建软路由后还要运行其他各种杂七杂八的服务，性能逐渐不足，于是最近入手了一台畅网微控的5800u。想着最近也没有好玩的可以折腾的东西，这台软路由如果按常规用PVE也就没啥意思了，于是我便想着走出舒适区，用一下Hyper-v试试。

不得不说，对于简单的虚拟机，Hyper-v的各类设置项可以说是非常容易上手的。我上手之前还在搜Hyper-v如何直通网卡，上手后发现根本不需要直通，Hyper-v虚拟交换机可以直接连接外部网络，跟直通差不多。给OpenWrt的wan口只需要设置成不让宿主机访问，lan口允许宿主机访问，就可以正常拨号并且让宿主机上网了，这个lan口再直接连接到ap上，就可以实现大部分设备正常上网了。至此，我仅给OpenWrt配置了2个网口，就实现了看似一切正常的上网，殊不知一个巨大的坑被我完美的忽视了….

这套设备正常使用一段时间后，我在小黄鱼上又发现了有人出一套一模一样的设备，但价格巨实惠，64G+3T的5800u只要2k2。我自己上学有用软路由的需求，家里也有需求，想着正巧趁此机会给家里也整一套，于是就无脑又入了一台。到手以后我就打算先装个Win测试一下，顺便往里面扔点文件，考虑到想扔进去的文件比较多，ap只有1G口，这两台机器都是2.5G口，我就在第一台机器上给OpenWrt又配置了个lan，加到br-lan里，打算直接两机器互拷文件，这便是我迈入坑中的第一脚。

踩坑一——DHCP无效

自信的我给OpenWrt配置完第二个lan，插上网线就是直接开始连SMB……啊嘞？怎么连不上捏？看一眼网络配置……嗯…？169开头的ip…？什么玩意？我不至于脑瘫的插错口吧…看一眼，没错啊，怪了…禁用一下网口，再启用试试…嗯？怎么还是169，我开DHCP了啊？为了测试，我就把第二台机器插到了ap上，欸，它又能正常获取ip了。这就怪了，虚拟交换机配置错了？可这俩lan我配置的一模一样啊…到底是哪不对捏？

于是我开始排除不一致的变量…折腾了大约几个小时，虚拟交换机删了建，建了删，配置都一样了，怎么第二个口死活没有DHCP，还能有啥不一样的啊…不过最终，我找到了br-lan的配置里，发现网桥MAC和第一个lan一样，而和我后加的不一样。这时的我已经半破防了，虽然想着这完全是正常现象，我还是破罐子破摔尝试着改了一下br-lan的MAC，改成和第二个lan一样的。结果…欸！尼玛，第二个lan的DHCP有了，第一个lan的DHCP无了！我人傻了。

我想着这MAC还能影响DHCP的？PVE都没事的啊？Hyper-v这虚拟交换机什么玩意，怎么还对MAC地址有限制咋的？白丝不得其解的我去问了问GPT，了解到了一些关于网桥转发机理和Hyper-v的MAC地址安全机制。

首先，Linux 网桥（Bridge）是 L2 层设备，根据 MAC 地址学习并转发帧。当它收到某个以太网帧，会记录源 MAC 来自哪个接口，将来如果有目标是这个 MAC 的帧，就只从那个接口发出去，而不是广播。

其次，Hyper-v默认不启用MAC spoofing，不允许MAC欺骗，当某一接口企图使用和自己MAC不一样的其他MAC地址发送数据包时，Hyper-v的虚拟交换机会将该数据包丢弃。

那么由此，我们先来解释一下DHCP在两个口上工作情况的区别。首先我们要理解一点，源MAC是单向概念，不管是请求还是响应，都有属于自己的源MAC和目的MAC，设备请求DHCP的源MAC是设备MAC，OpenWrt对DHCP响应的源MAC是其br-lan的MAC，并不是请求响应一来一回源MAC始终不变。那么对于第一个lan接口（lan1），它的虚拟网卡MAC与br-lan相同，并且与宿主机桥接，此时无论是宿主机还是通过该接口连接的其他设备发出DHCP Discover广播，OpenWrt在响应时都会发回lan1接口，因为它学习了数据包进入时的接口，而其从br-lan向设备发回DHCP Offer响应的源MAC是br-lan的MAC，与lan1接口一致。对于OpenWrt发回的数据包，它需要通过lan1接口发送到请求DHCP的设备，在不启用MAC spoofing的情况下，Hyper-v检查该数据包的源MAC是否和lan1接口的MAC相同，此时是相同的，则该接口上DHCP正常。

对于第二个lan接口（lan2）上的设备发送DHCP请求时，DHCP响应数据包在发回时的源MAC仍是br-lan的MAC，这个MAC与lan2的MAC不一致了。此时，响应数据包企图通过lan2发回给请求DHCP的设备，Hyper-v发现该数据包源MAC与lan2的MAC不一致，于是便把它丢弃了，这就出现了lan2口上DHCP无效的现象。

于是乎，我打开了lan2上的启用MAC地址欺骗（位于虚拟机设置->网络适配器->高级功能，解决了DHCP问题。

踩坑二——两接口设备无法互通

如果是大佬，大概看小标题就知道发生什么了……是的，我把一个坑踩了2次啊啊啊啊啊啊啊！！！！！

解决了DHCP问题之后，我发现俩机器直接SMB仍然连不上，甚至ping不上。这个时候我还没有像上面那样去详细了解MAC欺骗，解决了DHCP就把问题搁置了。这时候我就在想莫非是除了MAC欺骗，虚拟交换机之间本身存在隔离？我是不是要先在Windows建立一个桥，然后把桥直通给OpenWrt？我之后试了很多方法，全部失败…见下…

  • New-NetSwitchTeam。根本建立不了SwitchTeam，原因不明。
  • New-IntelNetTeam。网卡是i226-v，成功建立AdaptiveLoadBalancing类型的IntelNetTeam，可是两接口依然不互通，并且DHCP失效问题复现。可能是需要建立VirtualMachineLoadBalancing类型的？但是尝试创建的时候提示需要Hyper-v角色，我明明已经有好几个Hyper-v虚拟机在运行了，不知道怎么回事。不过有人如果需要用IntelNetTeam的话，前排提示，一定要按官方文档把当前驱动全删了，冷重启后，再重装驱动，不然很大概率不成功。我就是想着一个驱动为什么还要删了重装，创建网卡组试了好几次都没成功，按要求重装一次驱动就好了。
  • New-NetLbfoTeam。这玩意…只给sever用，win10的所有sku都不能用，但是server系统打不上amd的驱动…只能说无语…
  • 直接在更改适配器选项里创建桥接。这玩意不行，创建好桥接以后，创建虚拟交换机的时候，在选择外部网络的下拉菜单里，根本不给对应选项，只显示物理网卡。IntelNetTeam就能显示创建的网卡组。
  • DDA设备直通。直通网卡后直接不开机，提示虚拟机监控程序功能对于该用户来说不可用，原因不明，BIOS正常启用SR-IOV功能，但虚拟机就是不开机。直通ps1脚本如下，需要admin。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    $locationpath = 'PCIROOT(0)#PCI(0201)#PCI(0000)'
    $VmName = 'wrt'
    # 变量赋值$locationpath需要直通硬件的位置路径，$VmName直通的指定虚拟机名称
    Dismount-VMHostAssignableDevice -LocationPath $locationpath -Force
    # 卸载硬件
    Set-VM -Name $VmName -AutomaticStopAction TurnOff
    # 直通设备的虚拟机不能被暂停或热迁移，所以自动关机动作必须为 ACPI shutdown 或者硬关机
    Add-VMAssignableDevice -VMName $VmName -LocationPath $locationpath
    # 将设备添加给指定虚拟机
    Get-VMAssignableDevice -VMName $VmName
    # 查看虚拟机直通设备情况
    pause

最后也不知道是脑袋抽了一下还是怎么的，突然想起来我的MAC欺骗只开了lan2的，然后我去把lan1的也打开了，一切正常了…上面的试错花了我加起来差不多七八个小时…难蚌…至于原理，跟上面基本一样的，上面看懂了举一反三一下也就懂了。

结语

微软你$@%#的安全机制真的是*&$%@&!#^$&#$^@$$^#*$##