摘要

  • 配置被接受、配置正在使用、一次访问获得有效结果，是三个不同的结论。即使设备已经应用预期配置，也不能据此推断代理允许访问指定目标，更不能推断远端应用完成了请求。验收必须把配置状态与实际访问记录关联起来，而不是用前者替代后者。RFC 8342为预期配置与运行状态的区分提供了基础。
  • 代理认证、转发授权、服务器身份验证和应用操作结果各有独立对象。在通常的 SOCKS TCP 转发结构中，客户端收到 TCP 保活响应，只能为客户端至代理这一段连接提供有限的存活证据；它不能代替代理至目标的连接证据，也不能代替业务请求结果。这一边界来自 SOCKS5 的连接流程与 TCP 保活的协议语义。

把提交回执写进服务验收，错误已经发生

代理配置一提交成功，就把交付记录中的“远端应用可达”勾选完成：这种判断错误不一定出在配置内容，而在验收结论超出了证据范围。即使配置完全正确，后续连接仍要经过不受这份配置单独控制的代理策略、远端认证和应用处理。

以 NETCONF 为例，<ok/> 表示对应请求的处理没有产生错误或警告，而且该操作没有返回数据；提交候选配置，则涉及把候选配置用于当前配置。二者都不能自动变成另一个应用端点已经响应的证明。管理客户端与被管理设备之间的成功交互，也不是被管理设备经代理访问远端服务的成功交互。RFC 6241分别规定了这些管理操作的含义。

因此，“已接受”首先需要补全宾语：接受的是候选配置修改，还是提交操作？候选配置可以在不改变当前配置的情况下编辑。按照网络管理数据存储架构，<running> 中的配置经过必要转换后形成 <intended>，后者表达系统试图应用的配置；<operational> 则包含系统实际使用的配置和运行状态。不能仅凭这些名称，把“已经提交”理解为“所有相关效果都已经发生”。RFC 8342明确区分了这些层次。

对于实现能够准确呈现的节点，比较预期值与运行中值，可以帮助确认配置是否落地。然而，“正在使用某个代理地址”仍然不是“通过该代理完成了应用操作”。如果实现另外执行了连通性测试，测试可以提供额外证据，但验收记录必须交代测试对象、路径、时间、身份和结果，不能把这些信息隐藏在一个含义不明的成功状态里。

三套 grouping 划定的是配置范围

RFC 9643 定义三个 YANG 模块，各自提供主要的可复用 grouping。它们之间的关系不是三份相互担保的健康证明，而是公共参数、客户端参数与服务器参数的组合。

模块与主要 grouping 负责表达的内容 不能直接据此得出的结论
ietf-tcp-common：tcp-common-grouping 可选 TCP 保活及 idle-time、max-probes、probe-interval 参数 某个应用进程仍能处理请求
ietf-tcp-client：tcp-client-grouping 目标地址和端口、可选本地绑定、代理选择，并复用公共参数 代理已经允许转发，或目标服务已经响应
ietf-tcp-server：tcp-server-grouping local-bind 监听地址与端口列表，并复用公共参数 监听已成功建立，或某个 SOCKS 转发请求已获授权

这些范围由 RFC 9643分别定义。尤其需要注意，ietf-tcp-server 并不是 SOCKS 服务器访问控制规则模型，不能因为名称中有“服务器”就让它承担代理授权的证明责任。

grouping 是供模型复用的节点定义块，单独声明它不会在数据树中创建节点；需要通过 uses 等相应机制使用它。这是 RFC 7950规定的语言语义，不是一种启动服务或验证服务的操作。

RFC 9643 的三个模块本身不创建独立的协议可访问节点，也不定义连接结果的 RPC、动作或通知。它们可以被更完整的系统使用，但不自带一套应用可达性遥测。RFC 9643对模型范围和安全考虑的说明，限制了运营者能够仅凭这些模块作出的判断。

