Site-Konsole

Erfasst am 28.07.2026 von einer CE dieses Deployments. sitecli/capture-manifest.json hält fest, welcher Knoten es war, und scripts/capture-sitecli.sh --check überprüft die Befehlsoberfläche erneut gegen eine laufende CE.

Jede Customer Edge stellt die Site-Konsole von F5 unter https://<sli-ip>:65500 bereit. In diesem Deployment ist das üblicherweise der Weg, den man zuerst versuchen sollte.

Sie verlangt am wenigsten von Ihnen: kein zu verteilender SSH-Schlüssel, kein zu pflegender Jump-Host, keine öffentliche IP am Knoten und kein VM-Austausch, um sie zu aktivieren. Wer sich verbinden darf, wird zu einer Azure-RBAC-Entscheidung. Und sie setzt nicht voraus, dass die Site registriert ist: Diese Seite wurde erstmals erfasst, während alle drei Sites site_state: FAILED meldeten, und unverändert erneut gegen dieselben Knoten verifiziert, nachdem sie ONLINE waren.

Der Haken ist, dass die Site-Konsole nur auf der internen (SLI-)Adresse des Knotens antwortet, die nur von innerhalb des VNet erreichbar ist. Azure Bastion schließt diese Lücke, ohne sonst etwas ins Netzwerk zu stellen.

Was hier verifiziert ist und was nicht

Jeder Befehl und jede Ausgabe auf dieser Seite wurde gegen f5-xc-ce-vm-01 in diesem Deployment ausgeführt und ist wortgetreu wiedergegeben, einschließlich der Fehlschläge.

Die Authentifizierung ist verifiziert: Die admin-Zugangsdaten der Appliance liefern über den Tunnel 200. Was nicht durchgespielt wurde, ist die Konsole selbst — nichts im Folgenden beschreibt, was Sie sehen oder tun können, sobald Sie drin sind.

Azure RBAC ist nicht verifiziert. Jeder Durchlauf erfolgte als Subscription Owner, daher ist die Reader-Anforderung in Schritt 2 die dokumentierte Anforderung von Microsoft und nicht etwas hier Gemessenes.

Bastion ist Opt-in und wird standardmäßig nicht bereitgestellt

enable_bastion ist standardmäßig false, daher gibt es bei einem Standard-terraform apply keinen Bastion-Host und terraform output -raw bastion_name ist null. Setzen Sie enable_bastion = true in terraform/terraform.tfvars — in diesem Deployment ist es true.

Der Grund für das Opt-in sind die Kosten, nicht das Risiko: Ein Host mit Standard-SKU verursacht ab dem Moment der Bereitstellung eine stündliche Grundgebühr, unabhängig davon, ob jemand einen Tunnel öffnet — 0,29 USD/Stunde in eastus für die zwei enthaltenen Skalierungseinheiten (Listenpreis, 07/2026), also rund 212 USD pro Monat. Schalten Sie es wieder ab, wenn die Demo keinen Konsolenzugriff benötigt.

Bevor Sie beginnen

1. Melden Sie sich bei Azure an und fügen Sie die Bastion-Erweiterung hinzu. Tunneling ist eine Funktion des nativen Clients und die Erweiterung ist nicht standardmäßig installiert.

   az login
   az extension add --name bastion

2. Halten Sie Reader auf der CE-VM, ihrer Netzwerkschnittstelle und dem Bastion-Host. Dies ist die dokumentierte Anforderung von Microsoft und hier nicht verifiziert — jeder Durchlauf in diesem Deployment erfolgte als Subscription Owner, daher wurde für keine geringere Rolle gezeigt, dass sie ausreichend oder unzureichend ist.

3. Bestätigen Sie, dass Bastion bereitgestellt und leistungsfähig ist. Die Basic-SKU unterstützt weder Tunneling noch IP-basierte Verbindungen, daher sind Standard und True hier beide tragend.

   az network bastion list -g "$(terraform output -raw resource_group_name)" \
     --query "[].{name:name, sku:sku.name, tunneling:enableTunneling}" -o table

   Name               Sku       Tunneling
   -----------------  --------  -----------
   mcn-ce-ha-bastion  Standard  True

Den Tunnel öffnen

Übernehmen Sie die Werte aus terraform output, statt sie einzutippen — die Ressourcen-ID ist nichts, was man von Hand zusammensetzen sollte.

1. Lesen Sie den Namen des Bastion-Hosts, die Ressourcengruppe und die VM-Ressourcen-ID der Ziel-CE aus.

   cd terraform
   BASTION=$(terraform output -raw bastion_name)
   RG=$(terraform output -raw resource_group_name)
   VM_ID=$(terraform output -json ce_vm_ids | jq -r '.eastus01')

   mcn-ce-ha-bastion
   rg-mcn-ce-ha-<deployer>
   /subscriptions/…/providers/Microsoft.Compute/virtualMachines/f5-xc-ce-vm-01

   Die Map ist nach Site verschlüsselt, nicht nach VM-Name

   Die Schlüssel von ce_vm_ids sind eastus01, eastus02, eastus03 — nicht die VM-Namen. Ein Filter wie jq -r '."f5-xc-ce-vm-01"' liefert null, und der Tunnel scheitert dann an einer leeren Ressourcen-ID. Listen Sie sie auf, wenn Sie unsicher sind:

   terraform output -json ce_vm_ids | jq -r 'keys | join(", ")'

   eastus01, eastus02, eastus03

