As chamadas de Apex saen de Salesforce, non do teu VPN
Unha VPN no portátil dálle un camiño ao teu navegador, non a Apex nin a Marketing Cloud. Emparexa o chamador real cunha pasarela pública ou unha conexión privada cualificada.
A API privada responde no teu navegador no momento en que o portátil se une á VPN, así que a integración debería funcionar. Non funciona, porque o código que fai a chamada execútase noutro lugar por completo. Apex execútase nos servidores de aplicacións de Salesforce, e unha actividade do lado do servidor de Marketing Cloud execútase no runtime dese produto. Ningún dos dous herda o túnel do teu portátil. Abórdao como un procedemento curto: identifica o chamador, escolle unha entrada que ese chamador poida acadar, conecta o camiño de extremo a extremo e despois verifica desde o propio runtime.
Escribe a ficha do chamador antes de calquera cambio de rede
Enche cinco campos e négate a adiviñar ningún. O produto de execución e o contexto deciden todo o demais, así que comeza por aí e non polo cortalumes do servidor.
| 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? |
Unha pestana do navegador e unha chamada de Apex son dous clientes distintos, e un navegador que funciona só demostra que existe un camiño desde o teu escritorio. Se o campo do runtime di Apex, a pregunta pertinente é de que enderezos sae Salesforce, non que enderezos ten o teu portátil. Por iso un túnel que fai cargar a API no navegador pode deixar a integración fallando co mesmo tempo de espera que antes. A ficha do chamador existe para deter ese erro antes de que alguén edite un cortalumes.
Escolle a entrada que o chamador pode usar de verdade
Os dous deseños son lexítimos e resolven problemas distintos. O primeiro é unha entrada pública deliberada: unha pasarela de API por HTTPS ou un servizo de integración que autentica o chamador, aplica permisos estreitos e mantén unha conexión protexida co backend privado. Iso non é o mesmo que expoñer todos os servizos do backend ou reenviar un porto de xestión a internet.
O segundo é unha conexión privada cualificada. A documentación de Private Connect saínte de Salesforce describe o encamiñamento das chamadas admitidas mediante unha Outbound Network Connection vinculada a unha credencial con nome, sobre a súa disposición definida de AWS PrivateLink. A funcionalidade ten restricións de edición, licenza e produto, así que confirma que a organización cumpre os requisitos antes de deseñar arredor dela.
Ningún dos dous deseños é un cliente OpenVPN instalado dentro de Salesforce, e a vella afirmación de que toda integración debe acadar un backend público é demasiado ampla alí onde encaixa unha conexión privada admitida. Escolle a que admita o runtime e despois completa o camiño ata a API real: un punto de conexión de AWS non coñece o teu recurso local nin herda a ruta do teu portátil. O DNS, o encamiñamento do backend, a política de acceso e o tráfico de resposta teñen que seguir a arquitectura que escolliches. Un camiño privado a medio construír falla dun xeito que parece exactamente un problema de autenticación.
Conecta o camiño privado de extremo a extremo
Traballa desde a API cara a fóra e detente no primeiro oco. Confirma que o backend responde en local, logo que o punto de conexión privado chega a el e despois que a credencial con nome e a súa conexión saínte apuntan a ese punto.
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 integrationO primeiro comando demostra que o backend está san desde dentro da rede privada, o segundo mostra a que resolve o nome e o terceiro executa unha chamada desde o runtime real de Salesforce. Un 200 do primeiro e un fallo do terceiro illan o oco no camiño ou na credencial, non no servizo.
Mantén preciso o alcance da identidade mentres conectas. Unha credencial con nome non repara por si soa un punto de conexión inalcanzable, porque a credencial e a conexión privada son axustes relacionados con tarefas separadas. Unha lista de IP permitidas estreita a admisión de rede e non é unha credencial de API, así que conserva a validación TLS normal e o proceso propio de autenticación e rotación do servizo. Se unha proba só pasa despois de desactivar a comprobación do certificado, atopaches un problema de nome de host e non de camiño, e o certificado segue tendo que coincidir.
Verifica desde o runtime e despois rexistra a reversión
Acepta unha petición permitida e inocua desde o runtime da integración, non desde a túa máquina. Rexistra a orixe observada polo servizo receptor, o principal autenticado, o resultado e unha petición denegada a propósito que debe fallar.
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/pingExecuta as mesmas dúas sondas desde a rede do propio backend para que a orixe observada poida compararse co que produciu o runtime. Un 200 seguido dun 401 ou un 403 é a forma que queres; dous 200 significan que a ruta de denegación non se aplica de verdade.
Escribe a reversión antes de necesitala: que entrada da lista permitida, credencial con nome ou conexión saínte cambiaches, quen a posúe e como restaurar o valor anterior. Logo pecha o círculo nomeando o chamador na nube e a ruta completa do servizo no ticket, para que ninguén reabra o mesmo asunto como un problema de VPN.