Apex コールアウトは Salesforce から出るのであり、VPN からではない
ノート PC の VPN はブラウザに経路を与えるだけで、Apex や Marketing Cloud には与えません。実際の呼び出し元を、公開ゲートウェイか適格なプライベート接続に対応させます。
ノート PC が VPN に参加した瞬間、ブラウザではプライベート API が応答するため、連携は動くはずに見えます。実際には動きません。コールアウトを行うコードはまったく別の場所で実行されるからです。Apex は Salesforce のアプリケーションサーバー上で実行され、Marketing Cloud のサーバー側アクティビティはその製品のランタイムで実行されます。どちらもノート PC のトンネルを引き継ぎません。短い手順として進めてください。呼び出し元を特定し、その呼び出し元が到達できる入口を選び、経路を端から端まで配線し、最後にランタイム自身から検証します。
ネットワークを変更する前に呼び出し元カードを書く
五つの項目を埋め、どれも推測してはいけません。実行する製品とコンテキストが以降のすべてを決めるので、サーバーのファイアウォールではなくそこから始めます。
| 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 がどのアドレスから出るのであって、自分のノート PC がどのアドレスを持つかではありません。だから API がブラウザで読み込めるトンネルでも、連携は以前と同じタイムアウトで失敗し続けます。呼び出し元カードは、誰かがファイアウォールを編集する前にその誤りを止めるためにあります。
呼び出し元が実際に使える入口を選ぶ
どちらの設計も正当で、解く問題が異なります。一つ目は意図的な公開入口です。呼び出し元を認証し、狭い権限を適用し、プライベートなバックエンドへの保護された接続を保つ、HTTPS の API ゲートウェイまたは連携サービスです。これは、すべてのバックエンドサービスを露出したり、管理ポートをインターネットへ転送したりするのとは違います。
二つ目は適格なプライベート接続です。Salesforce のPrivate Connect のアウトバウンドに関するドキュメントは、対応するコールアウトを、名前付き資格情報に紐づく Outbound Network Connection を介して、定義された AWS PrivateLink の構成で経路化することを説明しています。この機能にはエディション、ライセンス、製品の制約があるため、これを前提に設計する前に組織が条件を満たすことを確認してください。
どちらの設計も Salesforce の内部にインストールする OpenVPN クライアントではなく、すべての連携が公開バックエンドに到達しなければならないという古い主張は、対応するプライベート接続が適する場面では広すぎます。ランタイムが対応する方を選び、実際の API までの経路を完成させます。AWS のエンドポイントはオンプレミスのリソースを知らず、ノート PC のルートを引き継ぎません。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 の問題として再び開かれないようにします。