这不妨碍使用这些 grouping 的系统另外提供监测。它只是意味着，运营者不能把外部系统尚未提供的证据归功于基础模型，也不能因为基础模型没有记录某种故障，就认定这种故障不可能发生。

同名地址字段，指向两个不同的对象

客户端 grouping 外层的 remote-address 与 remote-port 指向目标 TCP 服务；代理分支内部同名的地址和端口，则指向代理服务器。例如，proxy-server/socks5-parameters/remote-address 不是应用目标地址。代理分支的端口默认值为 1080，也不能被当作外层目标服务端口的默认值。RFC 9643通过节点描述和各自的定义区分了二者。

如果监测系统只保留一个没有上下文的“远端地址”，就可能把连接代理成功误写为连接业务目标成功。由此得到的记录要求是：分别标识预期目标、实际接入的代理，以及能够观察到的代理出站目标。这是运营设计上的推论，不是该 RFC 已经提供的遥测字段。

代理选择同样不能简化为一个“已启用”的布尔值。proxy-server 是可选的存在性容器，SOCKS4、SOCKS4a、SOCKS5 分支分别受 YANG 能力声明约束。在该模型中，SOCKS4 分支的代理地址使用 IP 地址类型，SOCKS4a 和 SOCKS5 分支允许 IP 地址或主机名。模型列出这些选择，不代表每个实现都支持它们，更不代表实际代理与所选协议兼容。RFC 9643列明了这些配置条件。

主机名又引入了另一层需要记录的事实。SOCKS5 的线上请求可以携带 IPv4 地址、域名或 IPv6 地址，由 ATYP 标识。配置中出现主机名，并不是某次请求实际发送了域名、由哪一侧完成解析、最终连接哪个 IP 地址的记录。RFC 1928规定了请求中的地址形式；解析位置、地址选择和失败尝试，则应从实际实现与访问记录中确认，不能从静态配置倒推。

SOCKS 的几个“成功”，不能合并记账

以 SOCKS5 的 CONNECT 路径为例，客户端首先与代理建立 TCP 连接，然后协商认证方法，完成适用的认证子协商，再提交目标地址和端口。代理评估请求，决定拒绝还是建立相应连接。**客户端至代理的 TCP 建连发生在 SOCKS 协商之前；代理至目标的连接是另一个阶段。**这一顺序由 RFC 1928规定。

配置所选的认证方式、客户端实际提供的方法、代理实际选中的方法，是不同信息。RFC 9643 中可选的 authentication-parameters 可以选择 GSS-API 或用户名／密码；其中 GSS-API 容器为后续模型补充具体配置预留位置，并不是已经建立的安全上下文。RFC 9643没有把这些配置定义变成协商结果。

用户名／密码分支又借用了 ietf-crypto-types 中的 password-grouping。这套分组用于表示向远端系统认证所需的密码，并按实现能力支持明文或加密表示。RFC 9640描述的是凭据的数据形式。因此，一项密码配置被接受，不能证明运行时已经成功取用该凭据；配置中的加密表示，也不能证明随后发送的认证报文受到加密保护。这两项结论分别需要运行结果和通信保护机制支持。

在线上，方法选择与凭据校验仍要实际发生。SOCKS5 的 METHOD=0xFF 表示没有可接受的方法，客户端必须关闭连接。未配置认证参数，不能代替实际观察到无需认证方法的证据。RFC 1928定义了这一协商过程。用户名／密码子协商中的成功状态，则说明该子协商成功，而不是后续目标访问已经获准；RFC 1929限定了这个状态的含义。

转发授权需要另外判断。CONNECT 回复中的 REP=0x00 是代理报告请求成功的证据；它比“代理端口能连上”强得多，却仍不是应用响应。REP=0x02 表示规则不允许连接，REP=0x05 表示连接被拒绝，不能统一压缩成“网络异常”。回复中的 BND.ADDR、BND.PORT 是代理为出站连接使用的绑定信息，也不是目标服务器的身份证明。RFC 1928给出了这些区别。

