Apex-Callouts gehen von Salesforce aus, nicht von Ihrem VPN

Die private API antwortet in Ihrem Browser in dem Moment, in dem der Laptop dem VPN beitritt, die Integration sollte also funktionieren. Sie tut es nicht, weil der Code, der den Callout ausführt, ganz woanders läuft. Apex läuft auf den Anwendungsservern von Salesforce, und eine serverseitige Aktivität in Marketing Cloud läuft in der Laufzeitumgebung dieses Produkts. Keine von beiden erbt den Tunnel Ihres Laptops. Gehen Sie es als kurze Prozedur an: Aufrufer identifizieren, einen Eingang wählen, den dieser Aufrufer erreichen kann, den Pfad durchgängig verdrahten und dann aus der Laufzeitumgebung selbst prüfen.

Schreiben Sie die Aufruferkarte, bevor Sie am Netzwerk etwas ändern

Füllen Sie fünf Felder aus und weigern Sie sich, eines davon zu raten. Ausführungsprodukt und Kontext entscheiden über alles Weitere, beginnen Sie also dort und nicht bei der Firewall des Servers.

Ein Browser-Tab und ein Apex-Callout sind zwei verschiedene Clients, und ein funktionierender Browser beweist nur, dass es einen Weg von Ihrem Schreibtisch aus gibt. Wenn das Feld für die Laufzeitumgebung Apex sagt, lautet die relevante Frage, von welchen Adressen Salesforce ausgeht, nicht welche Adressen Ihr Laptop hat. Deshalb kann ein Tunnel, der die API im Browser laden lässt, die Integration mit demselben Timeout scheitern lassen wie zuvor. Die Aufruferkarte existiert, um diesen Fehler zu stoppen, bevor jemand eine Firewall bearbeitet.

Wählen Sie den Eingang, den der Aufrufer tatsächlich nutzen kann

Beide Designs sind legitim, und sie lösen unterschiedliche Probleme. Das erste ist ein bewusster öffentlicher Eingang: ein HTTPS-API-Gateway oder ein Integrationsdienst, der den Aufrufer authentifiziert, enge Berechtigungen anwendet und eine geschützte Verbindung zum privaten Backend hält. Das ist nicht dasselbe, wie jeden Backend-Dienst offenzulegen oder einen Verwaltungsport ins Internet weiterzuleiten.

Das zweite ist eine qualifizierte private Verbindung. Die Dokumentation zu Private Connect für ausgehende Verbindungen von Salesforce beschreibt, wie unterstützte Callouts über eine Outbound Network Connection, die an ein benanntes Credential gebunden ist, gemäß der definierten AWS-PrivateLink-Anordnung geleitet werden. Das Feature hat Einschränkungen bei Edition, Lizenz und Produkt, bestätigen Sie also die Eignung der Org, bevor Sie darauf aufbauen.

Keines der Designs ist ein in Salesforce installierter OpenVPN-Client, und die ältere Behauptung, jede Integration müsse ein öffentliches Backend erreichen, ist zu pauschal, wo eine unterstützte private Verbindung passt. Wählen Sie die Variante, die die Laufzeitumgebung unterstützt, und vervollständigen Sie dann den Pfad zur echten API: ein AWS-Endpunkt kennt Ihre lokale Ressource nicht und erbt nicht die Route Ihres Laptops. DNS, Backend-Routing, Zugriffsrichtlinie und Antwortverkehr müssen alle der gewählten Architektur folgen. Ein halb gebauter privater Pfad scheitert so, dass es genau wie ein Authentifizierungsproblem aussieht.

Verdrahten Sie den privaten Pfad durchgängig

Arbeiten Sie von der API nach außen und halten Sie bei der ersten Lücke an. Bestätigen Sie, dass das Backend lokal antwortet, dann dass der private Endpunkt es erreicht, und dann dass das benannte Credential und seine ausgehende Verbindung auf diesen Endpunkt zielen.

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

Der erste Befehl beweist, dass das Backend aus dem privaten Netz heraus gesund ist, der zweite zeigt, wohin der Name auflöst, und der dritte führt einen Callout aus der tatsächlichen Salesforce-Laufzeitumgebung aus. Ein 200 vom ersten und ein Fehler vom dritten isolieren die Lücke auf den Pfad oder das Credential statt auf den Dienst.

Halten Sie den Identitätsumfang beim Verdrahten präzise. Ein benanntes Credential repariert einen unerreichbaren Endpunkt nicht allein, weil Credential und private Verbindung verwandte Einstellungen mit getrennten Aufgaben sind. Eine IP-Allowlist verengt die Netzwerkzulassung und ist kein API-Credential, behalten Sie also die normale TLS-Validierung und den eigenen Authentifizierungs- und Rotationsprozess des Dienstes bei. Wenn ein Test erst gelingt, nachdem Sie die Zertifikatsprüfung deaktiviert haben, haben Sie ein Hostname-Problem statt eines Pfadproblems gefunden, und das Zertifikat muss weiterhin passen.

Prüfen Sie aus der Laufzeitumgebung und halten Sie dann das Rollback fest

Akzeptieren Sie eine harmlose erlaubte Anfrage aus der Laufzeitumgebung der Integration, nicht von Ihrem Rechner. Halten Sie die beobachtete Quelle des empfangenden Dienstes, den authentifizierten Principal, das Ergebnis und eine bewusst verweigerte Anfrage fest, die scheitern muss.

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

Führen Sie dieselben zwei Prüfungen aus dem eigenen Netz des Backends aus, damit die beobachtete Quelle mit dem verglichen werden kann, was die Laufzeitumgebung erzeugt hat. Ein 200 gefolgt von einem 401 oder 403 ist die gewünschte Form; zwei 200 bedeuten, dass der Verweigerungspfad nicht wirklich durchgesetzt wird.

Schreiben Sie das Rollback, bevor Sie es brauchen: welchen Allowlist-Eintrag, welches benannte Credential oder welche ausgehende Verbindung Sie geändert haben, wer sie besitzt und wie der vorherige Wert wiederhergestellt wird. Schließen Sie dann den Kreis, indem Sie den Cloud-Aufrufer und den vollständigen Dienstpfad im Ticket benennen, damit niemand dasselbe Problem erneut als VPN-Problem aufmacht.