Volania Apex vychádzajú zo Salesforce, nie z vášho VPN
VPN na notebooku dáva vášmu prehliadaču cestu, nie Apexu či Marketing Cloudu. Spárujte skutočného volajúceho s verejnou bránou alebo kvalifikovaným privátnym pripojením.
Privátne API odpovedá v prehliadači v momente, keď sa notebook pripojí k VPN, takže integrácia by mala fungovať. Nefunguje, pretože kód, ktorý volanie vykonáva, beží úplne inde. Apex beží na aplikačných serveroch Salesforce a serverová aktivita v Marketing Cloud beží v runtime tohto produktu. Ani jedno nededí tunel vášho notebooku. Urobte to ako krátky postup: identifikujte volajúceho, vyberte vstup, na ktorý sa tento volajúci dostane, prepojte cestu od začiatku do konca a potom overte priamo z runtime.
Napíšte kartu volajúceho skôr než akúkoľvek zmenu siete
Vyplňte päť polí a odmietnite ktorékoľvek z nich hádať. Produkt vykonávania a kontext rozhodujú o všetkom ďalšom, takže začnite tam, a nie pri firewalle servera.
| 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? |
Karta prehliadača a volanie Apex sú dvaja rôzni klienti a fungujúci prehliadač dokazuje len to, že z vášho stola existuje cesta. Ak pole runtime hovorí Apex, príslušná otázka znie, z ktorých adries Salesforce vychádza, a nie ktoré adresy má váš notebook. Preto môže tunel, vďaka ktorému sa API v prehliadači načíta, nechať integráciu zlyhávať s rovnakým timeoutom ako predtým. Karta volajúceho existuje preto, aby túto chybu zastavila skôr, než niekto upraví firewall.
Vyberte vstup, ktorý volajúci naozaj môže použiť
Oba návrhy sú legitímne a riešia rôzne problémy. Prvý je zámerný verejný vstup: brána API cez HTTPS alebo integračná služba, ktorá volajúceho overí, uplatní úzke oprávnenia a drží chránené pripojenie k privátnemu backendu. To nie je to isté ako vystaviť každú backendovú službu alebo presmerovať správcovský port do internetu.
Druhý je kvalifikované privátne pripojenie. Dokumentácia odchádzajúceho Private Connect od Salesforce opisuje smerovanie podporovaných volaní cez Outbound Network Connection viazané na pomenované prihlasovacie údaje, podľa definovaného usporiadania AWS PrivateLink. Funkcia má obmedzenia edície, licencie a produktu, takže pred návrhom potvrďte, že organizácia spĺňa podmienky.
Ani jeden návrh nie je klient OpenVPN nainštalovaný vnútri Salesforce a staršie tvrdenie, že každá integrácia musí dosiahnuť verejný backend, je príliš široké všade, kde sa hodí podporované privátne pripojenie. Vyberte to, čo runtime podporuje, a potom dokončite cestu k skutočnému API: koncový bod AWS nepozná váš miestny zdroj a nededí trasu vášho notebooku. DNS, smerovanie backendu, prístupová politika aj spätná prevádzka musia sledovať architektúru, ktorú ste zvolili. Nedostavaná privátna cesta zlyháva spôsobom, ktorý vyzerá presne ako problém s overovaním.
Prepojte privátnu cestu od začiatku do konca
Postupujte od API von a zastavte sa pri prvej medzere. Potvrďte, že backend odpovedá lokálne, potom že sa k nemu privátny koncový bod dostane, a nakoniec že pomenované prihlasovacie údaje a ich odchádzajúce pripojenie mieria na tento koncový bod.
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 integrationPrvý príkaz dokazuje, že backend je zdravý zvnútra privátnej siete, druhý ukazuje, na čo sa meno prekladá, a tretí vykonáva volanie zo skutočného runtime Salesforce. 200 z prvého a zlyhanie z tretieho izoluje medzeru na ceste alebo v prihlasovacích údajoch, nie v službe.
Pri prepájaní udržujte rozsah identity presný. Pomenované prihlasovacie údaje samy nedostupný koncový bod neopravia, pretože údaje a privátne pripojenie sú súvisiace nastavenia s oddelenými úlohami. Zoznam povolených IP zužuje sieťové prijímanie a nie je prihlasovacím údajom API, preto zachovajte bežné overenie TLS aj vlastný proces overovania a rotácie služby. Ak test prejde len po vypnutí kontroly certifikátu, našli ste problém s názvom hostiteľa, nie s cestou, a certifikát stále musí zodpovedať.
Overte z runtime a potom zaznamenajte vrátenie
Prijmite neškodnú povolenú požiadavku z runtime integrácie, nie zo svojho počítača. Zaznamenajte pozorovaný zdroj prijímajúcej služby, overený subjekt, výsledok a jednu zámerne odmietnutú požiadavku, ktorá musí zlyhať.
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/pingSpustite tie isté dve sondy z vlastnej siete backendu, aby bolo možné pozorovaný zdroj porovnať s tým, čo vytvoril runtime. 200 nasledované 401 alebo 403 je tvar, ktorý chcete; dve 200 znamenajú, že cesta odmietnutia sa v skutočnosti nevynucuje.
Napíšte vrátenie skôr, než ho budete potrebovať: ktorý záznam zoznamu povolených, pomenované prihlasovacie údaje alebo odchádzajúce pripojenie ste zmenili, kto ho vlastní a ako obnoviť predchádzajúcu hodnotu. Potom uzavrite slučku tým, že v tikete pomenujete volajúceho v cloude a úplnú cestu služby, aby nikto neotvoril rovnaký problém znova ako problém VPN.