不少家庭和中小办公场景部署旁路网关VPN的核心诉求，是在分流指定海外访问流量的同时，完全保留原有局域网的互访能力，既不用逐台终端配置VPN客户端，也不影响内网打印机共享、NAS文件读写、监控画面调取等常规业务。但很多用户部署完成后经常出现内网互访卡顿、共享资源失联的问题，这份旁路网关VPN部署后局域网访问有效性检查操作指南，就围绕旁路网关VPN：局域网访问检查的全流程逻辑，从配置前提、实操步骤到故障定位逐一拆解，帮用户在不打乱原有内网架构的前提下完成校验。
配置前置校验
正式启动检查前，首先要确认旁路网关的部署拓扑符合基础要求，旁路网关本身不能接管内网所有设备的默认网关，仅需把需要走VPN隧道的远端网段流量指向旁路网关处理，内网网段的静态路由必须提前下发到内网主路由中，很多新手部署时误把主路由的默认网关直接改成旁路网关的LAN口地址，会导致所有内网互访流量都被错误转发到VPN隧道，直接从根源上破坏局域网访问的基础逻辑。
技术人员正在核对旁路网关部署后的内网物理拓扑与路由配置前提
接下来要梳理完整的内网网段清单，把当前内网下所有VLAN、不同业务子网的IP段全部整理归档，同时区分出VPN隧道关联的远端站点网段，避免后续检查时把跨VPN的远端站点资源误判成本地局域网资源，干扰检查结果的准确性。
分层访问检查实操步骤
首先开展同二层局域网段的互访检查，选取两台同接主路由WiFi、或者接入同一接入交换机的普通终端，互相ping对方的内网IP，同时尝试访问对方开启的共享文件夹、本地部署的轻量测试网页，这个步骤的核心是验证旁路网关没有篡改同网段二层转发规则，不少开源旁路网关的默认配置会错误下发二层代理规则，导致同网段互访的ARP响应被劫持，哪怕后续三层转发正常，同设备之间的局域网互访也会出现异常。
完成同网段校验后再开展跨VLAN跨子网的局域网访问检查，比如办公场景下的办公子网要访问监控子网、NAS存储子网，首先要从旁路网关本身出发，ping通所有不同子网的网关地址，再用普通终端尝试访问其他子网的内网资源，确认内网跨三层转发的流量没有被旁路网关的VPN分流规则误匹配。
最后做内网核心服务的专项访问校验，依次测试内网打印机的打印任务提交、NAS的大体积文件读写、内网OA系统的页面加载、监控摄像头的实时画面调取，这类业务对网络路径的变化敏感度更高，快点哪怕基础ping测试显示连通，也可能因为VPN分流规则里的NAT设置错误导致业务数据包被篡改，出现连通但业务不可用的问题。
异常场景的故障定位逻辑
如果同网段互访失败，首先要排查旁路网关的LAN口配置，确认它的LAN口没有开启混杂模式下的流量劫持规则，很多开源旁路网关的默认配置里会把所有非指定白名单IP的流量都转发到WAN口，需要手动把所有内网网段的流量排除在转发规则之外，恢复二层流量的原生转发逻辑。
如果跨子网访问失败，要回头检查主路由上的静态路由条目，确认指向旁路网关的路由条目只对需要走VPN分流的远端网段生效，没有把整个内网大段的路由都指向旁路网关，很多用户配置的时候图省事直接添加了指向旁路网关的默认路由，梯子软件直接打乱了内网原本的三层转发逻辑。
如果基础网络连通但内网业务异常，要排查旁路网关的NAT设置，确认内网互访的流量不会被做源地址NAT转换，一旦内网互访的数据包源地址被改成旁路网关的LAN口地址，很多内网服务的IP白名单校验、权限校验机制就会直接失效，出现能连通但无法登录、无法读写资源的问题。
常见操作误区规避
很多用户做旁路网关VPN：局域网访问检查的时候，只测试自己手头的一两台常用终端，忽略了内网里的IoT设备、监控摄像头、打印服务器这类固定IP的无头设备，这类设备大多没有配置自定义网关的能力，一旦内网路由规则变化，很容易出现失联的情况，检查的时候要把所有固定IP的内网设备全部覆盖到，避免遗漏隐性故障。
不要为了省事直接在内网终端上手动配置旁路网关作为默认网关，这种操作会让这台终端的所有内网访问流量都绕经VPN隧道，哪怕最后访问能通也会增加不必要的转发路径，完全违背了旁路网关部署的分流初衷。
整套检查流程走完之后，建议保留一段时间的观察期，持续查看内网各个业务的访问日志，确认没有出现偶发的断连、权限失效的问题，才能最终确认旁路网关的部署完全兼顾了分流需求和局域网访问的有效性。
