Volání Apex odcházejí ze Salesforce, ne z vaší VPN
VPN na notebooku dává vašemu prohlížeči cestu, ne Apexu ani Marketing Cloud. Spárujte skutečného volajícího s veřejnou branou nebo kvalifikovaným privátním připojením.
Privátní API odpovídá ve vašem prohlížeči ve chvíli, kdy se notebook připojí k VPN, takže integrace by měla fungovat. Nefunguje, protože kód, který volání provádí, běží úplně jinde. Apex běží na aplikačních serverech Salesforce a serverová aktivita v Marketing Cloud běží v runtime tohoto produktu. Ani jedno nedědí tunel vašeho notebooku. Provedte to jako krátký postup: určete volajícího, zvolte vstup, na který se tento volající dostane, propojte cestu od začátku do konce a poté ověřte přímo z runtime.
Napište kartu volajícího dřív než jakoukoli změnu sítě
Vyplňte pět polí a odmítněte kterékoli z nich hádat. Produkt provádění a kontext rozhodují o všem dalším, takže začněte tam, a ne u firewallu serveru.
| 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 prohlížeče a volání Apex jsou dva různí klienti a funkční prohlížeč dokazuje jen to, že z vašeho stolu existuje cesta. Pokud pole runtime říká Apex, příslušná otázka zní, ze kterých adres Salesforce vychází, a ne které adresy má váš notebook. Proto může tunel, díky kterému se API v prohlížeči načte, nechat integraci selhávat se stejným timeoutem jako dřív. Karta volajícího existuje proto, aby tuto chybu zastavila dřív, než někdo upraví firewall.
Zvolte vstup, který volající skutečně může použít
Oba návrhy jsou legitimní a řeší různé problémy. První je záměrný veřejný vstup: brána API přes HTTPS nebo integrační služba, která volajícího ověří, uplatní úzká oprávnění a drží chráněné připojení k privátnímu backendu. To není totéž jako vystavit každou backendovou službu nebo přesměrovat správcovský port do internetu.
Druhý je kvalifikované privátní připojení. Dokumentace odchozího Private Connect od Salesforce popisuje směrování podporovaných volání přes Outbound Network Connection vázané na pojmenované přihlašovací údaje, podle definovaného uspořádání AWS PrivateLink. Funkce má omezení edice, licence a produktu, takže před návrhem potvrďte, že organizace splňuje podmínky.
Ani jeden návrh není klient OpenVPN nainstalovaný uvnitř Salesforce a starší tvrzení, že každá integrace musí dosáhnout veřejného backendu, je příliš široké všude, kde se hodí podporované privátní připojení. Zvolte to, co runtime podporuje, a pak dokončete cestu ke skutečnému API: koncový bod AWS nezná váš místní prostředek a nedědí trasu vašeho notebooku. DNS, směrování backendu, přístupová politika i zpětný provoz musí sledovat architekturu, kterou jste zvolili. Nedostavěná privátní cesta selhává způsobem, který vypadá přesně jako problém s ověřováním.
Propojte privátní cestu od začátku do konce
Postupujte od API ven a zastavte se u první mezery. Potvrďte, že backend odpovídá lokálně, potom že se k němu privátní koncový bod dostane, a nakonec že pojmenované přihlašovací údaje a jejich odchozí připojení míří 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 integrationPrvní příkaz dokazuje, že backend je zdravý zevnitř privátní sítě, druhý ukazuje, na co se jméno překládá, a třetí provádí volání ze skutečného runtime Salesforce. 200 z prvního a selhání ze třetího izoluje mezeru na cestě nebo v přihlašovacích údajích, ne ve službě.
Při propojování udržujte rozsah identity přesný. Pojmenované přihlašovací údaje samy nedostupný koncový bod neopraví, protože údaje a privátní připojení jsou související nastavení s oddělenými úkoly. Seznam povolených IP zužuje síťový přístup a není přihlašovacím údajem API, proto zachovejte běžné ověření TLS i vlastní proces ověřování a rotace služby. Pokud test projde jen po vypnutí kontroly certifikátu, našli jste problém s názvem hostitele, ne s cestou, a certifikát stále musí odpovídat.
Ověřte z runtime a potom zaznamenejte vrácení
Přijměte neškodný povolený požadavek z runtime integrace, ne ze svého počítače. Zaznamenejte pozorovaný zdroj přijímající služby, ověřený subjekt, výsledek a jeden záměrně odmítnutý požadavek, který musí selhat.
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/pingSpusťte stejné dvě sondy z vlastní sítě backendu, aby bylo možné pozorovaný zdroj porovnat s tím, co vytvořil runtime. 200 následované 401 nebo 403 je tvar, který chcete; dvě 200 znamenají, že cesta odmítnutí se ve skutečnosti nevynucuje.
Napište vrácení dřív, než ho budete potřebovat: který záznam seznamu povolených, pojmenované přihlašovací údaje nebo odchozí připojení jste změnili, kdo je vlastní a jak obnovit předchozí hodnotu. Potom uzavřete smyčku tím, že v tiketu pojmenujete volajícího v cloudu a úplnou cestu služby, aby nikdo neotevřel stejný problém znovu jako problém VPN.