客户端通常没有独立观察代理至目标的 TCP 握手，而是在接收代理的报告。运营记录应保留这种证据来源差异：代理报告成功、代理侧记录了出站连接、应用端点返回了可验证响应，不是同一种观察。它们可以相互补充，却不能在汇总时失去各自的来源。

认证的保护范围也必须分开。GSS-API 方法不仅涉及安全上下文建立，还包括消息保护等级的协商；实际提供的保护应按协商结果判断，而不是只看配置中出现了 GSS-API 的名称。RFC 1961描述了客户端与 SOCKS 服务器之间的这一机制。它所认证和保护的交互，并不能替代目标应用自身的身份验证。

用户名／密码子协商则直接携带明文密码。RFC 1929明确指出了这一风险。由此可以推导：没有额外受保护通道时，之后再与目标应用建立 TLS，无法追溯保护此前已经发送给代理的密码。“应用连接加密”与“代理凭据传输受到保护”，必须分别证明。

这里关注的是一次 TCP 出站访问如何逐步获得足够证据，而不是 UDP 关联如何随控制连接结束。即使不讨论任何 UDP 生命周期规则，配置接受与服务可达之间的证明缺口仍然存在。

转发建立后，仍然需要知道对方是谁

代理允许一个客户端连接某个地址，不等于该地址上的对端已经证明自己是预期服务。应用采用 SSH 或 TLS 时，还需要检查相应协议的服务器认证。RFC 9644区分 SSH 客户端身份与服务器认证配置；RFC 9645为 TLS 客户端提供相应的身份与认证配置。这些内容承担的是不同于 TCP 地址和代理选择的职责。

对于使用主机密钥认证的 SSH，会话中的密码学验证与“这把主机密钥是否属于预期服务器”的信任判断不能拆散。只记录收到某把密钥，或者为了完成连接而跳过可信绑定检查，都不足以证明远端身份。RFC 4253同时描述了主机密钥核验和密钥交换签名验证，并指出接受未经验证的主机密钥会失去对主动攻击的抵抗能力。

在证书认证的 TLS 1.3 中，CertificateVerify 用于证明对端持有对应私钥，Finished 则用于验证握手和计算出的密钥。这些消息具有具体的密码学作用，不能只凭收到一张证书或开始了一次握手，就认定认证已经完成。RFC 8446规定了这些验证步骤。

预期服务身份还要独立确定。客户端需要依据应用规则构造参考标识，再与服务器提供的标识匹配；不能把对端自己提供的名称直接当作预期名称，再宣布匹配成功。RFC 9525专门区分了参考标识与服务器呈现的标识。这意味着，访问记录中的代理地址、实际连接地址和用于验证目标服务的身份，不能因为都与同一次访问有关，就被合并为一个字段。

使用预共享密钥或原始公钥时，证据应对应实际采用的身份绑定和握手验证，而不是要求一份不存在的证书检查结果。这些认证形式也体现在 RFC 9645中。验收应跟随实际机制，但不能因机制不同就省略身份问题。

由此得到的运营结论是：记录预期身份、实际验证对象、验证结果及所用信任策略，而不只是“加密已开启”。如果受验证的会话终止在一个获授权的网关，验证结论就属于该终止点；网关后面的业务处理仍然需要另外证明。身份验证解决的是通信对象问题，不负责替应用担保处理结果。

应用有响应，也要区分拒绝、受理与完成

最后一层证据必须落到具体请求。TCP 提供字节流传输，而不是一份关于任意业务操作是否完成的统一报告；RFC 9293界定的传输服务，不能替应用定义成功条件。因此，验收不能停在“已发送数据”或“收到了若干字节”。

