Apex-kall går frå Salesforce, ikkje frå VPN-en din

Den private API-en svarar i nettlesaren din i det laptopen koplar seg på VPN-en, så integrasjonen burde verke. Han verkar ikkje, fordi koden som gjer kallet, køyrer ein heilt annan stad. Apex køyrer på applikasjonsservarane til Salesforce, og ein serversideaktivitet i Marketing Cloud køyrer i køyretidsmiljøet til det produktet. Ingen av dei arvar tunnelen til laptopen din. Køyr dette som ein kort prosedyre: identifiser kalleparten, vel ein inngang som den kalleparten kan nå, kople vegen ende-til-ende, og verifiser deretter frå sjølve køyretidsmiljøet.

Skriv kallepartkortet før noka nettverksendring

Fyll ut fem felt og nekt å gjette på noko av dei. Utføringsproduktet og konteksten avgjer alt vidare, så start der og ikkje ved brannmuren til serveren.

Ei nettlesarfane og eit Apex-kall er to ulike klientar, og ein fungerande nettlesar beviser berre at det finst ein veg frå skrivebordet ditt. Viss køyretidsfeltet seier Apex, er det relevante spørsmålet kva adresser Salesforce går ut frå, ikkje kva adresser laptopen din har. Difor kan ein tunnel som får API-et til å laste i ein nettlesar, la integrasjonen feile med same tidsavbrot som før. Kallepartkortet finst for å stoppe den feilen før nokon redigerer ein brannmur.

Vel inngangen kalleparten faktisk kan bruke

Båe designa er legitime, og dei løyser ulike problem. Det fyrste er ein medviten offentleg inngang: ein HTTPS API-gateway eller ei integrasjonsteneste som autentiserer kalleparten, brukar snevre løyve og held ei verna tilkopling til det private backendet. Det er ikkje det same som å eksponere kvar backend-teneste eller videresende ein administrasjonsport til internett.

Det andre er ei kvalifisert privat tilkopling. dokumentasjonen til Salesforce for utgåande Private Connect skildrar ruting av støtta kall gjennom ein Outbound Network Connection bunden til ein namngjeven credential, over det definerte AWS PrivateLink-oppsettet. Funksjonen har avgrensingar på utgåve, lisens og produkt, så stadfest at organisasjonen kvalifiserer før du designar rundt han.

Ingen av designa er ein OpenVPN-klient installert inne i Salesforce, og den eldre påstanden om at kvar integrasjon må nå eit offentleg backend, er for brei der ei støtta privat tilkopling passar. Vel den køyretidsmiljøet støttar, og fullfør deretter vegen til det verkelege API-et: eit AWS-endepunkt kjenner ikkje den lokale ressursen din og arvar ikkje ruta til laptopen din. DNS, backend-ruting, tilgangspolicy og svartrafikk må alle følgje arkitekturen du valde. Ein halvferdig privat veg feilar på ein måte som ser nøyaktig ut som eit autentiseringsproblem.

Kople den private vegen ende-til-ende

Arbeid utover frå API-et og stopp ved fyrste hol. Stadfest at backendet svarar lokalt, deretter at det private endepunktet når det, og så at den namngjevne credentialen og den utgåande tilkoplinga hans peikar på det endepunktet.

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

Den fyrste kommandoen beviser at backendet er friskt innanfrå det private nettverket, den andre viser kva namnet løyser seg til, og den tredje utfører eit kall frå det verkelege Salesforce-køyretidsmiljøet. Ein 200 frå den fyrste og ein feil frå den tredje isolerer holet til vegen eller credentialen framfor tenesta.

Hald omfanget til identiteten presist medan du koplar. Ein namngjeven credential reparerer ikkje eit utilgjengeleg endepunkt åleine, fordi credentialen og den private tilkoplinga er skylde innstillingar med kvar si oppgåve. Ei IP-løyveliste snevrar inn nettverkstilgang og er ikkje ein API-credential, så hald på vanleg TLS-validering og tenesta sin eigen autentisering og rotasjon. Viss ein test berre lukkast etter at du slår av sertifikatkontrollen, har du funne eit vertsnamnproblem framfor eit vegproblem, og sertifikatet må framleis stemme.

Verifiser frå køyretidsmiljøet, og registrer deretter tilbakerullinga

Godta ein ufarleg tillaten førespurnad frå køyretidsmiljøet til integrasjonen, ikkje frå maskinen din. Registrer den observerte kjelda til tenesta som tek imot, den autentiserte principalen, resultatet og éin medvite avvist førespurnad som må feile.

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

Køyr dei same to prøvane frå backendet sitt eige nettverk slik at den observerte kjelda kan samanliknast med det køyretidsmiljøet produserte. Ein 200 etterfylgd av 401 eller 403 er forma du vil ha; to 200 betyr at avvisningsvegen ikkje faktisk blir handheva.

Skriv tilbakerullinga før du treng henne: kva løyvelisteoppføring, namngjeven credential eller utgåande tilkopling du endra, kven som eig henne, og korleis den førre verdien blir gjenoppretta. Lukk deretter løkka ved å namngje skykalleparten og heile tenestevegen i saka, slik at ingen opnar same sak på nytt som eit VPN-problem.