
Ec2 SQL データベース サーバー:
Connection-specific DNS Suffix . : ec2.internal
Link-local IPv6 Address . . . . . : fe80::9ca:e9d1:a7b5:3e42%16
IPv4 Address. . . . . . . . . . . : 172.31.21.189
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . : 172.31.16.1
*(この Ec2 DB には現在、パブリックにアクセス可能な Elastic IP も関連付けられていることに注意してください。VPC ピアリングのドキュメントで、パブリック IP が関連付けられていると VPC ピアリングが正しく機能しないことがわかったため、この点を指摘しています)
同じ VPC、Workspace Client ネットワーク上に AWS Workspace Directory をセットアップしました。
Connection-specific DNS Suffix . : ec2.internal
Link-local IPv6 Address . . . . . : fe80::dc3c:d1c1:c7fe:812b%15
IPv4 Address. . . . . . . . . . . : 172.31.16.45
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . : 172.31.16.1
これらは同じ CIDR 172.31 上にあるため通信できません。VPC ピアリングに関するドキュメントを読みましたが、この状況には適用できないと思います。ワークスペース デスクトップ (クライアント アプリ) と ec2 インスタンス上の SQL データベース間のネットワーク接続を設定する適切で安全な方法は何ですか。
編集
1) DB サーバーへのトラフィックを許可するために、EC2 セキュリティ グループに次のルールを追加しました。
2) 両方のボックスで Windows ファイアウォールを無効にします。
答え1
次のいずれかの領域に問題があると思われます。
- セキュリティ グループに関する問題。 両方のインスタンスにデフォルトのセキュリティ グループがある場合は問題はありませんが、SQL インスタンスに新しいセキュリティ グループを作成した可能性があります (外部 IP アドレスがあるため)。その場合は、ワークスペース クライアントのセキュリティ グループ、IP アドレス、または IP アドレス範囲からのアクセスを許可する必要があります。
- ルーティングテーブルの問題(デフォルトを変更しない限り、可能性は低いです)
- ファイアウォールの問題(たとえば、EC2 SQL インスタンスが Windows 上で実行されている SQL Server である場合、インスタンスで Windows ファイアウォールが有効になっている可能性があります)
- NACLの問題 (繰り返しますが、変更していない限り、おそらく問題にはなりません。)
おっしゃる通りですVPC ピアリング解決策ではありません。VPCピアリングを使用すると、2つの異なる仮想PC同じ VPC 内に 2 つのサブネットがあるため、これは必要なことではありません。
機能するはずのセキュリティ ルールの例をいくつか示します。
- 172.31.0.0/16 - VPC 内のあらゆるものが SQL Server にアクセスできるようにします
- 172.31.16.0/20 - 172.31.16.0 サブネット内のすべてから SQL Server へのアクセスを許可します
- 172.31.16.45/32 - 1 つのデスクトップが SQL サーバーにアクセスできるようにします。
(明確でない場合は、これらを SQL Server に関連付けられたセキュリティ グループに追加する必要があります。)