让 VPN 用户只访问一个服务，而不是整个子网

某位承包商只需要一个内部 Web 应用，别的都不要，而最省事的答案是给他 一条通往服务器子网的隧道。这在他扫描它的那一天之前都行得通。更窄的设计需要更多思考，因为可达性、路由和应用权限是三个必须彼此一致的控制。

把需求写成服务，而不是子网

从目标主机、协议和端口开始，然后加上应当访问它的用户组或设备组。只有在应用需要解析名称时才包含私有 DNS 区域，只有在登录流程需要时才包含身份提供商。其余一切都是你尚未证明合理的依赖。

子网是网络团队的实现细节，而服务是业务所要求的东西，也是可以被审查和退役的单位。

如果依赖清单超过三项，这个应用大概需要自己的一场设计讨论。

窄路由，但在别处强制

窄路由或选择器告诉隧道该承载哪些数据包；它不是授权策略。网关过滤器、目标主机防火墙和应用自身的权限模型才是决定访问的地方。只覆盖一个地址的路由是个好开始，但它不是能挡住有决心用户的控制。正是这种分离让你可以更改过滤器而不重新设计隧道。

反过来，带严格过滤器的宽路由也可以是正当的，但前提是所有人都知道两者中哪一个在执行强制。

明确记录强制点，否则下一次变更会不小心把它挪走。

检查服务实际看到的源

目标看到的是客户端池地址或网关地址，取决于你是否做地址转换。主机防火墙规则和日志必须与真实源一致。如果多个用户共享一个转换后的源，该主机上任何按用户的规则都无法区分他们，这是设计约束，不是缺陷。

有意识地选择地址转换：它简化路由，却摧毁源身份，这对审计和按用户规则很重要。

写下你选了两种中的哪一种，就写在依赖它的规则旁边。

应用授权不是可选项

能到达端口并不授予角色。应用仍然需要自己的登录和权限，因为网络层无法表达用户可以编辑哪些记录。信任来自内部子网任何请求的服务，会把窄隧道变成对一个已泄露凭据的完全访问。隧道决定谁能打开套接字，应用决定能用它做什么。

窄设计在这里有两重回报，因为可达主机越少，应用层错误可被利用的地方就越少。

把网络规则和应用角色放在不同系统中，并分别退役。

同时证明被允许和被拒绝的路径

以被授权用户身份连接并做一次无害的代表性操作，然后尝试一个本应不可达的目标。只测试前半部分的设计不算测试过，而拒绝测试才证明设计。每次规则变更后测试新会话，如果请求到达而回复不到，就查看返回路径。

不要为了让验收测试通过而禁用转发过滤器，因为那会改变被测对象。

当用户不再需要该服务时，在各自的系统中退役远程身份和应用角色，并记录两者。strongSwan 转发指南 涵盖了路径的网关一侧。