As callouts do Apex saem do Salesforce, não da sua VPN
Uma VPN no portátil dá ao navegador um caminho, não ao Apex nem ao Marketing Cloud. Combine o chamador real com um gateway público ou uma ligação privada qualificada.
A API privada responde no navegador no momento em que o portátil entra na VPN, por isso a integração deveria funcionar. Não funciona, porque o código que faz a chamada é executado num lugar completamente diferente. O Apex é executado nos servidores de aplicações da Salesforce, e uma atividade do lado do servidor no Marketing Cloud é executada no runtime desse produto. Nenhum deles herda o túnel do seu portátil. Trate isto como um procedimento curto: identifique o chamador, escolha uma entrada que esse chamador consiga alcançar, ligue o caminho de ponta a ponta e depois verifique a partir do próprio runtime.
Escreva a ficha do chamador antes de qualquer alteração de rede
Preencha cinco campos e recuse adivinhar qualquer um deles. O produto de execução e o contexto decidem tudo o resto, por isso comece aí e não pela firewall 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? |
Um separador do navegador e uma callout do Apex são dois clientes diferentes, e um navegador a funcionar só prova que existe um caminho a partir da sua secretária. Se o campo do runtime disser Apex, a pergunta relevante é de que endereços sai a Salesforce, não que endereços tem o seu portátil. É por isso que um túnel que faz a API carregar no navegador pode deixar a integração a falhar com o mesmo tempo limite de antes. A ficha do chamador existe para travar esse erro antes de alguém editar uma firewall.
Escolha a entrada que o chamador consegue realmente usar
Os dois desenhos são legítimos e resolvem problemas diferentes. O primeiro é uma entrada pública deliberada: um gateway de API por HTTPS ou um serviço de integração que autentica o chamador, aplica permissões estreitas e mantém uma ligação protegida ao backend privado. Isso não é o mesmo que expor todos os serviços do backend ou reencaminhar uma porta de gestão para a internet.
O segundo é uma ligação privada qualificada. A documentação do Private Connect de saída da Salesforce descreve o encaminhamento das callouts suportadas através de uma Outbound Network Connection associada a uma credencial com nome, sobre a sua disposição definida de AWS PrivateLink. A funcionalidade tem restrições de edição, licença e produto, por isso confirme que a organização cumpre os requisitos antes de desenhar em torno dela.
Nenhum dos desenhos é um cliente OpenVPN instalado dentro da Salesforce, e a antiga afirmação de que todas as integrações têm de alcançar um backend público é demasiado ampla onde cabe uma ligação privada suportada. Escolha a que o runtime suporta e depois conclua o caminho até à API real: um endpoint da AWS não conhece o seu recurso local nem herda a rota do seu portátil. O DNS, o encaminhamento do backend, a política de acesso e o tráfego de resposta têm todos de seguir a arquitetura que escolheu. Um caminho privado a meio construir falha de uma forma que parece exatamente um problema de autenticação.
Ligue o caminho privado de ponta a ponta
Trabalhe a partir da API para fora e pare no primeiro buraco. Confirme que o backend responde localmente, depois que o endpoint privado o alcança e depois que a credencial com nome e a sua ligação de saída apontam para esse endpoint.
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 prova que o backend está saudável a partir de dentro da rede privada, o segundo mostra para o que o nome resolve e o terceiro executa uma callout a partir do runtime real da Salesforce. Um 200 vindo do primeiro e uma falha vinda do terceiro isolam o buraco no caminho ou na credencial, e não no serviço.
Mantenha o âmbito da identidade preciso enquanto liga. Uma credencial com nome não repara sozinha um endpoint inalcançável, porque a credencial e a ligação privada são definições relacionadas com tarefas separadas. Uma lista de IP permitidos estreita a admissão de rede e não é uma credencial de API, por isso mantenha a validação TLS normal e o processo próprio de autenticação e rotação do serviço. Se um teste só passa depois de desativar a verificação do certificado, encontrou um problema de nome de anfitrião e não de caminho, e o certificado continua a ter de corresponder.
Verifique a partir do runtime e depois registe a reversão
Aceite um pedido permitido e inofensivo a partir do runtime da integração, não da sua máquina. Registe a origem observada pelo serviço recetor, o principal autenticado, o resultado e um pedido deliberadamente negado que tem de falhar.
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/pingExecute as mesmas duas sondas a partir da rede do próprio backend, para que a origem observada possa ser comparada com o que o runtime produziu. Um 200 seguido de um 401 ou 403 é a forma que quer; dois 200 significam que o caminho de negação não está realmente a ser aplicado.
Escreva a reversão antes de precisar dela: que entrada da lista de permitidos, credencial com nome ou ligação de saída alterou, quem é o proprietário e como restaurar o valor anterior. Depois feche o ciclo nomeando no ticket o chamador na nuvem e o caminho completo do serviço, para que ninguém reabra o mesmo assunto como um problema de VPN.