Apex pozivi izlaze iz Salesforcea, a ne iz vašeg VPN-a
VPN na prijenosnom računaru daje vašem pregledniku put, ne Apex ili Marketing Cloud. Uskladite stvarnog pozivaoca s javnim pristupnikom ili kvalificiranom privatnom vezom.
Privatni API odgovara u vašem pregledniku onog trenutka kada se prijenosni računar pridruži VPN-u, pa bi integracija trebalo da radi. Ne radi, jer se kod koji upućuje poziv izvršava sasvim negdje drugdje. Apex se izvršava na aplikacijskim serverima Salesforcea, a serverska aktivnost u Marketing Cloudu u izvršnom okruženju tog proizvoda. Nijedno od njih ne nasljeđuje tunel vašeg prijenosnog računara. Provedite to kao kratku proceduru: identificirajte pozivaoca, odaberite ulaz do kojeg taj pozivalac može doći, povežite put od početka do kraja, a zatim provjerite iz samog izvršnog okruženja.
Napišite karticu pozivaoca prije bilo kakve mrežne promjene
Popunite pet polja i odbijte da bilo koje od njih pogađate. Proizvod izvršavanja i kontekst odlučuju o svemu nizvodno, 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š prijenosni računar. Zato tunel koji omogući da se API učita u pregledniku može ostaviti integraciju da pada s istim timeoutom kao prije. Kartica pozivaoca postoji da zaustavi tu grešku prije nego što iko uredi firewall.
Odaberite ulaz koji pozivalac zaista može koristiti
Dva dizajna su legitimna i rješavaju različite probleme. Prvi je namjerni javni ulaz: HTTPS API pristupnik ili integracijska usluga koja autentificira pozivaoca, primjenjuje uska ovlaštenja i drži zaštićenu vezu s privatnim backendom. To nije isto kao izlaganje svake backend usluge ili prosljeđivanje upravljačkog porta na internet.
Drugi je kvalificirana privatna veza. Salesforceova dokumentacija za odlazni Private Connect opisuje usmjeravanje podržanih poziva kroz Outbound Network Connection vezan za imenovane vjerodajnice, preko definiranog AWS PrivateLink rasporeda. Funkcija ima ograničenja izdanja, licence i proizvoda, pa potvrdite da organizacija ispunjava uslove prije 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 gdje 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 nasljeđuje rutu vašeg prijenosnog računara. DNS, usmjeravanje backenda, politika pristupa i povratni saobraćaj moraju slijediti 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 van i zaustavite se na prvoj praznini. Potvrdite da backend odgovara lokalno, zatim da privatni endpoint do njega dolazi, a onda da imenovane vjerodajnice 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 razrješava, a treća izvršava poziv iz stvarnog Salesforce izvršnog okruženja. 200 s prve i neuspjeh s treće izoluju prazninu u putu ili vjerodajnicama, a ne u usluzi.
Držite obim identiteta preciznim dok povezujete. Imenovane vjerodajnice same ne popravljaju nedostupan endpoint, jer su vjerodajnice i privatna veza povezana podešavanja s odvojenim zadacima. IP lista dozvoljenih adresa sužava mrežni pristup i nije API vjerodajnica, pa zadržite normalnu TLS provjeru i vlastiti proces autentifikacije i rotacije usluge. Ako test prolazi tek nakon što isključite provjeru certifikata, našli ste problem s imenom hosta, a ne s putem, i certifikat se i dalje mora podudarati.
Provjerite iz izvršnog okruženja, pa zabilježite vraćanje
Prihvatite bezopasan dozvoljen zahtjev iz izvršnog okruženja integracije, a ne sa svoje mašine. Zabilježite uočeni izvor usluge koja prima, autentificirani subjekt, rezultat i jedan namjerno odbijen zahtjev 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 dvije provjere 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 provodi.
Napišite vraćanje prije nego što vam zatreba: koji ste zapis liste dozvoljenih, imenovane vjerodajnice ili odlaznu vezu promijenili, ko to posjeduje i kako vratiti prethodnu vrijednost. 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.