Apex pozivi izlaze iz Salesforcea, a ne iz vašeg VPN-a
VPN na laptopu daje vašem pregledniku put, ne Apexu ili Marketing Cloudu. Uparite stvarnog pozivatelja s javnim pristupnikom ili kvalificiranom privatnom vezom.
Privatni API odgovara u vašem pregledniku onog trena kada se laptop pridruži VPN-u, pa bi integracija trebalo da radi. Ne radi, jer se kod koji upućuje poziv izvršava sasvim negde drugde. Apex se izvršava na aplikacionim serverima Salesforcea, a serverska aktivnost u Marketing Cloudu izvršava se u izvršnom okruženju tog proizvoda. Ni jedno od njih ne nasleđuje tunel vašeg laptopa. Spovedite to kao kratak postupak: identifikujte pozivaoca, odaberite ulaz do kojeg taj pozivalac može da dođe, povežite put od početka do kraja, pa zatim proverite iz samog izvršnog okruženja.
Napišite karticu pozivaoca pre bilo kakve mrežne promene
Popunite pet polja i odbijte da pogodite bilo koje od njih. Proizvod izvršavanja i kontekst odlučuju o svemu dalje, pa počnite odatle, a ne od firewall-a servera.
| 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? |
Kartica preglednika i Apex poziv su dva različita klijenta, a preglednik koji radi dokazuje samo da put postoji s vašeg stola. Ako polje izvršnog okruženja kaže Apex, relevantno pitanje je s kojih adresa Salesforce izlazi, a ne koje adrese ima vaš laptop. Zato tunel koji omogući da se API učita u pregledniku može ostaviti integraciju da pada s istim tajmautom kao pre. Kartica pozivaoca postoji da zaustavi tu grešku pre nego što neko uredi firewall.
Odaberite ulaz koji pozivalac zaista može koristiti
Oba dizajna su legitimna i rešavaju različite probleme. Prvi je namerni javni ulaz: HTTPS API pristupnik ili integraciona usluga koja autentifikuje pozivaoca, primenjuje uska ovlašćenja i drži zaštićenu vezu s privatnim backendom. To nije isto kao izlaganje svake backend usluge ili prosleđivanje upravljačkog porta na internet.
Drugi je kvalifikovana privatna veza. Salesforceova dokumentacija za odlazni Private Connect opisuje usmeravanje podržanih poziva kroz Outbound Network Connection vezan za imenovane akreditive, preko definisanog AWS PrivateLink rasporeda. Funkcija ima ograničenja izdanja, licence i proizvoda, pa potvrdite da organizacija ispunjava uslove pre nego što dizajnirate oko nje.
Nijedan dizajn nije OpenVPN klijent instaliran unutar Salesforcea, a starija tvrdnja da svaka integracija mora doći do javnog backenda preširoka je gde god podržana privatna veza odgovara. Odaberite ono što izvršno okruženje podržava, a zatim dovršite put do stvarnog API-ja: AWS endpoint ne poznaje vaš lokalni resurs i ne nasleđuje rutu vašeg laptopa. DNS, usmeravanje backenda, politika pristupa i povratni saobraćaj moraju slediti arhitekturu koju ste odabrali. Nedovršen privatni put pada na način koji izgleda tačno kao problem autentifikacije.
Povežite privatni put od početka do kraja
Radite od API-ja prema spolja i zaustavite se na prvoj praznini. Potvrdite da backend odgovara lokalno, zatim da privatni endpoint do njega dolazi, a onda da imenovani akreditivi i njihova odlazna veza ciljaju taj endpoint.
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 integrationPrva naredba dokazuje da je backend zdrav iz unutrašnjosti privatne mreže, druga pokazuje u šta se ime razrešava, a treća izvršava poziv iz stvarnog Salesforce izvršnog okruženja. 200 s prve i neuspeh s treće izoluju prazninu u putu ili akreditivima, a ne u usluzi.
Držite obim identiteta preciznim dok povezujete. Imenovani akreditivi sami ne popravljaju nedostupan endpoint, jer su akreditivi i privatna veza povezana podešavanja s odvojenim zadatacima. IP lista dozvoljenih adresa sužava mrežni pristup i nije API akreditiv, pa zadržite normalnu TLS proveru i sopstveni proces autentifikacije i rotacije usluge. Ako test prolazi tek nakon što isključite proveru sertifikata, našli ste problem s imenom hosta, a ne s putem, i sertifikat i dalje mora da se poklapa.
Proverite iz izvršnog okruženja, pa zabeležite vraćanje
Prihvatite bezopasan dozvoljen zahtev iz izvršnog okruženja integracije, a ne sa svog stroja. Zabeležite uočeni izvor usluge koja prima, autentifikovani subjekt, rezultat i jedan namerno odbijen zahtev koji mora pasti.
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/pingPokrenite iste dve provere s vlastite mreže backenda kako bi se uočeni izvor mogao uporediti s onim što je izvršno okruženje proizvelo. 200 pa 401 ili 403 je oblik koji želite; dva 200 znače da se put odbijanja zapravo ne sprovodi.
Napišite vraćanje pre nego što vam zatreba: koji ste zapis liste dozvoljenih, imenovane akreditive ili odlaznu vezu promenili, kome pripada i kako vratiti prethodnu vrednost. Zatim zatvorite krug tako što ćete u tiketu imenovati pozivaoca u oblaku i puni put usluge, da niko isti problem ne otvori ponovo kao VPN problem.