2. Starten Sie den Tunnel. Er hält den Port offen, bis er gestoppt wird — führen Sie ihn also im Hintergrund aus oder verwenden Sie ein zweites Terminal.

   az network bastion tunnel \
     --name "$BASTION" \
     --resource-group "$RG" \
     --target-resource-id "$VM_ID" \
     --resource-port 65500 \
     --port 65500 &

   WARNING: Opening tunnel on port: 65500
   WARNING: Tunnel is ready, connect on port 65500
   WARNING: Ctrl + C to close

   Allen drei Zeilen ist WARNING: vorangestellt. Das ist die Azure CLI, die den Fortschritt nach stderr schreibt, kein Problem. Warten Sie auf Tunnel is ready, bevor Sie sich verbinden.

3. Bestätigen Sie, dass der Listener lokal auf Loopback läuft:

   lsof -nP -iTCP:65500 -sTCP:LISTEN

   COMMAND   PID  USER  FD  TYPE  DEVICE  SIZE/OFF  NODE  NAME
   Python  41648  you   7u  IPv4  …            0t0   TCP  127.0.0.1:65500 (LISTEN)

4. Öffnen Sie die Konsole. Der Tunnel macht sie lokal, daher lautet die Adresse localhost — nicht die Adresse des Knotens.

   open https://localhost:65500/          # macOS
   xdg-open https://localhost:65500/      # Linux

5. Stoppen Sie den Tunnel, wenn Sie fertig sind — Ctrl-C, oder kill %1, falls Sie ihn in den Hintergrund gelegt haben. Ihn offen zu lassen belegt den lokalen Port 65500 und die Bastion-Sitzung.

Was Sie sehen werden

Einen Anmeldedialog, keine Login-Seite. Die Konsole verwendet HTTP-Basic-Authentifizierung, daher zeigt der Browser seine eigene Abfrage für Benutzername und Passwort. Es gibt kein Formular zu betrachten:

curl -skI https://localhost:65500/

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Volterra Site Console"
Content-Type: text/html; charset=utf-8
Content-Length: 0

Ein 401 mit diesem Realm bedeutet, dass die Konsole korrekt arbeitet. Genau das soll eine nicht authentifizierte Anfrage bekommen — und wenn Sie derselben URL die admin-Zugangsdaten übergeben, antwortet sie mit 200. So bestätigen Sie die Zugangsdaten, bevor Sie einen Browser öffnen:

curl -sk -u admin -o /dev/null -w '%{http_code}\n' https://localhost:65500/

Enter host password for user 'admin':
200

-u admin ohne Doppelpunkt bewirkt, dass curl nach dem Passwort fragt, statt es von der Kommandozeile zu nehmen, wo es in der Shell-History und in der Prozessliste landen würde.

Eine Zertifikatswarnung, und zwar aus drei Gründen gleichzeitig. Das Zertifikat direkt geprüft:

openssl s_client -connect localhost:65500 -servername localhost </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

subject=C=US, ST=California, L=Santa Clara, O=Volterra, OU=Volterra Edge Services, CN=site-local.volterra.io
issuer=C=US, ST=California, L=Santa Clara, O=Volterra, OU=Volterra Edge Services, CN=site-local.volterra.io
notBefore=Oct 25 04:51:31 2024 GMT
notAfter=Oct 25 04:51:31 2025 GMT

Subject und Issuer sind gleich, es ist also selbstsigniert. Der Name lautet site-local.volterra.io, während Sie sich mit localhost verbinden, er passt also nicht. Und in dem Build, den dieses Deployment ausführt, ist das Zertifikat am 25. Oktober 2025 abgelaufen — die Appliance liefert es mit, und nichts in diesem Repository erneuert es.

Rechnen Sie mit einer unmissverständlichen Browserwarnung, und zwar jedes Mal. Die Subject-Zeile oben ist der nützliche Teil: An ihr bestätigen Sie, dass Sie die Appliance erreicht haben und nicht etwas anderes, das auf dem lokalen Port 65500 lauscht.

Die Admin-Zugangsdaten

Melden Sie sich als admin an. Diese Dokumentation veröffentlicht das Passwort nicht, und sollte das auch nicht tun.

In diesem Deployment ist dieses Passwort noch immer F5s Werkseinstellung

Das ist eine gemessene Tatsache, keine Vermutung: Die werkseitigen Standard-Zugangsdaten authentifizieren sich heute auf allen drei CEs und liefern 200. F5 veröffentlicht diesen Standard und verlangt, dass er geändert wird — das ist nicht geschehen.

