Klici Apex odhajajo iz Salesforcea, ne iz vašega VPN
VPN na prenosniku da vašemu brskalniku pot, ne Apexu ali Marketing Cloudu. Ujemite dejanskega klicatelja z javnim prehodom ali kvalificirano zasebno povezavo.
Zasebni API odgovori v brskalniku v trenutku, ko se prenosnik pridruži VPN, zato bi integracija morala delovati. Ne deluje, ker se koda, ki izvede klic, izvaja povsem drugje. Apex se izvaja na aplikacijskih strežnikih Salesforcea, strežniška dejavnost v Marketing Cloudu pa v izvajalnem okolju tega izdelka. Nobeno od tega ne podeduje predora vašega prenosnika. Izvedite to kot kratek postopek: prepoznajte klicatelja, izberite vhod, ki ga ta klicatelj lahko doseže, povežite pot od začetka do konca in nato preverite iz samega izvajalnega okolja.
Napišite kartico klicatelja pred vsako spremembo omrežja
Izpolnite pet polj in zavrnite ugibanje katerega koli od njih. Izdelek izvajanja in kontekst odločata o vsem nadaljnjem, zato začnite tam in ne pri požarnem zidu strežnika.
| 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? |
Zavihek brskalnika in klic Apex sta dva različna odjemalca, delujoč brskalnik pa dokazuje le, da pot z vaše mize obstaja. Če polje izvajalnega okolja pravi Apex, je relevantno vprašanje, s katerih naslovov Salesforce odhaja, ne kateri naslovi so na vašem prenosniku. Zato lahko predor, ki poskrbi, da se API naloži v brskalniku, pusti integracijo v napaki z enako časovno omejitvijo kot prej. Kartica klicatelja obstaja zato, da ustavi to napako, preden kdo uredi požarni zid.
Izberite vhod, ki ga klicatelj resnično lahko uporabi
Obe zasnovi sta legitimni in rešujeta različne težave. Prva je namerni javni vhod: prehod API prek HTTPS ali integracijska storitev, ki overi klicatelja, uporabi ozka dovoljenja in vzdržuje zaščiteno povezavo z zasebnim backendom. To ni isto kot razkriti vsako storitev backend ali preusmeriti upravljalna vrata v internet.
Druga je kvalificirana zasebna povezava. Dokumentacija odhodnega Private Connect pri Salesforceu opisuje usmerjanje podprtih klicev prek Outbound Network Connection, vezane na imenovane poverilnice, po njegovi določeni ureditvi AWS PrivateLink. Funkcija ima omejitve izdaje, licence in izdelka, zato pred načrtovanjem okoli nje potrdite, da organizacija izpolnjuje pogoje.
Nobena zasnova ni odjemalec OpenVPN, nameščen znotraj Salesforcea, in starejša trditev, da mora vsaka integracija doseči javni backend, je preširoka povsod, kjer ustreza podprta zasebna povezava. Izberite tisto, kar izvajalno okolje podpira, in nato dokončajte pot do pravega API-ja: končna točka AWS ne pozna vašega lokalnega vira in ne podeduje poti vašega prenosnika. DNS, usmerjanje backend, politika dostopa in odgovorni promet morajo slediti arhitekturi, ki ste jo izbrali. Napol zgrajena zasebna pot odpove tako, da je videti natanko kot težava z overjanjem.
Povežite zasebno pot od začetka do konca
Delajte od API-ja navzven in se ustavite pri prvi vrzeli. Potrdite, da backend odgovarja lokalno, nato da zasebna končna točka doseže do njega, in nato da imenovane poverilnice in njihova odhodna povezava ciljajo to končno točko.
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 integrationPrvi ukaz dokazuje, da je backend zdrav od znotraj zasebnega omrežja, drugi pokaže, v kaj se ime razreši, tretji pa izvede klic iz pravega izvajalnega okolja Salesforce. 200 s prvega in neuspeh s tretjega izolirata vrzel na pot ali v poverilnicah, ne v storitvi.
Med povezovanjem ohranjajte obseg identitete natančen. Imenovane poverilnice same ne popravijo nedosegljive končne točke, ker sta poverilnica in zasebna povezava povezani nastavitvi z ločenima nalogama. Seznam dovoljenih IP-jev zožuje omrežni sprejem in ni poverilnica API, zato ohranite običajno preverjanje TLS in lastni postopek overjanja ter rotacije storitve. Če test uspe šele po tem, ko izklopite preverjanje potrdila, ste našli težavo z imenom gostitelja in ne s potjo, potrdilo pa se mora še vedno ujemati.
Preverite iz izvajalnega okolja in nato zabeležite razveljavitev
Sprejmite neškodljivo dovoljeno zahtevo iz izvajalnega okolja integracije, ne s svojega računalnika. Zabeležite opaženi vir storitve, ki prejme zahtevo, overjenega subjekta, rezultat in eno namerno zavrnjeno zahtevo, ki mora spodleteti.
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/pingZaženite isti dve sondi iz lastnega omrežja backenda, da bo opaženi vir mogoče primerjati s tistim, kar je ustvarilo izvajalno okolje. 200, ki mu sledi 401 ali 403, je oblika, ki jo želite; dva 200 pomenita, da se pot zavrnitve v resnici ne uveljavlja.
Napišite razveljavitev, preden jo potrebujete: kateri vnos na seznamu dovoljenih, imenovane poverilnice ali odhodno povezavo ste spremenili, kdo jo ima v lasti in kako obnoviti prejšnjo vrednost. Nato sklenite zanko tako, da v zahtevku navedete klicatelja v oblaku in celotno pot storitve, da nihče ne odpre iste zadeve znova kot težave z VPN.