Az Apex-hívások a Salesforce-ból indulnak, nem a VPN-edből
A laptop VPN utat ad a böngésződnek, nem az Apexnek vagy a Marketing Cloudnak. Párosítsd a valódi hívót egy nyilvános átjáróval vagy egy minősített privát kapcsolattal.
A privát API abban a pillanatban válaszol a böngésződben, amikor a laptop csatlakozik a VPN-hez, tehát az integrációnak működnie kellene. Mégsem működik, mert a hívást végző kód egészen máshol fut. Az Apex a Salesforce alkalmazásszerverein fut, a Marketing Cloud szerveroldali tevékenysége pedig annak a terméknek a futtatókörnyezetében. Egyik sem örökli a laptopod alagútját. Végezd el rövid eljárásként: azonosítsd a hívót, válassz egy belépési pontot, amelyet az a hívó elér, kösd össze az útvonalat elejétől a végéig, majd ellenőrizd magából a futtatókörnyezetből.
Írd meg a hívókártyát minden hálózati változtatás előtt
Tölts ki öt mezőt, és utasítsd el bármelyik kitalálását. A végrehajtási termék és a környezet dönt minden továbbiról, ezért ott kezdd, ne a szerver tűzfalánál.
| 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? |
A böngészőfül és az Apex-hívás két különböző kliens, és egy működő böngésző csak azt bizonyítja, hogy létezik útvonal az asztalodtól. Ha a futtatókörnyezet mezője Apexet mond, a releváns kérdés az, hogy a Salesforce mely címekről lép ki, nem az, hogy a laptopod milyen címekkel rendelkezik. Ezért egy alagút, amely betölti az API-t a böngészőben, ugyanazzal az időtúllépéssel hagyhatja elhalni az integrációt, mint korábban. A hívókártya azért van, hogy ezt a hibát megállítsa, mielőtt bárki szerkesztene egy tűzfalat.
Válaszd azt a belépési pontot, amelyet a hívó valóban használhat
Mindkét terv jogos, és különböző problémákat old meg. Az első egy szándékos nyilvános belépés: HTTPS API-átjáró vagy integrációs szolgáltatás, amely hitelesíti a hívót, szűk jogosultságokat alkalmaz, és védett kapcsolatot tart a privát backend felé. Ez nem ugyanaz, mint minden backend-szolgáltatást kitenni vagy egy kezelőportot az internetre továbbítani.
A második egy minősített privát kapcsolat. A Salesforce kimenő Private Connect dokumentációja leírja, hogyan irányítják a támogatott hívásokat egy megnevezett hitelesítő adathoz kötött Outbound Network Connectionön keresztül, a meghatározott AWS PrivateLink-elrendezésen. A funkciónak kiadási, licenc- és termékkorlátai vannak, ezért erősítsd meg, hogy a szervezet megfelel a feltételeknek, mielőtt köré terveznél.
Egyik terv sem a Salesforce belsejébe telepített OpenVPN-kliens, és az a régi állítás, hogy minden integrációnak nyilvános backendet kell elérnie, túl széles ott, ahol egy támogatott privát kapcsolat illik. Válaszd azt, amelyet a futtatókörnyezet támogat, majd fejezd be az útvonalat a valódi API-ig: egy AWS-végpont nem ismeri a helyi erőforrásodat, és nem örökli a laptopod útvonalát. A DNS-nek, a backend-útvonalválasztásnak, a hozzáférési szabályzatnak és a válaszforgalomnak egyaránt a választott architektúrát kell követnie. Egy félig felépített privát útvonal pontosan úgy hibázik, ahogy egy hitelesítési probléma.
Kösd össze a privát útvonalat elejétől a végéig
Dolgozz kifelé az API-tól, és állj meg az első hiányosságnál. Erősítsd meg, hogy a backend helyben válaszol, majd hogy a privát végpont eléri, majd hogy a megnevezett hitelesítő adat és annak kimenő kapcsolata azt a végpontot célozza.
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 integrationAz első parancs bizonyítja, hogy a backend egészséges a privát hálózat belsejéből, a második megmutatja, mire oldódik fel a név, a harmadik pedig hívást hajt végre a valódi Salesforce futtatókörnyezetből. A 200 az elsőtől és a hiba a harmadiktól a hiányosságot az útvonalra vagy a hitelesítő adatra izolálja, nem a szolgáltatásra.
Tartsd pontoson az identitás hatókörét a bekötés közben. Egy megnevezett hitelesítő adat önmagában nem javít meg egy elérhetetlen végpontot, mert a hitelesítő adat és a privát kapcsolat külön feladatú, összefüggő beállítások. Az IP-engedélylista szűkíti a hálózati beengedést, és nem API-hitelesítő adat, ezért tartsd meg a normál TLS-ellenőrzést és a szolgáltatás saját hitelesítési és rotációs folyamatát. Ha egy teszt csak a tanúsítványellenőrzés kikapcsolása után sikerül, hosztnév-problémát találtál, nem útvonal-problémát, és a tanúsítványnak továbbra is egyeznie kell.
Ellenőrizd a futtatókörnyezetből, majd rögzítsd a visszaállítást
Fogadj el egy ártalmatlan, engedélyezett kérést az integráció futtatókörnyezetéből, nem a saját gépedről. Rögzítsd a fogadó szolgáltatás megfigyelt forrását, a hitelesített felet, az eredményt és egy szándékosan elutasított kérést, amelynek meg kell hiúsulnia.
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/pingFuttasd ugyanazt a két próbát a backend saját hálózatából, hogy a megfigyelt forrás összevethető legyen azzal, amit a futtatókörnyezet előállított. A 200, majd 401 vagy 403 a kívánt forma; két 200 azt jelenti, hogy az elutasítási útvonalat valójában nem kényszerítik ki.
Írd meg a visszaállítást, mielőtt szükséged lenne rá: melyik engedélylistabejegyzést, megnevezett hitelesítő adatot vagy kimenő kapcsolatot módosítottad, kié az, és hogyan állítható vissza az előző érték. Aztán zárd le a kört azzal, hogy a jegyben megnevezed a felhőhívót és a szolgáltatás teljes útvonalát, hogy senki ne nyissa újra ugyanezt a kérdést VPN-problémaként.