Salesforce CLI-Login über ein VPN: CLI, Browser und API-Host

Fehler beim Salesforce CLI-Login werden als ein Problem gemeldet und sind meist drei. Der CLI-Prozess läuft irgendwo, der Browser, der den Web-Flow abschließt, läuft irgendwo, und der spätere API-Aufruf läuft irgendwo, und diese drei Orte müssen sich weder Route noch Resolver noch Allowlist teilen. Sie zu vergleichen ist der schnellste Weg herauszufinden, welchen davon der Tunnel tatsächlich blockiert. Nichts in der Login-Ausgabe nennt, welcher der drei fehlgeschlagen ist.

Drei Hosts, eine Login-Geschichte

Der Web-Login-Flow übergibt den Identitätsschritt an einen Browser, und dieser Browser ist oft auf dem Laptop, während die CLI auf einem entfernten Entwicklungshost oder in einem Container sitzt. Der Laptop hat den VPN-Client, der entfernte Host hat, was das Plattformteam ihm gab, und keine der beiden Anordnungen deckt automatisch die andere ab. Ein VPN-Symbol in der Statusleiste sagt nichts über einen Host, auf dem der Client nie lief.

Nach dem Login stellt die CLI ihre eigenen API-Anfragen von dort, wo der Prozess lebt. Diese Anfragen brauchen DNS, Routing, TLS-Vertrauen und Client-Autorisierung auf der Org-Seite, also vier getrennte Prüfungen, die jeweils allein scheitern können. Ein Browser, der sich wunderbar angemeldet hat, sagt Ihnen über keine davon etwas.

Halten Sie beide Hälften auf einer Zeitachse, bewerten Sie sie aber getrennt. Ein einzelnes Ticket kann dann sagen, welche Hälfte brach, ohne daraus eine Diskussion über Zuständigkeit zu machen.

Nehmen Sie den Org-Eintrag von der Org, nicht aus dem Gedächtnis

Der Web-Flow nimmt eine Instanz-URL und speichert das Ergebnis unter einem Alias, und beide Werte sollten vom Org-Eigentümer kommen und nicht aus der Terminalhistorie eines Kollegen. Ein aus einem alten Ticket kopierter Sandbox-Host ist eine häufige Ursache für einen Login, der sich gegen die falsche Org authentifiziert und dann jede Abfrage scheitern lässt.

Verwenden Sie die Form, die das installierte Plugin dokumentiert, mit Ihrem eigenen genehmigten Host und Alias. Diese Dokumentation ist die Referenz für Flags, die sich zwischen sfdx und der aktuellen CLI geändert haben.

sf org login web --instance-url https://acme--uat.sandbox.my.salesforce.com --alias uat
sf org display --target-org uat

Hostname und Alias oben sind Beispiele, keine Standardwerte, die Sie kopieren sollten. Schließen Sie die normalen Browser-Identitäts- und MFA-Schritte ab, statt sie per Skript zu umgehen, und legen Sie niemals ein Passwort, eine Sitzungskennung oder einen Authenticator-Seed in einen Shell-Befehl, um die Abfrage zu überspringen.

Was die zwischengespeicherte Autorisierung beweist

Ein Alias, der in der lokalen Autorisierungsliste erscheint, beweist, dass ein Login auf dieser Maschine einmal erfolgreich war. Die Liste wird aus lokalem Speicher gelesen und kontaktiert die Org nicht, um zu bestätigen, dass das Token noch funktioniert, also können ein gesund aussehender Eintrag und ein abgelehnter API-Aufruf gleichzeitig wahr sein. Behandeln Sie den Cache als Aufzeichnung der Vergangenheit, nicht als Test der Live-Verbindung. Eine Cache-Prüfung beantwortet eine Support-Frage, schließt aber nie eine Untersuchung der Konnektivität ab.

Dieselbe Unterscheidung gilt für die Browser-Sitzung. Ein Tab, der die Org noch anzeigt, bedeutet nicht, dass das gespeicherte Token der CLI zur aktuellen Richtlinie passt, denn Token-Lebensdauer, IP-Einschränkungen und Client-App-Regeln werden an der API-Grenze durchgesetzt.

Lesen Sie den lokalen Eintrag, bevor Sie ihn löschen, denn Alias und Org-Host sind die zwei Fakten, nach denen der Support fragen wird. Einen Alias zu entfernen ist umkehrbar, aber den falschen mitten in einem Vorfall zu entfernen fügt nur ein zweites Problem hinzu.

Wo die API-Anfrage tatsächlich abgelehnt wird

Verfolgen Sie eine Anfrage von Anfang bis Ende und notieren Sie, welche Komponente antwortet. Ein TLS-Fehler benennt ein anderes Problem als ein 403, das ein anderes Problem benennt als ein Timeout, und ein Timeout ist der einzige der drei, der auf den Tunnel als ersten Verdächtigen zeigt. Die Fehlerklasse vor der Meldung zu lesen spart viel Raten. Schreiben Sie die Klasse auf, bevor Sie irgendetwas erneut ausführen.

Quelladressbeschränkungen sind der Fall, der einen Login erzeugt, der funktioniert, und eine Abfrage, die es nicht tut, weil der Browser-Flow und der API-Aufruf über verschiedene Adressen hinausgehen können. Das mit einer breiteren Allowlist zu beheben ist eine Entscheidung des Org-Eigentümers, keine Bequemlichkeit, und es sollte der kleinste Bereich sein, der den Host abdeckt.

Erfassen Sie den fehlschlagenden Befehl, den Alias, den Ausführungshost und den Zeitstempel, und lassen Sie das Token aus allem heraus, was Sie in das Ticket einfügen. Diese vierteilige Zusammenfassung braucht der Org-Eigentümer, um seine Seite zu prüfen.

Prüfen Sie den Flow von dem Host aus, der ihn nutzen wird

Testen Sie von der Maschine, die die Arbeitslast ausführen wird. Ein auf Ihrem Laptop verifizierter Login sagt nichts über einen Build-Agenten in einer anderen Netzwerkzone, und der Unterschied ist genau das, was Sie finden wollen.

Verwenden Sie für die Prüfung einen harmlosen autorisierten Lesezugriff, und behalten Sie den ersten Fehler, wenn er fehlschlägt.

sf org list auth
sf org display --target-org uat
sf data query --target-org uat --query "select Id, Name from Organization"

Wenn der Login gelingt, die Abfrage aber scheitert, sind die verbleibenden Kandidaten DNS, Routing, TLS-Interception und Client-Richtlinie auf der Org-Seite, und jeder hat seinen eigenen Eigentümer. Wenn der Login selbst scheitert, sind Browser und CLI wahrscheinlich nicht auf demselben Host, und die Behebung gehört zur Anordnung zwischen ihnen statt zum Tunnel. Automatisierung bekommt eine weitere Regel: Ein unbeaufsichtigter Job braucht einen genehmigten zertifikatsbasierten Login, denn eine zwischengespeicherte interaktive Sitzung, die auf einen Worker kopiert wird, ist kein Identitätsdesign.