VPN 経由の Salesforce CLI ログイン：CLI、ブラウザ、API ホスト

Salesforce CLI のログイン失敗は一つの問題として報告されますが、実際には通常三つです。CLI プロセスはどこかで動き、Web フローを完了するブラウザはどこかで動き、後続の API 呼び出しはどこかで動くのであり、その三か所はルート、リゾルバ、許可リストを共有している必要はありません。それらを比較することが、トンネルが実際にどれを遮断しているかを知る最速の方法です。ログイン出力のどこにも、三つのどれが失敗したかは書かれていません。

三つのホスト、一つのログイン物語

Web ログインフローは本人確認の段階をブラウザに渡し、そのブラウザは多くの場合ノート PC 上にあり、CLI は遠隔の開発ホストやコンテナ上にあります。ノート PC には VPN クライアントがあり、遠隔ホストにはプラットフォームチームが与えたものがあり、どちらの構成も他方を自動的に覆うわけではありません。ステータスバーの VPN アイコンは、クライアントを一度も実行していないホストについては何も語りません。

ログイン後、CLI はプロセスが存在する場所から独自の API リクエストを行います。そのリクエストには DNS、ルーティング、TLS の信頼、org 側のクライアント認可が必要で、これは四つの別々の検査であり、それぞれが単独で失敗し得ます。見事にサインインしたブラウザは、そのどれについても何も教えてくれません。

両方の半分を一つのタイムラインに置きつつ、別々に採点してください。そうすれば一枚のチケットで、どちらの半分が壊れたかを、所有権の議論にせずに言えます。

org の登録内容は記憶ではなく org から取る

Web フローはインスタンス URL を取り、結果をエイリアスの下に保存しますが、どちらの値も同僚のターミナル履歴ではなく org の所有者から取るべきです。古いチケットからコピーしたサンドボックスのホストは、誤った org に対して認証し、その後のすべてのクエリが失敗するログインのよくある原因です。

インストール済みプラグインが文書化している形を、自分が承認されたホストとエイリアスで使ってください。その文書は、sfdx と現在の CLI の間で変わったフラグの参照先です。

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

上記のホスト名とエイリアスは例であり、コピーすべき既定値ではありません。 通常のブラウザ本人確認と MFA の手順を完了し、スクリプトで回避しないでください、また、プロンプトを飛ばすためにパスワード、セッション識別子、認証器のシードをシェルコマンドに入れないでください。

キャッシュされた認可が証明すること

ローカルの認可一覧に現れるエイリアスは、そのマシンでかつてログインが成功したことを証明します。一覧はローカルストレージから読まれ、トークンがまだ有効かを確認するために org に問い合わせることはないため、健全に見えるエントリと拒否された API 呼び出しが同時に真であり得ます。キャッシュは過去の記録として扱い、生きた接続テストとは見なさないでください。キャッシュの確認はサポートの問いに答えますが、接続の調査を閉じることは決してありません。

同じ区別はブラウザのセッションにも当てはまります。org をまだ表示しているタブは、トークンの寿命、IP 制限、クライアントアプリの規則が API の境界で適用されるため、CLI の保存済みトークンが現在のポリシーに合致することを意味しません。

ローカルの記録は、エイリアスと org のホストがサポートの尋ねる二つの事実なので、削除する前に読んでください。エイリアスの削除は元に戻せますが、インシデントの最中に間違ったものを削除すると、二つ目の問題が増えるだけです。

API リクエストが実際に拒否される場所

一つのリクエストを最初から最後まで追い、どのコンポーネントが応答するかを記録してください。TLS の失敗は 403 とは別の問題を指し、それはタイムアウトとは別の問題を指し、タイムアウトだけがトンネルを最初の容疑者として指し示します。メッセージより先にエラークラスを読むことで、多くの推測を省けます。何かを再実行する前にクラスを書き留めてください。

送信元アドレスの制限は、ブラウザのフローと API 呼び出しが異なるアドレスから出ることがあるため、ログインは通るのにクエリは通らないというケースを作ります。それをより広い許可リストで直すのは org 所有者の判断であり、便宜ではなく、ホストを覆う最小の範囲であるべきです。

失敗したコマンド、エイリアス、実行ホスト、タイムスタンプを記録し、チケットに貼るものからトークンは外してください。その四行の要約こそ、org の所有者が自分の側を確認するために必要なものです。

使う側のホストからフローを確認する

ワークロードを実行するマシンからテストしてください。ノート PC で検証したログインは、別のネットワークゾーンにあるビルドエージェントについては何も語らず、その差こそ、あなたが見つけようとしているものです。

確認には無害な許可済みの読み取りを使い、失敗した場合は最初のエラーを残してください。

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

ログインは成功するのにクエリが失敗する場合、残る候補は DNS、ルーティング、TLS 傍受、org 側のクライアントポリシーであり、それぞれに担当者がいます。ログイン自体が失敗する場合、ブラウザと CLI はおそらく同じホストになく、修正はトンネルではなく両者の間の構成に属します。自動化にはもう一つの規則があり、キャッシュされた対話型セッションをワーカーにコピーすることは身元設計ではないため、無人ジョブには承認された証明書ベースのログインが必要です。