現在、VPC 内で AWS Lambda 関数を実行しており、たとえば、VPC 内の AWS Lambda が MongoDB Atlas でホストされているデータベースと通信できるように、MongoDB Atlas へのピアリング接続がすでに設定されています。
現在、AWS Lambda によってトリガーされ、同じ VPC 内で実行される VPC 内の特定のサービスが、VPN 経由でオンプレミスのネットワーク機能/ホストにアクセスする必要があるという要件が発生しています。さらに、そのネットワークはそのサービスへのメッセージに応答できる必要があるため、サイト間接続が必要になると思います。
顧客は、IKE フェーズ 1 パラメータ、IKE フェーズ 2 パラメータ (IPSEC)、ローカル ピア IP アドレス、受け入れられる VPN 通信ポート、およびローカル暗号化ドメインを提供しました。
彼らは現在、私たちのリモート ピア IP アドレスとリモート暗号化ドメインを要求しています。
質問1: 私たちが実現しようとしていることは、AWS の VPC で実現可能でしょうか (これについては矛盾する投稿を読んでいます。
質問2: トンネルの開始は顧客側から行う必要があり、その後、ネットワーク監視ポーリングを使用してトンネルをアクティブに保つという想定で正しいでしょうか?
答え1
質問1に関して。
IPSec ベースの VPN 経由で接続して、AWS の外部にあるリソースに安全に接続する機能について言及していると仮定します。答えは「はい」です。ただし、この機能のネイティブ AWS 実装にはいくつかの制限があります。1 つ目は、フェーズ 1 またはフェーズ 2 の構成設定のどの側面も指定できないことです。代わりに、AWS ではさまざまなメーカー向けに事前構成された設定をダウンロードする機能を提供していますが、一般的な良い例もいくつか提供しています。
良いリソースとしては次のようなものがあります:
AWS マネージド VPN 接続- AWS VPN Gatewayサービスの詳細を提供します
顧客ゲートウェイ- AWS 外部のデバイスに必要な設定に関する情報を提供します
質問2に関して。
これは本当です。何らかの理由でトンネルが切断された場合、AWS 側はそれを開始できません (これは非常に厄介な制限です)。ただし、回避策があります。一部のデバイスは、トンネルを維持するためにキープアライブパケットの送信をサポートしています。たとえば、Cisco ASA は、IP SLA 機能を使用して、トンネルを介して SLA メッセージを送信し、トンネルを維持できます。抜粋:サンプルASA設定:
トンネルをアクティブまたは常時アップ状態に維持するには、ASA は acl-amzn で定義されたサブネットにトラフィックを送信する必要があります。SLA モニタリングは、サブネット内の宛先に ping を送信するように設定でき、トンネルをアクティブに維持します。このトラフィックは、応答を返すターゲットに送信する必要があります。これは、外部インターフェイスから発信された ASA からターゲットに ping を送信することで手動でテストできます。ping の可能な宛先は、VPC 内のインスタンスです。冗長性を確保するために、複数の SLA モニターを複数のインスタンスに設定して、単一障害点から保護できます。
または、cron ジョブまたはスケジュールされたタスクを介して、一方のシステムが定期的に ping を送信するように設定することもできます。
ただし、別のオプションとして、独自の IPSec ゲートウェイを AWS にデプロイすることもできます。インスタンス自体または別のインスタンスで実行し、サブネットのルート テーブルを更新して、このインスタンス経由で AWS サブネット外にルーティングすることができます。これにより、IPSec の設定と動作をより細かく制御できますが、ネイティブの AWS サービスと比較すると、管理がより複雑になると言えます。