Wywołania Apex wychodzą z Salesforce, a nie z Twojego VPN
VPN na laptopie daje przeglądarce ścieżkę, a nie Apexowi czy Marketing Cloud. Dopasuj rzeczywistego wywołującego do publicznej bramy lub kwalifikowanego połączenia prywatnego.
Prywatne API odpowiada w przeglądarce w chwili, gdy laptop dołącza do VPN, więc integracja powinna działać. Nie działa, ponieważ kod wykonujący wywołanie działa zupełnie gdzie indziej. Apex działa na serwerach aplikacji Salesforce, a aktywność po stronie serwera w Marketing Cloud działa w środowisku uruchomieniowym tego produktu. Żadne z nich nie dziedziczy tunelu laptopa. Potraktuj to jako krótką procedurę: zidentyfikuj wywołującego, wybierz wejście, do którego ten wywołujący może dotrzeć, połącz ścieżkę od początku do końca, a następnie zweryfikuj z samego środowiska uruchomieniowego.
Napisz kartę wywołującego przed jakąkolwiek zmianą w sieci
Wypełnij pięć pól i odmów zgadywania któregokolwiek. Produkt wykonawczy i kontekst decydują o wszystkim dalej, więc zacznij tam, a nie od zapory serwera.
| 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? |
Karta przeglądarki i wywołanie Apex to dwa różne klienty, a działająca przeglądarka dowodzi tylko, że istnieje ścieżka z Twojego biurka. Jeśli pole środowiska uruchomieniowego mówi Apex, właściwym pytaniem jest, z których adresów wychodzi Salesforce, a nie jakie adresy ma Twój laptop. Dlatego tunel, który pozwala wczytać API w przeglądarce, może pozostawić integrację z tym samym limitem czasu co wcześniej. Karta wywołującego istnieje po to, by zatrzymać ten błąd, zanim ktoś zmieni zaporę.
Wybierz wejście, którego wywołujący naprawdę może użyć
Oba projekty są zasadne i rozwiązują różne problemy. Pierwszy to świadome wejście publiczne: brama API po HTTPS lub usługa integracyjna, która uwierzytelnia wywołującego, stosuje wąskie uprawnienia i utrzymuje chronione połączenie z prywatnym backendem. To nie to samo, co wystawienie każdej usługi backendu albo przekierowanie portu zarządzania do internetu.
Drugi to kwalifikowane połączenie prywatne. Dokumentacja wychodzącego Private Connect Salesforce opisuje kierowanie obsługiwanych wywołań przez Outbound Network Connection powiązane z nazwanymi poświadczeniami, zgodnie z zdefiniowanym układem AWS PrivateLink. Funkcja ma ograniczenia edycji, licencji i produktu, więc potwierdź, że organizacja spełnia warunki, zanim zaprojektujesz wokół niej.
Żaden z projektów nie jest klientem OpenVPN zainstalowanym wewnątrz Salesforce, a starsze twierdzenie, że każda integracja musi dotrzeć do publicznego backendu, jest zbyt szerokie tam, gdzie pasuje obsługiwane połączenie prywatne. Wybierz to, co obsługuje środowisko uruchomieniowe, a potem dokończ ścieżkę do rzeczywistego API: punkt końcowy AWS nie zna Twojego zasobu lokalnego i nie dziedziczy trasy laptopa. DNS, routing backendu, polityka dostępu i ruch odpowiedzi muszą podążać za wybraną architekturą. Pół zbudowana prywatna ścieżka zawodzi w sposób, który wygląda dokładnie jak problem z uwierzytelnianiem.
Połącz prywatną ścieżkę od początku do końca
Pracuj od API na zewnątrz i zatrzymaj się na pierwszej luce. Potwierdź, że backend odpowiada lokalnie, potem że prywatny punkt końcowy do niego dociera, a następnie że nazwane poświadczenia i ich połączenie wychodzące celują w ten punkt.
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 integrationPierwsze polecenie dowodzi, że backend jest zdrowy od wewnątrz sieci prywatnej, drugie pokazuje, na co rozwiązuje się nazwa, a trzecie wykonuje wywołanie z rzeczywistego środowiska Salesforce. 200 z pierwszego i błąd z trzeciego izolują lukę do ścieżki lub poświadczeń, a nie do usługi.
Utrzymuj precyzyjny zakres tożsamości podczas łączenia. Nazwane poświadczenia same nie naprawią nieosiągalnego punktu końcowego, ponieważ poświadczenia i połączenie prywatne to powiązane ustawienia o różnych zadaniach. Lista dozwolonych adresów IP zawęża dopuszczanie sieciowe i nie jest poświadczeniem API, więc zachowaj normalną walidację TLS oraz własny proces uwierzytelniania i rotacji usługi. Jeśli test przechodzi dopiero po wyłączeniu sprawdzania certyfikatu, znalazłeś problem z nazwą hosta, a nie ze ścieżką, a certyfikat nadal musi pasować.
Zweryfikuj ze środowiska uruchomieniowego, a potem zapisz wycofanie
Przyjmij nieszkodliwe dozwolone żądanie ze środowiska uruchomieniowego integracji, a nie z własnej maszyny. Zapisz zaobserwowane źródło usługi odbierającej, uwierzytelnionego podmiotu, wynik oraz jedno celowo odrzucone żądanie, które musi się nie powieść.
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/pingUruchom te same dwie sondy z własnej sieci backendu, aby zaobserwowane źródło można było porównać z tym, co wygenerowało środowisko uruchomieniowe. 200, a po nim 401 lub 403, to kształt, którego chcesz; dwa 200 oznaczają, że ścieżka odmowy nie jest faktycznie egzekwowana.
Zapisz wycofanie, zanim go potrzebujesz: który wpis listy dozwolonych, nazwane poświadczenia lub połączenie wychodzące zmieniłeś, kto jest jego właścicielem i jak przywrócić poprzednią wartość. Następnie zamknij pętlę, nazywając w zgłoszeniu wywołującego w chmurze i pełną ścieżkę usługi, żeby nikt nie otworzył ponownie tego samego zagadnienia jako problemu z VPN.