Apex-callouts vertrekken vanuit Salesforce, niet vanuit je VPN

De private API antwoordt in je browser op het moment dat de laptop lid wordt van de VPN, dus de integratie zou moeten werken. Dat doet ze niet, omdat de code die de callout doet ergens anders draait, heel ergens anders. Apex draait op de applicatieservers van Salesforce, en een server-side activiteit in Marketing Cloud draait in de runtime van dat product. Geen van beide erft de tunnel van je laptop. Voer dit uit als een korte procedure: identificeer de aanroeper, kies een ingang die die aanroeper kan bereiken, bedraad het pad van begin tot eind en verifieer daarna vanuit de runtime zelf.

Schrijf de aanroeperkaart voordat je iets aan het netwerk verandert

Vul vijf velden in en weiger er ook maar één te raden. Het uitvoeringsproduct en de context bepalen alles daarna, dus begin daar en niet bij de firewall van de server.

Een browsertab en een Apex-callout zijn twee verschillende clients, en een werkende browser bewijst alleen dat er een pad vanaf je bureau bestaat. Als het runtime-veld Apex zegt, is de relevante vraag vanaf welke adressen Salesforce uitgaat, niet welke adressen je laptop heeft. Daarom kan een tunnel waardoor de API in een browser laadt, de integratie laten falen met dezelfde time-out als voorheen. De aanroeperkaart bestaat om die fout te stoppen voordat iemand een firewall bewerkt.

Kies de ingang die de aanroeper werkelijk kan gebruiken

Beide ontwerpen zijn legitiem en lossen verschillende problemen op. Het eerste is een bewuste openbare ingang: een HTTPS API-gateway of integratiedienst die de aanroeper authenticeert, nauwe rechten toepast en een beschermde verbinding met de private backend houdt. Dat is niet hetzelfde als elke backendservice blootleggen of een beheerpoort naar het internet doorsturen.

Het tweede is een gekwalificeerde privéverbinding. De documentatie over uitgaande Private Connect van Salesforce beschrijft het routeren van ondersteunde callouts via een Outbound Network Connection die aan een genoemde credential is gebonden, over de gedefinieerde AWS PrivateLink-opstelling. De functie heeft beperkingen qua editie, licentie en product, dus bevestig dat de organisatie kwalificeert voordat je eromheen ontwerpt.

Geen van beide ontwerpen is een OpenVPN-client die in Salesforce is geïnstalleerd, en de oudere bewering dat elke integratie een openbare backend moet bereiken is te breed waar een ondersteunde privéverbinding past. Kies degene die de runtime ondersteunt en maak daarna het pad naar de echte API af: een AWS-endpoint kent je on-premises resource niet en erft de route van je laptop niet. DNS, backend-routering, toegangsbeleid en antwoordverkeer moeten allemaal de architectuur volgen die je koos. Een halfgebouwd privépad faalt op een manier die er precies uitziet als een authenticatieprobleem.

Bedraad het privépad van begin tot eind

Werk vanaf de API naar buiten en stop bij de eerste leemte. Bevestig dat de backend lokaal antwoordt, dan dat het private endpoint hem bereikt, en dan dat de genoemde credential en zijn uitgaande verbinding op dat endpoint mikken.

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

De eerste opdracht bewijst dat de backend gezond is van binnenuit het private netwerk, de tweede laat zien waar de naam naar resolvet, en de derde voert een callout uit vanuit de echte Salesforce-runtime. Een 200 van de eerste en een fout van de derde isoleren de leemte naar het pad of de credential, niet naar de dienst.

Houd de scope van de identiteit nauwkeurig tijdens het bedraden. Een genoemde credential repareert een onbereikbaar endpoint niet op eigen kracht, omdat de credential en de privéverbinding verwante instellingen met aparte taken zijn. Een IP-allowlist vernauwt netwerktoelating en is geen API-credential, dus behoud normale TLS-validatie en het eigen authenticatie- en rotatieproces van de dienst. Als een test pas slaagt nadat je de certificaatcontrole hebt uitgeschakeld, heb je een hostnaamprobleem gevonden in plaats van een padprobleem, en het certificaat moet nog steeds kloppen.

Verifieer vanuit de runtime en leg daarna de terugdraai vast

Accepteer een onschadelijk toegestaan verzoek vanuit de runtime van de integratie, niet vanaf je eigen machine. Leg de waargenomen bron van de ontvangende dienst vast, de geauthenticeerde principal, het resultaat en één bewust geweigerd verzoek dat moet falen.

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

Voer dezelfde twee probes uit vanaf het eigen netwerk van de backend, zodat de waargenomen bron kan worden vergeleken met wat de runtime produceerde. Een 200 gevolgd door een 401 of 403 is de vorm die je wilt; twee 200's betekenen dat het weigerpad niet echt wordt afgedwongen.

Schrijf de terugdraai voordat je hem nodig hebt: welke allowlist-vermelding, genoemde credential of uitgaande verbinding je hebt gewijzigd, wie hem bezit en hoe de vorige waarde wordt hersteld. Sluit dan de lus door in het ticket de cloud-aanroeper en het volledige servicepad te benoemen, zodat niemand dezelfde kwestie opnieuw opent als een VPN-probleem.