Виклики Apex виходять із Salesforce, а не з вашого VPN
VPN на ноутбуці дає вашому браузеру шлях, а не Apex чи Marketing Cloud. Зіставте реального викликача з публічним шлюзом або кваліфікованим приватним з'єднанням.
Приватний API відповідає в браузері тієї миті, коли ноутбук приєднується до VPN, тож інтеграція мала б працювати. Вона не працює, бо код, що виконує виклик, запускається зовсім в іншому місці. Apex виконується на серверах застосунків Salesforce, а серверна активність у Marketing Cloud — у середовищі виконання цього продукту. Жодне з них не успадковує тунель вашого ноутбука. Виконайте це як коротку процедуру: визначте викликача, оберіть вхід, до якого цей викликач може дістатися, з'єднайте шлях від початку до кінця, а потім перевірте із самого середовища виконання.
Напишіть картку викликача до будь-якої зміни мережі
Заповніть п'ять полів і відмовтеся вгадувати будь-яке з них. Продукт виконання та контекст визначають усе подальше, тому починайте звідти, а не з брандмауера сервера.
| Field | What it must answer |
|---|---|
| Runtime | Which product and execution context issues the request? |
| Endpoint | Which hostname must that runtime resolve, and to what? |
| Path | Which supported public entry or private connection carries it? |
| Identity | Which credential and which operation is the API asked to authorize? |
| Failure | How do responses return, and what happens when the path is down? |
Вкладка браузера і виклик Apex — два різні клієнти, і робочий браузер доводить лише те, що шлях існує з вашого робочого столу. Якщо поле середовища виконання каже Apex, доречне питання — з яких адрес виходить Salesforce, а не які адреси має ваш ноутбук. Тому тунель, який дозволяє API завантажитися в браузері, може залишити інтеграцію з тим самим тайм-аутом, що й раніше. Картка викликача потрібна, щоб зупинити цю помилку до того, як хтось відредагує брандмауер.
Оберіть вхід, яким викликач справді може скористатися
Обидва варіанти законні й розв'язують різні задачі. Перший — навмисний публічний вхід: шлюз API через HTTPS або інтеграційний сервіс, що автентифікує викликача, застосовує вузькі дозволи й тримає захищене з'єднання з приватним backend. Це не те саме, що виставити кожен сервіс backend або пробросити порт керування в інтернет.
Другий — кваліфіковане приватне з'єднання. Документація Salesforce про вихідний Private Connect описує маршрутизацію підтримуваних викликів через Outbound Network Connection, прив'язане до іменованих облікових даних, за визначеною схемою AWS PrivateLink. Функція має обмеження за редакцією, ліцензією та продуктом, тому підтвердьте відповідність організації, перш ніж проєктувати навколо неї.
Жоден із варіантів не є клієнтом OpenVPN, встановленим усередині Salesforce, і старе твердження, що кожна інтеграція мусить досягати публічного backend, надто широке там, де пасує підтримуване приватне з'єднання. Оберіть те, що підтримує середовище виконання, а потім завершіть шлях до реального API: кінцева точка AWS не знає вашого локального ресурсу й не успадковує маршрут ноутбука. DNS, маршрутизація backend, політика доступу та зворотний трафік мають відповідати обраній архітектурі. Недобудований приватний шлях відмовляє так, що це виглядає точно як проблема автентифікації.
З'єднайте приватний шлях від початку до кінця
Рухайтеся від API назовні й зупиніться на першій прогалині. Підтвердьте, що backend відповідає локально, потім що приватна кінцева точка до нього доходить, а потім що іменовані облікові дані та їхнє вихідне з'єднання націлені на цю точку.
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.40.8.20:8080/health
dig +short api.partner.example
sf apex run --file scripts/apex/callout-check.apex --target-org integrationПерша команда доводить, що backend здоровий зсередини приватної мережі, друга показує, у що розв'язується ім'я, а третя виконує виклик із реального середовища виконання Salesforce. 200 від першої та збій від третьої локалізують прогалину в шляху або облікових даних, а не в сервісі.
Тримайте область ідентичності точною під час з'єднання. Іменовані облікові дані самі не виправляють недосяжну кінцеву точку, бо облікові дані й приватне з'єднання — пов'язані налаштування з різними задачами. Список дозволених IP звужує мережевий допуск і не є обліковими даними API, тому зберігайте звичайну перевірку TLS і власний процес автентифікації та ротації сервісу. Якщо тест проходить лише після вимкнення перевірки сертифіката, ви знайшли проблему імені хоста, а не шляху, і сертифікат усе одно має збігатися.
Перевірте із середовища виконання, потім запишіть відкат
Прийміть нешкідливий дозволений запит із середовища виконання інтеграції, а не зі своєї машини. Запишіть спостережене джерело сервісу-отримувача, автентифікований суб'єкт, результат і один навмисно відхилений запит, який має зазнати невдачі.
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://api.partner.example/v1/ping
curl -sS -o /dev/null -w '%{http_code}\n' -H 'Authorization: Bearer invalid' https://api.partner.example/v1/pingВиконайте ті самі дві перевірки з власної мережі backend, щоб спостережене джерело можна було порівняти з тим, що видало середовище виконання. 200, за яким іде 401 або 403, — потрібна форма; два 200 означають, що шлях відмови насправді не застосовується.
Напишіть відкат до того, як він знадобиться: який запис списку дозволених, іменовані облікові дані чи вихідне з'єднання ви змінили, кому це належить і як відновити попереднє значення. Потім замкніть цикл, назвавши в заявці хмарного викликача та повний шлях сервісу, щоб ніхто не відкрив ту саму проблему знову як проблему VPN.