Apex позиви излазе из Salesforce-а, а не из вашег VPN-а
VPN на лаптопу даје вашем прегледачу пут, не Apex-у или Marketing Cloud-у. Упарите стварног позиваоца са јавним приступником или квалификованом приватном везом.
Приватни API одговара у вашем прегледачу оног тренутка када се лаптоп придружи VPN-у, па би интеграција требало да ради. Не ради, јер се код који упућује позив извршава сасвим негде другде. Apex се извршава на апликационим серверима Salesforce-а, а серверска активност у Marketing Cloud-у извршава се у извршном окружењу тог производа. Ни једно од њих не наслеђује тунел вашег лаптопа. Спроведите то као кратак поступак: идентификујте позиваоца, одаберите улаз до којег тај позивалац може да дође, повежите пут од почетка до краја, па затим проверите из самог извршног окружења.
Напишите картицу позиваоца пре било какве мрежне промене
Попуните пет поља и одбијте да погодите било које од њих. Производ извршавања и контекст одлучују о свему даље, па почните одатле, а не од firewall-а сервера.
| 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 учита у прегледачу може оставити интеграцију да пада са истим тајмаутом као пре. Картица позиваоца постоји да заустави ту грешку пре него што неко уреди firewall.
Одаберите улаз који позивалац заиста може користити
Оба дизајна су легитимна и решавају различите проблеме. Први је намерни јавни улаз: HTTPS API приступник или интеграциона услуга која аутентификује позиваоца, примењује уска овлашћења и држи заштићену везу с приватним 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 проблем.