Las callouts de Apex salen de Salesforce, no de tu VPN

La API privada responde en tu navegador en el momento en que el portátil se une a la VPN, así que la integración debería funcionar. No funciona, porque el código que hace la llamada se ejecuta en otro lugar por completo. Apex se ejecuta en los servidores de aplicaciones de Salesforce, y una actividad del lado del servidor de Marketing Cloud se ejecuta en el entorno de ejecución de ese producto. Ninguno de los dos hereda el túnel de tu portátil. Abórdalo como un procedimiento corto: identifica al llamador, elige una entrada que ese llamador pueda alcanzar, conecta la ruta de extremo a extremo y luego verifica desde el propio entorno de ejecución.

Escribe la ficha del llamador antes de cualquier cambio de red

Rellena cinco campos y niégate a adivinar ninguno. El producto de ejecución y el contexto deciden todo lo demás, así que empieza ahí y no por el cortafuegos del servidor.

Una pestaña del navegador y una llamada de Apex son dos clientes distintos, y un navegador que funciona solo demuestra que existe una ruta desde tu escritorio. Si el campo del entorno de ejecución dice Apex, la pregunta pertinente es de qué direcciones sale Salesforce, no qué direcciones tiene tu portátil. Por eso un túnel que hace que la API cargue en el navegador puede dejar la integración fallando con el mismo tiempo de espera que antes. La ficha del llamador existe para detener ese error antes de que alguien edite un cortafuegos.

Elige la entrada que el llamador puede usar de verdad

Los dos diseños son legítimos y resuelven problemas distintos. El primero es una entrada pública deliberada: una puerta de enlace de API por HTTPS o un servicio de integración que autentica al llamador, aplica permisos estrechos y mantiene una conexión protegida con el backend privado. Eso no es lo mismo que exponer todos los servicios del backend o reenviar un puerto de gestión a internet.

El segundo es una conexión privada cualificada. La documentación de Private Connect saliente de Salesforce describe el enrutamiento de las llamadas admitidas mediante una Outbound Network Connection vinculada a una credencial con nombre, sobre su disposición definida de AWS PrivateLink. La función tiene restricciones de edición, licencia y producto, así que confirma que la organización cumple los requisitos antes de diseñar en torno a ella.

Ninguno de los dos diseños es un cliente OpenVPN instalado dentro de Salesforce, y la vieja afirmación de que toda integración debe alcanzar un backend público es demasiado amplia allí donde encaja una conexión privada admitida. Elige la que admita el entorno de ejecución y luego completa la ruta hasta la API real: un punto de conexión de AWS no conoce tu recurso local ni hereda la ruta de tu portátil. El DNS, el enrutamiento del backend, la política de acceso y el tráfico de respuesta tienen que seguir la arquitectura que elegiste. Una ruta privada a medio construir falla de una forma que parece exactamente un problema de autenticación.

Conecta la ruta privada de extremo a extremo

Trabaja desde la API hacia fuera y detente en el primer hueco. Confirma que el backend responde en local, luego que el punto de conexión privado llega a él y después que la credencial con nombre y su conexión saliente 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 integration

El primer comando demuestra que el backend está sano desde dentro de la red privada, el segundo muestra a qué resuelve el nombre y el tercero ejecuta una llamada desde el entorno de ejecución real de Salesforce. Un 200 del primero y un fallo del tercero aíslan el hueco en la ruta o en la credencial, no en el servicio.

Mantén preciso el alcance de la identidad mientras conectas. Una credencial con nombre no repara por sí sola un punto de conexión inalcanzable, porque la credencial y la conexión privada son ajustes relacionados con tareas separadas. Una lista de IP permitidas estrecha la admisión de red y no es una credencial de API, así que conserva la validación TLS normal y el proceso propio de autenticación y rotación del servicio. Si una prueba solo pasa después de desactivar la comprobación del certificado, has encontrado un problema de nombre de host y no de ruta, y el certificado sigue teniendo que coincidir.

Verifica desde el entorno de ejecución y luego registra la reversión

Acepta una petición permitida e inocua desde el entorno de ejecución de la integración, no desde tu máquina. Registra el origen observado por el servicio receptor, el principal autenticado, el resultado y una 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/ping

Ejecuta las mismas dos sondas desde la red del propio backend para que el origen observado pueda compararse con lo que produjo el entorno de ejecución. Un 200 seguido de un 401 o un 403 es la forma que quieres; dos 200 significan que la ruta de denegación no se aplica de verdad.

Escribe la reversión antes de necesitarla: qué entrada de la lista permitida, credencial con nombre o conexión saliente cambiaste, quién la posee y cómo restaurar el valor anterior. Luego cierra el círculo nombrando al llamador en la nube y la ruta completa del servicio en el ticket, para que nadie reabra el mismo asunto como un problema de VPN.