API ya kibinafsi hujibu katika kivinjari chako mara kompyuta inapoungana na VPN, kwa hiyo muunganisho unapaswa kufanya kazi. Haufanyi kazi, kwa sababu msimbo unaofanya mwito unaendeshwa mahali pengine kabisa. Apex huendeshwa kwenye seva za programu za Salesforce, na shughuli ya upande wa seva katika Marketing Cloud huendeshwa katika mazingira ya utekelezaji ya bidhaa hiyo. Hakuna kimoja kinachorithi handaki la kompyuta yako. Fanya hili kama utaratibu mfupi: tambua mwitaji, chagua kiingilio ambacho mwitaji huyo anaweza kufikia, unga njia kutoka mwanzo hadi mwisho, kisha thibitisha kutoka kwenye mazingira ya utekelezaji yenyewe.

Andika kadi ya mwitaji kabla ya mabadiliko yoyote ya mtandao

Jaza sehemu tano na kataa kukisia yoyote kati yao. Bidhaa ya utekelezaji na muktadha huamua kila kitu kinachofuata, kwa hiyo anza hapo na si kwenye firewall ya seva.

FieldWhat it must answer
RuntimeWhich product and execution context issues the request?
EndpointWhich hostname must that runtime resolve, and to what?
PathWhich supported public entry or private connection carries it?
IdentityWhich credential and which operation is the API asked to authorize?
FailureHow do responses return, and what happens when the path is down?

Kichupo cha kivinjari na mwito wa Apex ni wateja wawili tofauti, na kivinjari kinachofanya kazi kinathibitisha tu kwamba kuna njia kutoka mezani pako. Ikiwa sehemu ya mazingira ya utekelezaji inasema Apex, swali linalofaa ni Salesforce hutoka kwenye anwani gani, si anwani gani kompyuta yako inayo. Ndiyo sababu handaki inayofanya API ipakiwe kwenye kivinjari inaweza kuacha muunganisho ukishindwa kwa muda uleule wa awali. Kadi ya mwitaji ipo ili kuzuia kosa hilo kabla ya mtu yeyote kuhariri firewall.

Chagua kiingilio ambacho mwitaji anaweza kutumia kwa kweli

Miundo yote miwili ni halali, na hutatua matatizo tofauti. Ya kwanza ni kiingilio cha umma kwa kusudi: lango la API la HTTPS au huduma ya muunganisho inayothibitisha mwitaji, inayotumia ruhusa finyu na inayoshikilia muunganisho uliolindwa kwa backend ya kibinafsi. Hiyo si sawa na kufichua kila huduma ya backend au kupeleka bandari ya usimamizi kwenye intaneti.

Ya pili ni muunganisho wa kibinafsi unaostahili. Nyaraka za Private Connect za kutoka za Salesforce zinaeleza jinsi miito inayotumika inavyopitishwa kupitia Outbound Network Connection iliyofungwa kwa kitambulisho kilichotajwa, kwa mpangilio wake uliobainishwa wa AWS PrivateLink. Kipengele kina vikwazo vya toleo, leseni na bidhaa, kwa hiyo thibitisha kuwa taasisi inastahili kabla ya kubuni kukizunguka.

Hakuna muundo kati ya hiyo miwili ambao ni mteja wa OpenVPN uliosakinishwa ndani ya Salesforce, na dai la zamani kwamba kila muunganisho lazima ufikie backend ya umma ni pana mno pale muunganisho wa kibinafsi unaotumika unafaa. Chagua ule ambao mazingira ya utekelezaji yanaunga mkono, kisha kamilisha njia hadi API halisi: kituo cha mwisho cha AWS hakijui rasilimali yako ya ndani na hakirithi njia ya kompyuta yako. DNS, uelekezaji wa backend, sera ya ufikiaji na trafiki ya majibu vyote vinapaswa kufuata usanifu uliochagua. Njia ya kibinafsi iliyojengwa nusu hushindwa kwa namna inayofanana kabisa na tatizo la uthibitishaji.

Unga njia ya kibinafsi kutoka mwanzo hadi mwisho

Fanya kazi kutoka API kwenda nje na simama kwenye pengo la kwanza. Thibitisha kuwa backend inajibu kwa ndani, kisha kwamba kituo cha mwisho cha kibinafsi kinaifikia, kisha kwamba kitambulisho kilichotajwa na muunganisho wake wa kutoka vinalenga kituo hicho.

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 integration

Amri ya kwanza inathibitisha kuwa backend ni nzuri kutoka ndani ya mtandao wa kibinafsi, ya pili inaonyesha jina linatatuliwa kwa nini, na ya tatu inatekelezwa mwito kutoka mazingira halisi ya utekelezaji ya Salesforce. 200 kutoka ya kwanza na kushindwa kutoka ya tatu hutenganisha pengo kwenye njia au kitambulisho, si kwenye huduma.

Weka wigo wa utambulisho kwa usahihi unapounganisha. Kitambulisho kilichotajwa hakiwezi kurekebisha peke yake kituo cha mwisho kisichofikika, kwa sababu kitambulisho na muunganisho wa kibinafsi ni mipangilio inayohusiana na kazi tofauti. Orodha ya IP zinazoruhusiwa hupunguza uingiaji wa mtandao na si kitambulisho cha API, kwa hiyo weka uthibitishaji wa kawaida wa TLS na mchakato wa uthibitishaji na mzunguko wa huduma yenyewe. Ikiwa jaribio linafaulu tu baada ya kuzima ukaguzi wa cheti, umepata tatizo la jina la mwenyeji na si la njia, na cheti bado kinapaswa kuendana.

Thibitisha kutoka mazingira ya utekelezaji, kisha rekodi urejeshaji

Kubali ombi lililoruhusiwa lisilo na madhara kutoka mazingira ya utekelezaji ya muunganisho, si kutoka kwenye mashine yako. Rekodi chanzo kilichoonekana cha huduma inayopokea, mtambulisho uliothibitishwa, matokeo na ombi moja lililokataliwa kwa kusudi ambalo lazima lishindwe.

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/ping

Endesha uchunguzi huo huo wa pili kutoka mtandao wa backend yenyewe ili chanzo kilichoonekana kiweze kulinganishwa na kile mazingira ya utekelezaji yalizalisha. 200 ikifuatiwa na 401 au 403 ndiyo umbo unaotaka; 200 mbili zinamaanisha njia ya kukataa haitekelezwi kwa kweli.

Andika urejeshaji kabla ya kuuhitaji: ni kipengele gani cha orodha ya ruhusa, kitambulisho kilichotajwa au muunganisho wa kutoka uliobadilisha, nani anamiliki na jinsi ya kurejesha thamani ya awali. Kisha funga mduara kwa kutaja kwenye tiketi mwitaji wa wingu na njia kamili ya huduma, ili mtu yeyote asifungue tena suala hilo kama tatizo la VPN.

Makala zinazohusiana