Lệnh gọi Apex đi ra từ Salesforce, không phải từ VPN của bạn

API riêng trả lời trong trình duyệt ngay khi máy tính xách tay tham gia VPN, nên tích hợp lẽ ra phải hoạt động. Nó không hoạt động, vì đoạn mã thực hiện lệnh gọi chạy ở một nơi hoàn toàn khác. Apex chạy trên các máy chủ ứng dụng của Salesforce, còn hoạt động phía máy chủ trong Marketing Cloud chạy trong môi trường thực thi của sản phẩm đó. Cả hai đều không thừa hưởng đường hầm của máy tính bạn. Hãy làm theo một quy trình ngắn: xác định bên gọi, chọn một lối vào mà bên gọi đó có thể chạm tới, nối đường đi từ đầu đến cuối, rồi kiểm chứng từ chính môi trường thực thi.

Viết thẻ bên gọi trước mọi thay đổi mạng

Điền năm trường và từ chối đoán bất kỳ trường nào. Sản phẩm thực thi và ngữ cảnh quyết định mọi thứ về sau, nên hãy bắt đầu từ đó chứ không phải từ tường lửa của máy chủ.

Một tab trình duyệt và một lệnh gọi Apex là hai khách hàng khác nhau, và một trình duyệt chạy được chỉ chứng minh rằng có một đường đi từ bàn làm việc của bạn. Nếu trường môi trường thực thi ghi Apex, câu hỏi phù hợp là Salesforce đi ra từ những địa chỉ nào, chứ không phải máy tính của bạn có những địa chỉ nào. Đó là lý do một đường hầm giúp API tải được trong trình duyệt vẫn có thể để tích hợp hỏng với đúng thời gian chờ như trước. Thẻ bên gọi tồn tại để chặn sai lầm đó trước khi ai đó sửa tường lửa.

Chọn lối vào mà bên gọi thực sự có thể dùng

Cả hai thiết kế đều chính đáng và giải quyết những vấn đề khác nhau. Cách thứ nhất là một lối vào công khai có chủ đích: một cổng API qua HTTPS hoặc một dịch vụ tích hợp xác thực bên gọi, áp dụng quyền hạn hẹp và giữ kết nối được bảo vệ tới backend riêng. Đó không giống với việc phơi bày mọi dịch vụ backend hay chuyển một cổng quản trị ra internet.

Cách thứ hai là một kết nối riêng đủ điều kiện. Tài liệu Private Connect hướng ra ngoài của Salesforce mô tả việc định tuyến các lệnh gọi được hỗ trợ qua một Outbound Network Connection gắn với thông tin xác thực có tên, theo bố trí AWS PrivateLink đã định nghĩa. Tính năng này có ràng buộc về ấn bản, giấy phép và sản phẩm, nên hãy xác nhận tổ chức đủ điều kiện trước khi thiết kế quanh nó.

Không thiết kế nào là một ứng dụng khách OpenVPN cài bên trong Salesforce, và tuyên bố cũ rằng mọi tích hợp phải chạm tới một backend công khai là quá rộng ở những nơi một kết nối riêng được hỗ trợ phù hợp. Hãy chọn thứ mà môi trường thực thi hỗ trợ, rồi hoàn tất đường đi tới API thật: một điểm cuối AWS không biết tài nguyên tại chỗ của bạn và không thừa hưởng tuyến của máy tính bạn. DNS, định tuyến backend, chính sách truy cập và lưu lượng phản hồi đều phải theo kiến trúc bạn đã chọn. Một đường riêng xây dở sẽ hỏng theo cách trông giống hệt một vấn đề xác thực.

Nối đường riêng từ đầu đến cuối

Làm việc từ API ra ngoài và dừng ở khoảng trống đầu tiên. Xác nhận backend trả lời tại chỗ, rồi điểm cuối riêng chạm tới nó, rồi thông tin xác thực có tên và kết nối hướng ra của nó nhắm vào điểm cuối đó.

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

Lệnh đầu tiên chứng minh backend khỏe mạnh từ bên trong mạng riêng, lệnh thứ hai cho thấy tên phân giải thành gì, và lệnh thứ ba thực hiện một lệnh gọi từ môi trường thực thi Salesforce thật. Một 200 từ lệnh đầu và một lỗi từ lệnh thứ ba cô lập khoảng trống vào đường đi hoặc thông tin xác thực chứ không phải dịch vụ.

Giữ phạm vi danh tính chính xác khi nối. Thông tin xác thực có tên không tự sửa một điểm cuối không tới được, vì thông tin xác thực và kết nối riêng là những thiết lập liên quan với nhiệm vụ riêng. Danh sách IP được phép thu hẹp việc tiếp nhận mạng và không phải thông tin xác thực API, nên hãy giữ kiểm tra TLS bình thường cùng quy trình xác thực và luân chuyển của chính dịch vụ. Nếu một bài kiểm tra chỉ qua sau khi bạn tắt kiểm tra chứng chỉ, bạn đã gặp vấn đề tên máy chủ chứ không phải đường đi, và chứng chỉ vẫn phải khớp.

Kiểm chứng từ môi trường thực thi, rồi ghi lại việc hoàn tác

Chấp nhận một yêu cầu vô hại được phép từ môi trường thực thi của tích hợp, không phải từ máy của bạn. Ghi lại nguồn quan sát được của dịch vụ nhận, chủ thể đã xác thực, kết quả và một yêu cầu bị từ chối có chủ đích mà chắc chắn phải hỏng.

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

Chạy đúng hai phép thử đó từ mạng của chính backend để có thể so sánh nguồn quan sát được với thứ môi trường thực thi tạo ra. Một 200 rồi 401 hoặc 403 là hình dạng bạn muốn; hai 200 nghĩa là đường từ chối không thực sự được thực thi.

Viết bản hoàn tác trước khi bạn cần: mục danh sách cho phép, thông tin xác thực có tên hay kết nối hướng ra nào bạn đã đổi, ai sở hữu và cách khôi phục giá trị trước đó. Rồi khép vòng bằng cách nêu tên bên gọi trên đám mây và toàn bộ đường đi của dịch vụ trong phiếu, để không ai mở lại cùng vấn đề như một sự cố VPN.