Выклікі 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 або сэрвіс інтэграцыі, які аўтэнтыфікуе выклікальніка, прымяняе вузкія дазволы і трымае абароненае злучэнне з прыватным бэкэндам. Гэта не тое ж самае, што адкрыць усе сэрвісы бэкэнда або пракінуць порт кіравання ў інтэрнэт.
Другая — кваліфікаванае прыватнае злучэнне. Дакументацыя Salesforce пра зыходны Private Connect апісвае маршрутызацыю падтрыманых выклікаў праз Outbound Network Connection, прывязанае да названых уліковых даных, паводле вызначанай схемы AWS PrivateLink. Функцыя мае абмежаванні па рэдакцыі, ліцэнзіі і прадукце, таму перад праектаваннем пацвердзіце, што арганізацыя адпавядае ўмовам.
Ні адна схема не з'яўляецца кліентам OpenVPN, усталяваным унутры Salesforce, і старое сцвярджэнне, што кожная інтэграцыя павінна дасягаць публічнага бэкэнда, занадта шырокае там, дзе падыходзіць падтрыманае прыватнае злучэнне. Абярыце тое, што падтрымлівае асяроддзе выканання, і давядзіце шлях да рэальнага API: канцавы пункт AWS не ведае вашага лакальнага рэсурсу і не ўспадкоўвае маршрут вашага ноўтбука. DNS, маршрутызацыя бэкэнда, палітыка доступу і зваротны трафік павінны адпавядаць абранай архітэктуры. Недбудаваны прыватны шлях адмаўляе так, што выглядае дакладна як праблема аўтэнтыфікацыі.
Звяжыце прыватны шлях ад пачатку да канца
Рухайцеся ад API вонкава і спыніцеся на першай прагаліне. Пацвердзіце, што бэкэнд адказвае лакальна, затым што прыватны канцавы пункт дасягае яго, а затым што названыя ўліковыя даныя і іх зыходнае злучэнне накіраваны на гэты пункт.
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Першая каманда даказвае, што бэкэнд здаровы знутры прыватнай сеткі, другая паказвае, у што развязавецца імя, а трэцяя выконвае выклік з рэальнага асяроддзя выканання 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Выканайце тыя ж два запыты з уласнай сеткі бэкэнда, каб назіраную крыніцу можна было параўнаць з тым, што выдала асяроддзе выканання. Патрэбная форма — 200, за якім ідзе 401 ці 403; два 200 азначаюць, што шлях адмовы насамрэч не прымяняецца.
Напішыце адкат да таго, як ён спатрэбіцца: які запіс спісу дазволеных, названыя ўліковыя даныя ці зыходнае злучэнне вы змянілі, хто ім валодае і як вярнуць папярэдняе значэнне. Затым замкніце цыкл, назваўшы хмарнага выклікальніка і поўны шлях сэрвісу ў заяўцы, каб ніхто не адкрыў тую ж праблему зноў як праблему VPN.