☰

AWS Connect WorkSpace Desktops к базе данных EC2 SQL на том же VPC

tag-icon • tag-icon amazon-web-services amazon-ec2 amazon-vpc
AWS Connect WorkSpace Desktops к базе данных EC2 SQL на том же VPC

Сервер базы данных SQL EC2:

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 также связан общедоступный эластичный IP-адрес. Я отмечаю это, поскольку в документации по пирингу VPC я видел, что пиринг VPC не будет работать правильно, если с ним связан общедоступный IP-адрес)

Я настраиваю AWS Workspace Directory на том же VPC, сетевое подключение Workspace Client:

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, но я не думаю, что это применимо в этой ситуации. Какой подходящий и безопасный способ настроить сетевое подключение между рабочим столом рабочей области (клиентское приложение) и базой данных SQL на моем экземпляре ec2.

Редактировать

1) Я добавил следующее правило в группу безопасности EC2, чтобы разрешить трафик на сервер БД: введите описание изображения здесь 2) Отключите брандмауэр Windows на обоих компьютерах.

решение1

Я подозреваю, что проблема в одной из следующих областей:

  1. Проблема с группами безопасности. Если у обоих экземпляров есть группа безопасности по умолчанию, то проблем быть не должно, но вы могли создать новую группу безопасности для своего экземпляра SQL (поскольку у него есть внешний IP-адрес). Если это так, вам необходимо убедиться, что вы разрешаете доступ из группы безопасности, IP-адреса или диапазона IP-адресов клиента рабочей области.
  2. Проблема с таблицами маршрутизации(маловероятно, если вы не изменили значение по умолчанию)
  3. Проблема с брандмауэром(например, если экземпляр EC2 SQL — это SQL Server, работающий на Windows, на экземпляре может быть включен брандмауэр Windows)
  4. Проблема с NACL (Опять же, вероятно, это не проблема, если вы их не модифицировали.)

Ты прав, чтоVPC-пирингне является решением. Пиринг VPC позволяет вам маршрутизировать между двумя различнымивпцs. У вас две подсети в одном VPC, так что это не то, что вам нужно.

Вот несколько примеров правил безопасности, которые должны работать:

  • 172.31.0.0/16 — разрешить любому объекту в VPC доступ к SQL Server
  • 172.31.16.0/20 — разрешить всем в подсети 172.31.16.0 доступ к SQL Server
  • 172.31.16.45/32 — разрешить одному рабочему столу доступ к SQL-серверу.

(Если это не ясно, вам следует добавить их в группу безопасности, связанную с SQL Server.)

Связанный контент