Apex 콜아웃은 VPN이 아니라 Salesforce에서 나갑니다
노트북 VPN은 브라우저에 경로를 줄 뿐 Apex나 Marketing Cloud에는 주지 않습니다. 실제 호출자를 공용 게이트웨이나 자격을 갖춘 프라이빗 연결에 맞추십시오.
노트북이 VPN에 연결되는 순간 브라우저에서는 프라이빗 API가 응답하므로 통합이 되어야 할 것 같습니다. 하지만 되지 않습니다. 콜아웃을 수행하는 코드가 전혀 다른 곳에서 실행되기 때문입니다. Apex는 Salesforce의 애플리케이션 서버에서 실행되고, Marketing Cloud의 서버 측 활동은 해당 제품의 런타임에서 실행됩니다. 어느 쪽도 노트북의 터널을 물려받지 않습니다. 짧은 절차로 진행하십시오. 호출자를 식별하고, 그 호출자가 도달할 수 있는 진입점을 고르고, 경로를 처음부터 끝까지 연결한 다음, 런타임 자체에서 검증하십시오.
네트워크를 바꾸기 전에 호출자 카드를 작성하십시오
다섯 개 항목을 채우고 어느 것도 추측하지 마십시오. 실행 제품과 컨텍스트가 이후의 모든 것을 결정하므로 서버의 방화벽이 아니라 거기서 시작하십시오.
| 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? |
브라우저 탭과 Apex 콜아웃은 서로 다른 클라이언트이고, 브라우저가 동작한다는 것은 내 책상에서 경로가 있다는 것만 증명합니다. 런타임 항목이 Apex라면 관련 질문은 Salesforce가 어느 주소에서 나가는가이지, 노트북이 어느 주소를 갖는가가 아닙니다. 그래서 API가 브라우저에서 열리게 하는 터널이 있어도 통합은 이전과 같은 타임아웃으로 계속 실패할 수 있습니다. 호출자 카드는 누군가 방화벽을 편집하기 전에 그 실수를 막기 위해 존재합니다.
호출자가 실제로 사용할 수 있는 진입점을 고르십시오
두 설계 모두 정당하며 서로 다른 문제를 해결합니다. 첫째는 의도적인 공용 진입점입니다. 호출자를 인증하고, 좁은 권한을 적용하고, 프라이빗 백엔드로 보호된 연결을 유지하는 HTTPS API 게이트웨이나 통합 서비스입니다. 이는 모든 백엔드 서비스를 노출하거나 관리 포트를 인터넷으로 전달하는 것과 같지 않습니다.
둘째는 자격을 갖춘 프라이빗 연결입니다. Salesforce의 아웃바운드 Private Connect 문서 는 지원되는 콜아웃을 이름 있는 자격 증명에 묶인 Outbound Network Connection을 통해 정의된 AWS PrivateLink 구성으로 라우팅하는 방법을 설명합니다. 이 기능에는 에디션, 라이선스, 제품 제약이 있으므로 이를 전제로 설계하기 전에 조직이 조건을 충족하는지 확인하십시오.
어느 설계도 Salesforce 내부에 설치하는 OpenVPN 클라이언트가 아니며, 모든 통합이 공용 백엔드에 도달해야 한다는 오래된 주장은 지원되는 프라이빗 연결이 맞는 곳에서는 너무 넓습니다. 런타임이 지원하는 쪽을 고르고 실제 API까지 경로를 완성하십시오. AWS 엔드포인트는 온프레미스 리소스를 알지 못하고 노트북의 경로를 물려받지 않습니다. DNS, 백엔드 라우팅, 접근 정책, 응답 트래픽이 모두 선택한 아키텍처를 따라야 합니다. 절반만 만든 프라이빗 경로는 인증 문제와 똑같이 보이는 방식으로 실패합니다.
프라이빗 경로를 처음부터 끝까지 연결하십시오
API에서 바깥으로 작업하고 첫 번째 공백에서 멈추십시오. 백엔드가 로컬에서 응답하는지, 그다음 프라이빗 엔드포인트가 거기에 도달하는지, 그다음 이름 있는 자격 증명과 그 아웃바운드 연결이 그 엔드포인트를 향하는지 확인하십시오.
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첫 번째 명령은 프라이빗 네트워크 안에서 백엔드가 정상임을 증명하고, 두 번째는 이름이 무엇으로 해석되는지 보여 주며, 세 번째는 실제 Salesforce 런타임에서 콜아웃을 실행합니다. 첫 번째의 200과 세 번째의 실패는 공백을 서비스가 아니라 경로나 자격 증명으로 분리합니다.
연결하는 동안 ID 범위를 정확하게 유지하십시오. 이름 있는 자격 증명은 도달할 수 없는 엔드포인트를 혼자 고치지 못합니다. 자격 증명과 프라이빗 연결은 역할이 다른 관련 설정이기 때문입니다. IP 허용 목록은 네트워크 허용 범위를 좁힐 뿐 API 자격 증명이 아니므로, 정상적인 TLS 검증과 서비스 자체의 인증 및 순환 절차를 유지하십시오. 인증서 검사를 끈 뒤에야 테스트가 통과한다면 경로가 아니라 호스트 이름 문제를 찾은 것이며, 인증서는 여전히 일치해야 합니다.
런타임에서 검증한 다음 롤백을 기록하십시오
내 컴퓨터가 아니라 통합 런타임에서 무해하고 허용된 요청을 받으십시오. 수신 서비스가 관찰한 출처, 인증된 주체, 결과, 그리고 반드시 실패해야 하는 의도적으로 거부된 요청 하나를 기록하십시오.
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같은 두 검사를 백엔드 자체 네트워크에서 실행해 관찰된 출처를 런타임이 만든 것과 비교할 수 있게 하십시오. 200 다음에 401이나 403이 오는 것이 원하는 형태입니다. 200이 두 번 나오면 거부 경로가 실제로 강제되지 않는 것입니다.
필요해지기 전에 롤백을 작성하십시오. 어떤 허용 목록 항목, 이름 있는 자격 증명, 아웃바운드 연결을 바꿨는지, 소유자는 누구인지, 이전 값을 어떻게 복원하는지. 그다음 티켓에 클라우드 호출자와 전체 서비스 경로를 적어 같은 문제가 다시 VPN 문제로 열리지 않게 하십시오.