Вход в Salesforce CLI через VPN: CLI, браузер и хост API

Сбои входа в Salesforce CLI сообщают как одну проблему, а обычно их три. Процесс CLI работает где-то, браузер, завершающий веб-поток, работает где-то, и последующий вызов API работает где-то, и эти три места не обязаны делить маршрут, резолвер или список разрешённых. Сравнить их — самый быстрый способ понять, какой из них на самом деле блокирует туннель. Ничто в выводе входа не указывает, какой из трёх отказал.

Три хоста, одна история входа

Веб-поток входа передаёт шаг идентификации браузеру, и этот браузер часто находится на ноутбуке, пока CLI сидит на удалённом хосте разработки или в контейнере. На ноутбуке есть клиент VPN, на удалённом хосте есть то, что дала ему команда платформы, и ни одна из двух схем автоматически не покрывает другую. Значок VPN в строке состояния ничего не говорит о хосте, который ни разу не запускал клиент.

После входа CLI делает собственные запросы к API оттуда, где живёт процесс. Эти запросы требуют DNS, маршрутизации, доверия TLS и авторизации клиента на стороне org — четыре отдельные проверки, и каждая может отказать сама по себе. Браузер, который прекрасно вошёл, ничего не говорит ни об одной из них.

Держите обе половины на одной временной шкале, но оценивайте их отдельно. Тогда один тикет сможет сказать, какая половина сломалась, не превращая это в спор о владении.

Берите запись org у org, а не из памяти

Веб-поток берёт URL экземпляра и сохраняет результат под псевдонимом, и оба значения должны приходить от владельца org, а не из истории терминала коллеги. Хост sandbox, скопированный из старого тикета, — частая причина входа, который аутентифицируется в неправильной 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, вместо того чтобы обходить их скриптом, и никогда не помещайте пароль, идентификатор сессии или зерно аутентификатора в shell-команду, чтобы пропустить запрос.

Что доказывает кэшированная авторизация

Псевдоним в локальном списке авторизаций доказывает, что вход когда-то удался на этой машине. Список читается из локального хранилища и не обращается к org, чтобы подтвердить, что токен ещё работает, поэтому здоровый на вид запись и отклонённый вызов API могут быть верны одновременно. Относитесь к кэшу как к записи о прошлом, а не как к проверке живой связности. Проверка кэша отвечает на вопрос поддержки, но никогда не закрывает расследование связности.

То же различие относится к сессии браузера. Вкладка, которая всё ещё показывает org, не означает, что сохранённый токен CLI соответствует текущей политике, потому что срок жизни токена, ограничения по IP и правила клиентского приложения применяются на границе API.

Прочитайте локальную запись, прежде чем удалять её, так как псевдоним и хост org — это два факта, которые запросит поддержка. Удаление псевдонима обратимо, но удаление неверного посреди инцидента лишь добавляет вторую проблему.

Где запрос к API на самом деле отклоняется

Проследите один запрос от начала до конца и отметьте, какой компонент отвечает. Сбой TLS называет другую проблему, чем 403, который называет другую проблему, чем тайм-аут, и только тайм-аут из трёх указывает на туннель как первого подозреваемого. Чтение класса ошибки до сообщения экономит много догадок. Запишите класс, прежде чем что-либо перезапускать.

Ограничения адреса источника — это случай, когда вход работает, а запрос нет, потому что веб-поток и вызов API могут выходить через разные адреса. Исправлять это более широким списком разрешённых — решение владельца org, а не удобство, и это должен быть наименьший диапазон, покрывающий хост.

Зафиксируйте сбойную команду, псевдоним, хост выполнения и отметку времени, а токен оставьте вне всего, что вставляете в тикет. Эта сводка из четырёх строк нужна владельцу org, чтобы проверить свою сторону.

Проверьте поток с того хоста, который будет его использовать

Тестируйте с машины, которая будет выполнять рабочую нагрузку. Вход, проверенный на ноутбуке, ничего не говорит об агенте сборки в другой сетевой зоне, и разница — именно то, что вы пытаетесь найти.

Для проверки используйте безвредное разрешённое чтение, и если оно не удастся, сохраните первую ошибку.

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, вероятно, не на одном хосте, и исправление относится к схеме между ними, а не к туннелю. Автоматизация получает ещё одно правило: необслуживаемое задание нуждается в утверждённом входе на основе сертификата, потому что кэшированная интерактивная сессия, скопированная на worker, — не проект идентичности.