VPN 笔记本要更快，需要开启 IP 转发吗？

把笔记本改造成路由器，是很多人用来解决错误问题的办法。转发存在的意义，是让一台机器传递目的地址并非自身的数据包，它对同一台机器上的浏览器加载页面有多快没有任何意见。两条路径看起来相似，只是因为它们都把流量送进同一个隧道。一旦把它们分开，你就会发现大量关于开启转发或开放防火墙的建议，描述的其实是你并不具备的拓扑。

从桌面看完全相同的两条数据包路径

笔记本上的浏览器会生成自己的请求。主机会选择隧道路由，客户端进程把数据包封装后发送给对端，应答再回到应用程序。这一串过程不会经过任何转发决策，因为这台机器既是会话的起点，也是终点。

现在把另一台设备放在刻意配置的以太网段上，并让笔记本成为它的默认网关。那台设备发起请求，笔记本收到目的地址在别处的数据包，内核必须决定是否把它继续转发。这才是转发角色，而它带来的前提条件是客户端角色从不需要的：被允许的穿通路径、两侧的路由，以及在设计包含地址转换时仍然可用的回程路径。

ip_forward 真正改变的是什么

内核关于 IPv4 sysctl 的文档把 ip_forward 描述为让主机在各接口之间转发数据包的开关。它不是主机自身产生流量的快车道，任何对该参数的解读都不会让本机浏览器更快。如果有影响，转发反而会给原本做得更少的机器增加状态和策略。

同一份文档还警告，修改该值会把其他 IPv4 参数重置为主机或路由器的默认值。这让这个开关更像一次配置事件，而不是一次探测：调好的参数可能在你脚下被还原，而这次改动可能造成没人会想到归因于它的性能回退。这也意味着该开关应当由承担网关角色的人一次性、有意识地设定。在排查变慢时去拨动它，是副作用必然与症状混淆的那一种情形。

三个并不相同的防火墙问题

允许 VPN 监听、允许笔记本运行的服务、允许流量穿过笔记本，是三种不同的许可。第一种让对端能够访问某个守护进程，第二种暴露了本机的东西，第三种把机器变成他人的中转。三者范围不同，最后一种远宽于普通出站应用所需的应答。

当某条具体流被阻断时，先说出它的源、目的、方向和策略归属，再去改规则。为该流写一条窄规则是修复；在隧道接口上全部放行，是恰好包含了修复的策略变更。之后浏览器能用，只能证明该流可用，并不能证明宽规则是必要的。

路径正确之后再测量

用相同的目标、相同的工作负载和可比的条件进行测量，并且一次只改一个变量。把转发改动、防火墙放宽和照抄的加密设置捆在一起测试，只会得到一个数字而没有任何解释，因为其中没有任何东西告诉你三者中是谁改变了结果。

把路由和解析器故障完全排除在性能讨论之外。解析慢的名字不是吞吐问题，而卡在某个固定大小的传输通常是 MTU 问题，而不是限速。在比较任何数字之前，先写清楚这三种情况里你实际观察到的是哪一种。否则下一位读者继承的，是一个测错对象的基准和一项没人能解释的改动。

描述你实际拥有的拓扑，而不是客户端上的标签

一台共享连接、承载路由型容器网络或为虚拟机转发流量的笔记本，无论软件怎么称呼自己，都是网关。客户端这个词描述的是隧道如何配置，而不是数据包是否被交给别人。

在运行手册里写清角色：什么发起流量、什么必须穿过这台机器，以及当前任务针对的是这两者中的哪一个。只有在属于受支持方案时才启用网关角色，不要把它当成未经解释的提速调整，套用到从不需要它的拓扑上。