Accéder à un Customer Edge

Quatre voies fonctionnent, et celle qui s’applique est déterminée par l’état du nœud, par l’endroit d’où vous vous connectez et par ce que vous devez atteindre — plutôt que par préférence.

Voie	Nécessite un nœud `ONLINE`	Nécessite une accessibilité réseau	Limites	Couvre
API de débogage	oui	oui	environ 25 à 30 minutes de montée en charge sur un nouveau site	34 commandes
Site Console	non	via Azure Bastion, aucun hôte de rebond nécessaire	Bastion doit être en SKU Standard avec tunneling, et n’est pas déployé par défaut	L’interface de dépannage de nœud de F5
SSH	non	depuis l’intérieur du VNet, vers l’adresse interne uniquement	la clé doit être présente dès le premier démarrage	La Site CLI embarquée complète
Console série	non	non	une session par VM ; limite de collage de 2 048 caractères	La Site CLI embarquée complète

La console série est le dernier recours, et la seule voie qui subsiste sur un nœud dépourvu de chemin réseau fonctionnel.

La Site Console est généralement la première à essayer. C’est celle qui exige le moins de vous — aucune clé SSH à distribuer, aucun hôte de rebond, aucune IP publique sur le nœud, et aucun remplacement de VM — car l’accès devient une décision Azure RBAC plutôt qu’un problème de distribution d’identifiants. Elle vous donne l’interface de dépannage propre à F5 plutôt que la surface de commandes : allez donc au-delà lorsque vous devez exécuter des commandes précises ou scripter quoi que ce soit. Son unique prérequis est Azure Bastion, que ce déploiement rend optionnel (enable_bastion, valeur par défaut false) car un hôte en SKU Standard est facturé qu’un tunnel soit ouvert ou non.

SSH est la voie à privilégier lorsque l’API de débogage ne suffit pas, car l’appliance propose sensiblement plus de commandes que les 34 exposées par cette API. Elle a deux coûts. La clé est écrite par cloud-init et doit donc être présente au premier démarrage, ce qui signifie que l’activer sur des nœuds en cours d’exécution remplace chaque VM CE — une reconstruction de flotte plutôt qu’un changement de configuration. Et sshd ne répond que sur l’adresse interne du nœud : il faut donc un hôte à l’intérieur du VNet ; sonder l’adresse par laquelle vous connaissez le nœud signalera toujours un port fermé.

Pourquoi cette répartition n’est pas une question de préférence

L’API de débogage est servie par le plan de contrôle F5 Distributed Cloud, qui relaie vers le nœud par le tunnel que vpm établit lors de l’enregistrement. Pas d’enregistrement signifie pas de tunnel, ce qui signifie que l’API n’a rien vers quoi relayer.

Elle échoue d’une manière peu utile plutôt qu’évidente : un nœud qui n’a jamais démarré ressemble donc à un problème d’API.

La console série emprunte au contraire une tout autre voie — à travers la plateforme Azure jusqu’au port série émulé du nœud. Elle ne se soucie pas de savoir si le nœud s’est enregistré, s’il dispose d’une accessibilité réseau ou d’un plan de données fonctionnel. Cette indépendance est tout l’intérêt, et c’est pourquoi les diagnostics de démarrage doivent rester activés sur les VM CE.

Identifiants

Chaque voie utilise des identifiants différents, et aucun d’eux n’a sa place sur une ligne de commande.

API de débogage — un jeton d’API F5 Distributed Cloud, dans XCSH_API_TOKEN, avec l’URL du tenant dans XCSH_API_URL. Le fichier de contexte xcsh situé dans ~/.config/xcsh/contexts/<tenant>.json contient les deux, et c’est ce que lit scripts/capture-sitecli.sh lorsque l’environnement ne les fournit pas. Le tenant de ce déploiement est f5-sales-demo ; un jeton émis pour un autre tenant renvoie un simple 401 qui se lit comme un identifiant expiré.
Site Console — deux identifiants, à des niveaux différents. Votre connexion Azure interactive ouvre le tunnel Bastion, et le compte admin propre à l’appliance vous authentifie sur la console située derrière, en HTTP Basic. Côté Azure, Microsoft indique qu’il faut le rôle Reader sur la VM, sa carte réseau et l’hôte Bastion ; cette exigence n’est pas vérifiée ici, car tous les tests ont été exécutés en tant que propriétaire de l’abonnement.
SSH — la moitié privée de la paire de clés dont le déploiement a écrit la moitié publique dans /var/home/admin/.ssh/authorized_keys au premier démarrage, plus un hôte à l’intérieur du VNet pour joindre l’adresse interne. Connectez-vous en tant que admin, pas azureuser.
Console série — votre connexion Azure interactive. Il n’existe pas de principal de service pour cela : le tenant Entra d’entreprise F5 n’autorise pas d’en provisionner un, ce qui explique aussi qu’aucune partie de ceci ne s’exécute en CI.