Die praktische Folge ist, dass in diesem Deployment “hält Reader auf dem Bastion” gleichbedeutend ist mit vollem Zugriff auf die Appliance-Konsole, und zwar für jeden, der einen Wert kennt, der in F5s öffentlicher Dokumentation steht. Ändern Sie ihn, und behandeln Sie diese Änderung als Teil der Knotenbereitstellung und nicht als spätere Härtung.

Zwei Gründe, warum es hier wichtiger ist, es nicht zu veröffentlichen, als es scheinen mag:

• Diese Dokumentation ist öffentlich. Das aktuelle Konsolenpasswort der Flotte abzudrucken würde “hält Reader auf dem Bastion” für jeden, der die Seite liest, in vollen Appliance-Zugriff verwandeln.
• Ein in der Dokumentation veröffentlichtes Passwort ist in dem Moment falsch, in dem jemand es rotiert — und zwar auf die irreführendste Weise: Die lesende Person schließt daraus, dass ihr Zugriff defekt ist, statt dass die Seite veraltet ist.

Sobald es rotiert wurde, holen Sie es dort, wo Ihr Team betriebliche Geheimnisse aufbewahrt.

Das Setzen des Passworts aus Terraform ist nicht verifiziert

admin_user_credentials.admin_password am Site-Objekt sieht nach dem deklarativen Weg aus, dies zu setzen. Es ist nicht bestätigt, dass es in diesem Build die Site-Konsole erreicht, gehen Sie also nicht davon aus.

Lesen Sie auch die SSH-Seite nicht als Beleg in die eine oder andere Richtung. Ihr Befund, dass admin_password “nichts geändert hat”, wurde gegen die SSH-Authentifizierung gemessen, die vpm für den Benutzer admin vollständig überspringt. Das sagt nichts über die Konsole aus.

Warum der Tunnel auf die Ressourcen-ID zielen muss

--target-resource-id ist erforderlich. Stattdessen die Adresse des Knotens anzusteuern wird abgelehnt — unabhängig davon, welche Adresse Sie verwenden, deshalb ist hier bewusst keine echte abgedruckt:

az network bastion tunnel --name "$BASTION" -g "$RG" \
  --target-ip-address <any-sli-address> --resource-port 65500 --port 65501

ERROR: Custom ports are not allowed. Allowed ports for Tunnel with IP connect is 22, 3389.

Der Grund ist nicht, dass IP-basierte Verbindungen deaktiviert wären — auf diesem Bastion ist ip_connect_enabled true. Microsoft unterstützt benutzerdefinierte Ports über IP-basierte Verbindungen mit nativem Client unabhängig von dieser Einstellung nicht (Azure-Dokumentation), und 65500 ist ein benutzerdefinierter Port. Die Bastion-Konfiguration hier zu untersuchen führt zu nichts; verwenden Sie die Ressourcen-ID.

Wenn es nicht funktioniert

Symptom	Ursache	Behebung
ERROR: Custom ports are not allowed. Allowed ports for Tunnel with IP connect is 22, 3389.	--target-ip-address verwendet	--target-resource-id verwenden
ERROR: Defined port is currently unavailable	Ein anderer Tunnel belegt diesen lokalen Port bereits	Den anderen Tunnel stoppen oder ein anderes --port übergeben; --resource-port bleibt 65500
terraform output -raw bastion_name ist null oder leer	Bastion ist nicht bereitgestellt	enable_bastion = true setzen und anwenden
Tunnel startet, aber die Ressourcen-ID ist leer	Der jq-Filter hat den VM-Namen statt des Site-Schlüssels verwendet	Auf eastus01/02/03 schlüsseln
401 Unauthorized, Realm Volterra Site Console	Kein Fehler — nicht authentifizierte Anfrage	Die admin-Zugangsdaten angeben
Browser lehnt das Zertifikat ab	Selbstsigniert, Namensabweichung und seit Okt. 2025 abgelaufen	Erwartet; prüfen, dass der Subject CN=site-local.volterra.io lautet, und fortfahren

Autorisierungsfehler wurden nicht reproduziert

Unzureichendes RBAC ist die andere naheliegende Fehlerursache, aber sie zu reproduzieren würde bedeuten, Rollenzuweisungen aus einem gemeinsam genutzten Deployment zu entfernen — daher ist sie hier nicht mit einer wortgetreuen Fehlermeldung dokumentiert. Wenn der Tunnel beim Start mit einem Autorisierungsfehler scheitert, prüfen Sie Reader auf allen dreien: der VM, ihrer NIC und dem Bastion-Host.

Die anderen Wege

Debug-APISkriptbar und wiederholbar, benötigt keinen VNet-Zugriff. 34 Befehle, und die Site muss ONLINE sein.

SSHDie vollständige Site-CLI auf der Box. Benötigt einen ab dem ersten Boot vorhandenen Schlüssel und einen Host innerhalb des VNet.

Serielle KonsoleFür einen Knoten ganz ohne funktionierenden Netzwerkpfad. Eine Sitzung pro VM, Einfügelimit von 2.048 Zeichen.