通过Lancom路由器VPN连接仅导致MS Office运行缓慢问题排查

这问题我之前帮朋友排查过类似的，大概率是Lancom路由器的VPN/网络优化设置和Office的特定网络行为不兼容导致的——毕竟只有Office异常，其他RDP操作正常，说明核心RDP连接没问题，只是Office的流量在Lancom VPN环境下被“卡”住了。具体可以从这几个方向逐一排查：

1. VPN压缩与MTU分片设置不合理 #

Office（尤其是Server 2012 R2上搭配的Office 2013/2016）在RDP会话里会频繁传输大量小数据包（比如文档实时同步、格式渲染的细碎请求）。Lancom如果默认开启了IPsec VPN压缩，反而会因为压缩小数据包额外消耗路由器CPU，导致延迟飙升；另外如果VPN接口的MTU值设得过高（比如默认1500），小数据包也会被强制分片，重组过程中增加丢包和延迟。而Fritz!Box的默认设置通常会自动适配这类小流量场景。

• 排查操作：
  • 登录Lancom管理后台，找到VPN配置模块（远程访问VPN或站点到站点VPN），关闭「VPN压缩」选项；
  • 把VPN接口的MTU值调整为1300（比公网MTU小，避免分片），保存后重启VPN连接，测试Office运行速度。

2. QoS流量优先级未适配办公场景 #

如果Lancom路由器给VPN流量设置了较低优先级，或者没有给Office相关流量分配足够带宽，就会导致Office的请求被其他流量挤兑，出现卡顿。Fritz!Box默认会自动识别RDP和办公类流量，并赋予高优先级。

• 排查操作：
  • 进入Lancom的QoS设置页面，找到VPN流量的优先级规则，把RDP端口3389、SMB端口445（Office访问共享文件常用）设为最高优先级；
  • 检查是否有带宽限制规则限制了VPN的上行/下行速率，如有则暂时取消或调高配额。

3. 加密套件不兼容导致握手延迟 #

Office在RDP会话中会和Server进行加密通信（比如许可证验证、云组件同步），如果Lancom VPN使用的加密套件和Windows Server 2012 R2/Office的支持范围不匹配，会导致反复握手、重传，拖慢速度。Fritz!Box的默认加密套件组合更适配旧版Windows/Office的环境。

• 排查操作：
  • 在Lancom的VPN加密设置里，将加密套件切换为兼容模式：优先选择AES-256-CBC加密算法、SHA256哈希算法，避免使用过于冷门或最新的加密套件。

4. RDP本地资源映射与VPN转发冲突 #

如果你的RDP客户端开启了本地驱动器映射或打印机映射，Office会频繁访问这些映射资源（比如打开本地文件存到Server、调用本地打印机预览），而Lancom的VPN转发机制对这类跨隧道的映射流量处理效率较低。Fritz!Box的VPN转发逻辑则更高效处理这类场景。

• 排查操作：
  • 打开RDP客户端，切换到「本地资源」选项卡，暂时关闭本地驱动器、打印机的映射；
  • 重新连接RDP测试，如果Office速度恢复正常，就说明是映射流量的问题，可以回到Lancom后台，给SMB端口445的流量单独设置优先级或转发规则。

5. VPN隧道类型适配问题 #

不同的VPN隧道类型（IPsec、L2TP/IPsec、PPTP）对流量的处理逻辑差异很大，Lancom默认的隧道类型可能不适合RDP+Office的混合流量模式，而Fritz!Box的默认选择更适配。

• 排查操作：
  • 尝试将Lancom的VPN隧道类型切换为L2TP/IPsec（如果之前用的是纯IPsec），或者反过来，测试哪种隧道类型下Office运行流畅。

内容的提问来源于stack exchange，提问作者siffed