在没有互联网上行链路的 LAN 上管理 Raspberry Pi

专用 LAN 上的两台设备即使完全没有上行链路，也能交换受保护的流量。它们做不到的是凭空变出所选安全模型所预期的服务。因此工作一半是选择，一半是清点：挑出与任务相符的保护，然后列出一切会悄悄伸向互联网的东西。

本演练的前提是两台设备在同一专用网络上持有已批准的地址。不要因为两者都接入了同一个 Wi-Fi 就推断可达性；连接、路由和访问规则仍然决定这一点。

按任务而非按习惯选择保护

终端会话或受支持的文件管理任务适合 SSH，其架构把服务器认证、用户认证和受保护传输内部承载的通道分开。这些角色都不需要商业 VPN 提供商，也不会因为没有通往互联网的默认路由而停止工作。

服务器允许时，可以有一项额外的 TCP 服务穿过经授权的 SSH 转发：把本地监听器绑得很窄，把目的地写明确，并记住这转发的是那一项服务，而不是复制一个以太网段。

到多个地址或协议的路由访问是另一种需求，本地终止的 VPN 可以提供。那种情况下的对端是可到达的本地网关，而不是互联网某处的端点，网关仍然需要预定的路由、转发规则和服务权限。在单个应用已经能正确使用 TLS 的地方，让它保护自己的连接往往就是最小的可行答案。

清点会离开 LAN 的东西

在依赖隔离工作台之前，先准备好软件、主机身份和凭据，或者使用组织支持的离线交付流程。下载命令不是给无法访问来源的机器准备的安装计划，在故障期间才发现这一点是很糟糕的学习时机。

把命名做成有意为之。使用预定的本地 DNS 服务或记录在案的地址安排，因为配置好的公共解析器并不会造出一条通往它自己的路径。更改套接字地址也不是跳过应用身份检查的理由。如果答案是工作台干脆只用地址，那也写下来，免得下一位工程师在一个从未配置过的搜索域上耗掉一小时。

然后为外部依赖阅读认证与验证模型：注册、身份提供方、多因素批准、证书状态获取、时间源。每一项在隔离网络上都是潜在的阻碍。在维护窗口之前列出它们，而不是在窗口期间，因为在不恰当的时刻发现的依赖会把五分钟的任务变成一个下午。提供一项已批准且可达的安排，或者选择离线可用的模型，绝不要因为服务缺失就悄悄禁用检查。

把身份检查放在它该在的地方

通过你信任的配置流程验证预期的主机密钥或证书，并在协议校验证书时间的地方保持时钟正确。与某台设备共用一个交换机，并不会让那台设备成为你想抵达的那一台，反过来假设正是同一网段上的攻击者希望你犯的错误。

时间值得在计划里单列一行。许多协议在时钟漂移得足够远时会拒绝本来有效的凭据，而没有网络时间源的 Pi 可能悄悄漂移好几个月，直到有人抱怨。

在上行链路真正不存在时测试

拔掉上行链路，然后执行你为此设计的那项维护操作：终端会话、文件复制、被转发的服务、路由连接。确认被拒绝的身份或被禁止的资源仍然被拒绝，因为只证明顺利路径的设计根本没有被测试过。做的时候读日志，因为有意思的失败是那些留下痕迹却不改变结果的。

记录本地端点、保护机制以及该操作使用的每一项依赖。通往互联网的出口与本地管理的安全路径是两项不同的需求，把它们分开，才能让后者在失去前者时仍然成立。