一个可以直接核对的例子，是远端应用本身提供 NETCONF 服务。此时，应检查来自那个已验证目标会话的 <rpc-reply>，而不是部署本地代理配置时的回执；通过 message-id 对应请求，再按操作区分返回数据、<ok/> 与 <rpc-error>。RFC 6241规定了这些协议结构。能够关联到请求的错误响应，可以证明相应协议处理给出了反馈，却不能被记为预定操作成功。

对于其他应用，验收同样需要事先定义“可达”的业务含义：是能完成认证后的只读查询，还是能对指定租户的指定资源执行写入？是收到响应，还是得到正确内容与可确认的最终状态？如果某项应用流程将“受理请求”与“完成处理”分为两个阶段，就应依据该应用的实际约定继续确认后者，而不是用受理记录替代完成记录。

只读探测可以用来降低测试副作用，但它不能在逻辑上证明写入权限和写入路径正常。反过来，一项写入未能完成，也不必然意味着所有只读功能都不可用。验收应说明测到了什么，而不是把不同操作折叠成一个含义过宽的“服务正常”。

这也意味着成功具有范围。一项请求成功，只能支持它所覆盖的身份、资源、操作、路径和时间窗口内的判断，不能被扩大为所有账户、所有地址或未来持续可用的保证。这种限定不是为了否定成功结果，而是为了让成功结果能够准确地进入后续决策。

保活响应停在哪一段，结论就应停在哪一段

在通常的 SOCKS CONNECT 转发结构中，客户端至代理与代理至目标是两段 TCP 连接。客户端内核发出的 TCP 保活探针由该段连接的 TCP 对端回应；它不是一条必须由 SOCKS 转发给目标应用处理的业务请求。因此，客户端收到保活响应，不能推出代理的出站连接健康。这是结合 SOCKS 连接机制与 TCP 保活定义得到的分段判断。

即使另有证据表明代理至目标这一段的 TCP 对端也在回应，也不能据此推出应用进程已经消费数据并完成处理。两段传输层状态都成立，与特定应用操作得到有效结果，仍然是不同的问题。

RFC 9643 允许配置保活参数，但参数值不是观测结果。其模型以 idle-time + max-probes × probe-interval 近似描述对无响应 TCP 对端的检测与关闭时间，不能把这个近似值改写为应用响应时限。该 RFC 还建议在对应用有意义的协议层执行存活检查。RFC 9643分别说明了参数语义和使用原则。

与此同时，TCP 不能因某一个保活探针没有得到回应，就直接认定连接死亡。RFC 9293保留了这一容错边界。运营上既不应把一次回应扩张为应用健康证明，也不应把一次未回应扩张为确定的服务故障。业务请求的等待期限、错误处理和重试决策仍需独立设计。

可验收的结论，应当能够追溯到一次访问

沿着这些协议边界，合理的验收对象不是一行“已启用代理”，而是一次能够关联配置版本的访问：所用代理是什么，实际协商了什么方法，转发获得了什么结果，对端身份如何验证，请求又得到了什么语义上的响应。这样的记录结构是运营设计建议，不是 RFC 9643 已经规定的统一遥测格式。

关联关系尤其重要。假如连接池仍在复用变更前建立的连接，新配置提交后出现的应用成功，就不能单独验收新代理。同理，上层响应虽然能说明某条通路起了作用，但缺少路径记录时，不能反向证明它一定经过了指定代理。

证明责任应据此分配：配置管理者说明哪一版设置在使用，代理运营者说明转发决定与出站连接，信任策略维护者说明身份验证依据，应用负责人定义成功语义。拿不到某一阶段记录，应标为该阶段未核实，而不是由另一阶段的成功代签。记录缺失不等于已经证明失败，但同样不等于可以宣布成功。

RFC 9643 的价值在于使连接意图能够一致表达。真正可以用于交付的结论则应更具体：在明确的配置、路径、身份和时间窗口下，预定操作获得了符合验收条件的结果。没有完成这一步，能够宣布的是配置阶段完成，而不是远端服务已经得到证明。