Apex-vokoj eliras el Salesforce, ne el via VPN
Tekkomputila VPN donas al via retumilo vojon, ne al Apex aŭ Marketing Cloud. Kunigu la realan vokanton al publika enirejo aŭ al kvalifikita privata konekto.
La privata API respondas en via retumilo en la momento, kiam la tekkomputilo aliĝas al la VPN, do la integriĝo devus funkcii. Ĝi ne funkcias, ĉar la kodo, kiu faras la vokon, ruliĝas tute aliloke. Apex ruliĝas sur la aplikaj serviloj de Salesforce, kaj servilflanka aktiveco en Marketing Cloud ruliĝas en la rulmedio de tiu produkto. Neniu el ili heredas la tunelon de via tekkomputilo. Plenumu tion kiel mallongan proceduron: identigu la vokanton, elektu enirejon, kiun tiu vokanto povas atingi, kunligu la vojon de komenco ĝis fino, kaj poste kontrolu el la rulmedio mem.
Skribu la vokanto-karton antaŭ iu ajn reta ŝanĝo
Plenigu kvin kampojn kaj rifuzu diveni iun ajn el ili. La plenumprodukto kaj la kunteksto decidas ĉion malsupren, do komencu tie, ne ĉe la fajroŝirmilo de la servilo.
| 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? |
Retumila langeto kaj Apex-voko estas du malsamaj klientoj, kaj funkcianta retumilo pruvas nur, ke ekzistas vojo de via skribotablo. Se la rulmedia kampo diras Apex, la koncerna demando estas, el kiuj adresoj Salesforce eliras, ne kiujn adresojn havas via tekkomputilo. Tial tunelo, kiu igas la API-on ŝargiĝi en retumilo, povas lasi la integriĝon malsukcesi kun la sama tempolimo kiel antaŭe. La vokanto-karto ekzistas por haltigi tiun eraron antaŭ ol iu redaktos fajroŝirmilon.
Elektu la enirejon, kiun la vokanto efektive povas uzi
Ambaŭ dezajnoj estas legitimaj, kaj ili solvas malsamajn problemojn. La unua estas intenca publika enirejo: HTTPS-API-enirejo aŭ integriĝa servo, kiu aŭtentikigas la vokanton, aplikas mallarĝajn permesojn kaj tenas protektitan konekton al la privata malantaŭaĵo. Tio ne samas kiel elmeti ĉiun malantaŭaĵan servon aŭ plusendi administran pordon al la interreto.
La dua estas kvalifikita privata konekto. La dokumentaro de Salesforce pri elira Private Connect priskribas enkursigon de subtenataj vokoj tra Outbound Network Connection ligita al nomita akreditaĵo, laŭ sia difinita AWS PrivateLink-aranĝo. La funkcio havas limojn pri eldono, permesilo kaj produkto, do konfirmu, ke la organizo kvalifikiĝas antaŭ ol dezajni ĉirkaŭ ĝi.
Neniu el la dezajnoj estas OpenVPN-kliento instalita ene de Salesforce, kaj la pli malnova aserto, ke ĉiu integriĝo devas atingi publikan malantaŭaĵon, tro larĝas kie subtenata privata konekto taŭgas. Elektu la solvon, kiun la rulmedio subtenas, kaj poste finu la vojon al la reala API: AWS-finpunkto ne konas vian surlokan rimedon kaj ne heredas la itineron de via tekkomputilo. DNS, malantaŭaĵa enkursigo, alirpolitiko kaj responda trafiko ĉiuj devas sekvi la arkitekturon, kiun vi elektis. Duonkonstruita privata vojo malsukcesas tiel, ke ĝi aspektas precize kiel aŭtentikiga problemo.
Kunligu la privatan vojon de komenco ĝis fino
Laboru eksteren de la API kaj haltu ĉe la unua manko. Konfirmu, ke la malantaŭaĵo respondas loke, poste ke la privata finpunkto atingas ĝin, kaj poste ke la nomita akreditaĵo kaj ĝia elira konekto celas tiun finpunkton.
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 integrationLa unua komando pruvas, ke la malantaŭaĵo sanas el la interno de la privata reto, la dua montras, al kio la nomo solviĝas, kaj la tria plenumas vokon el la reala Salesforce-rulmedio. 200 el la unua kaj malsukceso el la tria izolas la mankon al la vojo aŭ la akreditaĵo, ne al la servo.
Tenu la identecan amplekson preciza dum vi kunligas. Nomita akreditaĵo ne riparas sole atingeblan finpunkton, ĉar la akreditaĵo kaj la privata konekto estas rilataj agordoj kun apartaj taskoj. IP-permeslisto mallarĝigas retan akcepton kaj ne estas API-akreditaĵo, do konservu normalan TLS-kontrolon kaj la propran aŭtentikigan kaj rotacian procezon de la servo. Se testo sukcesas nur post kiam vi malŝaltis la atestilan kontrolon, vi trovis gastignoman problemon anstataŭ vojan problemon, kaj la atestilo ankoraŭ devas kongrui.
Kontrolu el la rulmedio, poste registru la retroiron
Akceptu sendanĝeran permesitan peton el la integriĝa rulmedio, ne el via maŝino. Registru la observitan fonton de la ricevanta servo, la aŭtentikigitan principal, la rezulton kaj unu intence rifuzitan peton, kiu devas malsukcesi.
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/pingRulu la samajn du sondojn el la propra reto de la malantaŭaĵo, por ke la observita fonto kompareblu kun tio, kion produktis la rulmedio. 200 sekvata de 401 aŭ 403 estas la formo, kiun vi volas; du 200 signifas, ke la rifuza vojo ne estas efektive plenumata.
Skribu la retroiron antaŭ ol vi bezonos ĝin: kiun permeslistan eron, nomitan akreditaĵon aŭ eliran konekton vi ŝanĝis, kiu posedas ĝin, kaj kiel restarigi la antaŭan valoron. Poste fermu la cirklon nomante la nuban vokanton kaj la kompletan servan vojon en la bileto, por ke neniu remalfermu la saman aferon kiel VPN-problemon.