背景
我的软路由（运行OPNSense over PVE）是一台联想M920q小主机，支持vPro功能（Intel AMT），以单臂路由的形式接入主L3交换机，负责处理对管理平面的安全访问，以及提供Site-on-site VPN/DHCP/DNS等基础网络服务。
Intel AMT是一种不完整、非独立的带外管理服务。它试图像BMC那样提供电源控制、KVM远程控制、终端重定向等功能，但却没有独立的BMC管理芯片和IPMI管理网口，而是在消费级主板上复用了主机的板载网口，并配合CPU的功能模块和PCH共同拼凑出了上述功能。由于复用主机的网口和网卡，vPro没有自己的独立IP地址，只能与主机IP复用，或者用hacky的方式来设置静态IP；具体可配置为：1) 主机和vPro均配置为DHCP。vPro将自己配置为和主机相同的IP，并且对进入的数据包进行截取和检查；截取特定端口的数据包，而把剩下的数据包转发给主机；2) 主机和vPro均配置为静态IP。此时两者的IP允许不同，但由于vPro没有独立mac地址，因此本质上是对同一mac地址的IP Alias。
问题
这就造成一个问题：由于这种非常规的复用方式（而不是经由独立的网卡和交换芯片），从小主机本身发出的请求并不能直接访问到vPro。我并没有仔细验证，但是猜测是由于发给vPro的包在进入交换机广播时，并不会广播给进来的端口（避免flooding）；这一点从其他端口上抓到没有回应的ARP包可以侧面论证。外部交换机不给转发，主板内部也没有交换芯片，vPro运行在操作系统之下，也不能通过本地回环来转发，那自然就无法访问了。
考虑到vPro的设计用途是方便企业场景中IT support能方便地远程连接到用户电脑，并不考虑本地用户的经网络访问需求，这个问题倒是不大。但是在我的Homelab中，软路由承担了对管理平面的访问；没法经软路由远程访问其vPro就成为了一个问题。
解决方法
解决的关键在于，在L3交换机上，给特定为vPro IP的包配置一个单独的VLAN，然后对这个VLAN上的数据包进行路由；即用三层的路由规则绕过了二层的“不向进入端口转发”的限制。
最终数据路径为：OPN（M920q）->VLAN13->VLAN14->vPro（M920q）。
具体配置如下（为展示清晰，非正规地省略192.168.0.0/16的高16位）：
管理网段：
15.0/24M920q的主机IP（静态）：
14.14/24 [untagged]
M920q上PVE实际使用的IP：15.14/24 [vlan15]
M920q的vPro IP（静态）：14.15/24 [untagged]OPNSense的IP：
15.1/24[vlan15]，13.1[vlan13]交换机的VLAN：
L2交换：15.0/24[vlan15]
L3路由：13.0/24[vlan13],14.0/24[vlan14]
IP地址(for L3)：192.168.x.254/24
目标是将由OPNSense发出的目的地为14.15的包顺利投递给小主机。
首先在OPNSense上添加交换机VLAN13的网关（System:Gateways:Configuration）
[any L3-enabled interface]
192.168.13.254
然后将14.0/24网段的网关配置为交换机的VLAN13（System:Routes:Configuration）
192.168.14.0/24 192.168.13.254
在L3交换机上配置VLAN，将单臂路由端口上untagged的包配置为VLAN14（included, untagged）。这样我们便将专用于vPro的数据路径分离出来了。其次，为单臂路由端口新增一个VLAN13（included, tagged）用作中转；使用默认添加的路由：
192.168.13.0/24gw192.168.13.254interfaceVLAN13192.168.14.0/24gw192.168.14.254interfaceVLAN14
如此，我们便将去往vPro的包给顺利投递了。接下的几个问题是：1) 如何用管理平面的地址(15.0/24)去访问vPro；2) 如何投递回包；3) 如何保证作为转发中介的VLAN13的安全，使其不被误用或者恶意使用。
针对第一个问题，只需在OPNSense中新增一个IP Alias（Interfaces: Virtual IPs: Settings）并为其配置到vPro的port forward（Firewall: NAT: Port Forward）即可。在实践中，使用的IP地址是192.168.15.15。
对于第二个问题，由于OPNSense的防火墙管理着TCP状态，所以回包必须按原路程返回，而不能走捷径直接路由到OPNSense——这样做会导致防火墙在超时后reset TCP连接。
因此，回程数据通路为：vPro（M920q）->VLAN14->VLAN13->OPN（M920q）。
我们首先需要为一开始的数据包配置正确的回程IP：在OPNSense中为端口转发出来的包配置source NAT（Firewall: NAT: Outbound或者Firewall: Automation: Source NAT）为192.168.15.15。
接下来，在Intel AMT管理界面，设置默认网关为192.168.14.254，以便将回包路由到VLAN14中。
为了进一步把数据包经由VLAN13路由到OPNSense，我们在L3交换机上添加一条静态路由规则：
192.168.15.15/32gw192.168.13.1interfaceVLAN13
其中192.168.13.1正是OPNSense在VLAN13上的IP，就此回程包被顺利投递。
对于最后一个问题，由于15.0/24和14.0/24是受信网段，我们只需通过L3交换机的ACL功能，限制VLAN13和VLAN14只允许目标地址到192.168.15.0/24和192.168.14.0/24的包通过即可。
ACL Type Action Match Conditions
IPv4 Named Permit Match All: False
Protocol: 255 (IP)
Destination IP: 192.168.15.0
Destination Mask: 0.0.0.255
IPv4 Named Permit Match All: False
Protocol: 255 (IP)
Destination IP: 192.168.14.0
Destination Mask: 0.0.0.255
IPv4 Named Deny Match all packets在配置ACL的过程中，还意外遇到交换机的一个界面bug，使得我无法删除已添加的ACL规则；具体详见HPE OfficeConnect 1920S系列交换机bug两则