連線至 Customer Edge

四種途徑都可行，而適用哪一種是由節點的狀態、您從何處連線，以及您需要觸及什麼所決定 — 而非由偏好決定。

途徑	需要節點為 `ONLINE`	需要網路可達性	限制	涵蓋範圍
Debug 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 的主機無論是否有人開啟隧道都會計費。

當 debug API 不足以應付時，SSH 就是該採用的途徑，因為設備提供的指令遠多於該 API 所公開的 34 個。它有兩項代價。金鑰是由 cloud-init 寫入的，因此必須在首次開機時即已存在，這意味著在運行中的節點上啟用它會替換掉每一台 CE VM — 這是整批機群重建，而非設定變更。此外， sshd 僅在節點的內部位址上回應，所以需要一台位於 VNet 內部的主機；對您所知的節點位址進行探測永遠會回報連接埠關閉。

為何這樣的區分並非偏好問題

debug API 由 F5 Distributed Cloud 控制平面提供，並透過 vpm 在註冊期間建立的隧道轉送至節點。沒有註冊就沒有隧道，也就意味著該 API 沒有任何對象可以轉送。

它的失敗方式不明顯而且沒有幫助，因此一個從未成功啟動的節點看起來會像是 API 出了問題。

序列主控台走的則是完全相反的路徑 — 透過 Azure 平台連到節點模擬的序列埠。它不在乎節點是否已註冊、是否具備網路可達性，或資料平面是否正常運作。這種獨立性正是重點所在，也是開機診斷必須在 CE VM 上保持啟用的原因。

憑證

每種途徑使用不同的憑證，而且沒有一項應該出現在命令列上。

Debug 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 登入其後方的主控台。Azure 端依 Microsoft 的說明需要對 VM、其 NIC 以及 Bastion 主機具備 Reader 權限；該項需求未在此處驗證，因為所有測試都是以訂閱擁有者身分執行。
SSH — 部署在首次開機時將公開金鑰寫入 /var/home/admin/.ssh/authorized_keys 的那組金鑰對的私鑰部分，再加上一台位於 VNet 內部、可用來連到內部位址的主機。請以 admin 身分連線，而非 azureuser。
序列主控台 — 您的互動式 Azure 登入。這裡沒有服務主體可用：F5 企業 Entra 租戶不允許佈建服務主體，這也是為什麼本文件的任何部分都不在 CI 中執行。