Apex pozivi izlaze iz Salesforcea, a ne iz vašeg VPN-a
VPN na prijenosnom računalu 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 trenutka kada se prijenosno računalo pridruži VPN-u, pa bi integracija trebala raditi. Ne radi, jer se kod koji upućuje poziv izvršava posve drugdje. Apex se izvršava na aplikacijskim poslužiteljima Salesforcea, a poslužiteljska aktivnost u Marketing Cloudu izvršava se u izvršnom okruženju tog proizvoda. Nijedno od njih ne nasljeđuje tunel vašeg prijenosnog računala. Provedite to kao kratak postupak: identificirajte pozivatelja, odaberite ulaz do kojeg taj pozivatelj može doći, povežite put od početka do kraja, a zatim provjerite iz samog izvršnog okruženja.
Napišite karticu pozivatelja prije bilo kakve mrežne promjene
Ispunite pet polja i odbijte pogoditi bilo koje od njih. Proizvod izvršavanja i kontekst odlučuju o svemu daljnjem, pa počnite odatle, a ne od vatrozida poslužitelja.
| 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 dva su različita klijenta, a preglednik koji radi dokazuje samo da put postoji s vašeg radnog stola. Ako polje izvršnog okruženja kaže Apex, relevantno je pitanje s kojih adresa Salesforce izlazi, a ne koje adrese ima vaše prijenosno računalo. Zato tunel koji omogući da se API učita u pregledniku može ostaviti integraciju da pada s istim istekom vremena kao prije. Kartica pozivatelja postoji da zaustavi tu pogrešku prije nego što itko uredi vatrozid.
Odaberite ulaz koji pozivatelj doista može koristiti
Oba su dizajna legitimna i rješavaju različite probleme. Prvi je namjerni javni ulaz: HTTPS API pristupnik ili integracijska usluga koja autentificira pozivatelja, 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 uz imenovane vjerodajnice, preko definiranog AWS PrivateLink rasporeda. Značajka ima ograničenja izdanja, licence i proizvoda, pa potvrdite da organizacija ispunjava uvjete 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čunala. DNS, usmjeravanje backenda, pravila pristupa i povratni promet moraju slijediti arhitekturu koju ste odabrali. Nedovršen privatni put pada na način koji izgleda toč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 dolazi do njega, 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 što 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 izoliraju prazninu na putu ili vjerodajnicama, a ne u usluzi.
Držite opseg identiteta preciznim dok povezujete. Imenovane vjerodajnice same ne popravljaju nedostupan endpoint, jer su vjerodajnice i privatna veza povezane postavke s odvojenim zadaćama. Popis dopuštenih IP adresa sužava mrežni pristup i nije API vjerodajnica, pa zadržite uobičajenu TLS provjeru i vlastiti proces autentifikacije i rotacije usluge. Ako test prolazi tek nakon što isključite provjeru certifikata, pronaš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 dopušten zahtjev iz izvršnog okruženja integracije, a ne sa svog stroja. 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 usporediti s onim što je izvršno okruženje proizvelo. 200 pa 401 ili 403 oblik je 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 popisa dopuštenih, imenovane vjerodajnice ili odlaznu vezu promijenili, kome pripada i kako vratiti prethodnu vrijednost. Zatim zatvorite krug tako što ćete u kartici imenovati pozivatelja u oblaku i puni put usluge, da nitko isti problem ne otvori ponovno kao VPN problem.