接入客户边缘节点

四种路径都可行，而具体适用哪一种，取决于节点的状态、你从何处连接以及你需要访问什么——而不是取决于个人偏好。

路径	需要节点处于 `ONLINE`	需要网络可达性	限制	覆盖范围
调试 API	是	是	新站点约需 25–30 分钟预热	34 个命令
Site Console	否	通过 Azure Bastion，无需跳板机	Bastion 必须为支持隧道的 Standard SKU，且默认不部署	F5 的节点故障排查 UI
SSH	否	需从 VNet 内部连接，且仅限内部地址	密钥必须在首次启动时就已存在	完整的设备本机 Site CLI
串行控制台	否	否	每台 VM 一个会话；粘贴上限 2,048 个字符	完整的设备本机 Site CLI

串行控制台是最后手段，也是唯一在节点完全没有可用网络路径时仍然有效的路径。

Site Console 通常是首先应当尝试的方式。它对你的要求最少——无需分发 SSH 密钥、无需跳板机、节点无需公网 IP，也无需替换 VM——因为访问权限变成了 Azure RBAC 的决策问题，而不是凭据分发问题。它提供的是 F5 自带的故障排查 UI 而非命令行界面，因此当你需要运行特定命令或编写脚本时，就要越过它。它唯一的前置条件是 Azure Bastion，本部署将其设为可选启用（enable_bastion，默认 false），因为 Standard SKU 主机无论是否有人开启隧道都会计费。

当调试 API 不够用时，就该选择 SSH，因为设备提供的命令远多于该 API 暴露的 34 个。它有两项代价。密钥由 cloud-init 写入，因此必须在首次启动时就已存在，这意味着在运行中的节点上启用它需要替换每一台 CE VM——这是一次机群重建，而非配置变更。而且 sshd 仅在节点的内部地址上响应，因此需要一台位于 VNet 内部的主机；探测你所熟知的那个节点地址永远会报告端口关闭。

为什么这种划分不是偏好问题

调试 API 由 F5 Distributed Cloud 控制平面提供，它通过 vpm 在注册期间建立的隧道中继到节点。没有注册就没有隧道，也就意味着该 API 无处可中继。

它的失败方式并不明显，反而令人困惑，因此一个从未启动成功的节点看起来像是 API 出了问题。

串行控制台走的是完全相反的路径——经由 Azure 平台连接到节点的模拟串行端口。它不关心节点是否已注册、是否具备网络可达性，或数据平面是否正常工作。这种独立性正是其全部意义所在，也正是必须在 CE VM 上保持启用启动诊断的原因。

凭据

每条路径使用不同的凭据，且没有一种应当出现在命令行上。

调试 API — 一个 F5 Distributed Cloud API 令牌，以 XCSH_API_TOKEN 提供，租户 URL 以 XCSH_API_URL 提供。位于 ~/.config/xcsh/contexts/<tenant>.json 的 xcsh 上下文文件同时保存两者，当环境变量未提供时，scripts/capture-sitecli.sh 会读取该文件。本部署的租户是 f5-sales-demo；为其他租户签发的令牌会返回一个裸的 401，看起来像是凭据已过期。
Site Console — 两套凭据，位于不同层级。你的交互式 Azure 登录用于打开 Bastion 隧道，而设备自身的 admin 账户通过 HTTP Basic 登录其背后的控制台。Microsoft 声明 Azure 一侧需要对该 VM、其 NIC 以及 Bastion 主机具备 Reader 权限；此要求在此未经验证，因为所有测试均以订阅所有者身份运行。
SSH — 部署在首次启动时将公钥写入 /var/home/admin/.ssh/authorized_keys 的那对密钥的私钥部分，外加一台位于 VNet 内部、可用于连接内部地址的主机。以 admin 身份连接，而非 azureuser。
串行控制台 — 你的交互式 Azure 登录。此处没有服务主体：F5 企业 Entra 租户不允许创建服务主体，这也是本流程任何部分都无法在 CI 中运行的原因。