Apex izsaukumi nāk no Salesforce, nevis no jūsu VPN
Klēpjdatora VPN dod jūsu pārlūkam ceļu, nevis Apex vai Marketing Cloud. Saskaņojiet īsto izsaucēju ar publisku vārteju vai kvalificētu privātu savienojumu.
Privātais API atbild jūsu pārlūkā tajā mirklī, kad klēpjdators pievienojas VPN, tāpēc integrācijai būtu jādarbojas. Tā nedarbojas, jo kods, kas veic izsaukumu, darbojas pavisam citur. Apex darbojas Salesforce lietotņu serveros, bet Marketing Cloud servera puses darbība darbojas šī produkta izpildlaika vidē. Neviens no tiem nemanto jūsu klēpjdatora tuneli. Veiciet to kā īsu procedūru: identificējiet izsaucēju, izvēlieties ieeju, kuru šis izsaucējs var sasniegt, savienojiet ceļu no sākuma līdz galam un pēc tam pārbaudiet no pašas izpildlaika vides.
Uzrakstiet izsaucēja kartīti pirms jebkādām tīkla izmaiņām
Aizpildiet piecus laukus un atsakieties minēt jebkuru no tiem. Izpildes produkts un konteksts nosaka visu turpmāko, tāpēc sāciet tur, nevis pie servera ugunsmūra.
| 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? |
Pārlūka cilne un Apex izsaukums ir divi dažādi klienti, un strādājošs pārlūks pierāda tikai to, ka no jūsu rakstāmgalda pastāv ceļš. Ja izpildlaika lauks saka Apex, būtisks jautājums ir, no kurām adresēm Salesforce iziet, nevis kādas adreses ir jūsu klēpjdatoram. Tāpēc tunelis, kas liek API ielādēties pārlūkā, var atstāt integrāciju neveiksmīgu ar to pašu taimautu kā iepriekš. Izsaucēja kartīte ir domāta, lai apturētu šo kļūdu pirms kāds rediģē ugunsmūri.
Izvēlieties ieeju, kuru izsaucējs patiešām var izmantot
Abi risinājumi ir likumīgi, un tie risina dažādas problēmas. Pirmais ir apzināta publiska ieeja: HTTPS API vārteja vai integrācijas pakalpojums, kas autentificē izsaucēju, piemēro šauras atļaujas un uztur aizsargātu savienojumu ar privāto backend. Tas nav tas pats, kas atklāt katru backend pakalpojumu vai pārsūtīt pārvaldības portu uz internetu.
Otrais ir kvalificēts privāts savienojums. Salesforce izejošā Private Connect dokumentācija apraksta atbalstīto izsaukumu maršrutēšanu caur Outbound Network Connection, kas piesaistīts nosauktam akreditācijas datu kopumam, saskaņā ar tā noteikto AWS PrivateLink izkārtojumu. Funkcijai ir izdevuma, licences un produkta ierobežojumi, tāpēc pirms projektēšanas ap to pārliecinieties, ka organizācija atbilst nosacījumiem.
Neviens no risinājumiem nav Salesforce iekšienē instalēts OpenVPN klients, un vecākais apgalvojums, ka katrai integrācijai jāsasniedz publisks backend, ir pārāk plašs tur, kur der atbalstīts privāts savienojums. Izvēlieties to, ko atbalsta izpildlaika vide, un pēc tam pabeidziet ceļu līdz īstajam API: AWS galapunkts nezina jūsu vietējo resursu un nemanto jūsu klēpjdatora maršrutu. DNS, backend maršrutēšana, piekļuves politika un atbildes trafiks visiem jāseko jūsu izvēlētajai arhitektūrai. Pusuzbūvēts privāts ceļš neizdodas tā, ka izskatās tieši kā autentifikācijas problēma.
Savienojiet privāto ceļu no sākuma līdz galam
Strādājiet no API uz āru un apstājieties pie pirmās nepilnības. Apstipriniet, ka backend atbild lokāli, pēc tam ka privātais galapunkts to sasniedz, un tad ka nosauktais akreditācijas datu kopums un tā izejošais savienojums mērķē uz šo galapunktu.
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 integrationPirmā komanda pierāda, ka backend ir vesels no privātā tīkla iekšpuses, otrā parāda, uz ko atrisinās nosaukums, un trešā izpilda izsaukumu no īstās Salesforce izpildlaika vides. 200 no pirmās un neveiksme no trešās izolē nepilnību ceļā vai akreditācijas datos, nevis pakalpojumā.
Savienojot saglabājiet precīzu identitātes apjomu. Nosaukts akreditācijas datu kopums pats nesalabo nesasniedzamu galapunktu, jo akreditācijas dati un privātais savienojums ir saistīti iestatījumi ar atsevišķiem uzdevumiem. IP atļauto saraksts sašaurina tīkla uzņemšanu un nav API akreditācijas dati, tāpēc saglabājiet parasto TLS validāciju un pakalpojuma paša autentifikācijas un rotācijas procesu. Ja tests izdodas tikai pēc sertifikāta pārbaudes izslēgšanas, jūs esat atraduši resursdatora nosaukuma problēmu, nevis ceļa problēmu, un sertifikātam joprojām jāsakrīt.
Pārbaudiet no izpildlaika vides un pēc tam fiksējiet atritināšanu
Pieņemiet nekaitīgu atļautu pieprasījumu no integrācijas izpildlaika vides, nevis no savas mašīnas. Fiksējiet saņēmējpakaļpojuma novēroto avotu, autentificēto subjektu, rezultātu un vienu apzināti noraidītu pieprasījumu, kuram jāneizdodas.
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/pingPalaidiet tos pašus divus pārbaudījumus no backend paša tīkla, lai novēroto avotu varētu salīdzināt ar to, ko radīja izpildlaika vide. 200, kam seko 401 vai 403, ir vēlamā forma; divi 200 nozīmē, ka noraidīšanas ceļš faktiski netiek piemērots.
Uzrakstiet atritināšanu pirms tā jums nepieciešama: kuru atļauto saraksta ierakstu, nosauktu akreditācijas datu kopumu vai izejošo savienojumu jūs mainījāt, kam tas pieder un kā atjaunot iepriekšējo vērtību. Pēc tam aizveriet loku, biļetē nosaucot mākoņa izsaucēju un pilnu pakalpojuma ceļu, lai neviens to pašu jautājumu neatvērtu vēlreiz kā VPN problēmu.