У нас есть производственный сервер базы данных, который на данный момент не является общедоступным, не имеет общедоступного IP-адреса и находится в частной подсети VPC.
На данный момент он доступен только из приложений, запущенных на EC2 в том же VPC.
Теперь у нас есть необходимость разрешить ограниченный удаленный доступ к этой базе данных другому поставщику за пределами нашей учетной записи Amazon и VPC.
У меня есть заранее определенный список IP-адресов, к которым потребуется доступ.
Я пытаюсь найти лучший способ сделать это с минимальным прерыванием работы других наших приложений, работающих в нашем VPC.
Я мог бы изменить экземпляры базы данных для использования общедоступных IP-адресов, но, попробовав это в тестовой базе данных, я вижу, что затем EC2 начинает преобразовывать конечную точку экземпляра в общедоступный адрес. Я предполагаю, что это испортит наши правила маршрутизации VPC и группы безопасности и потенциально нарушит доступ для наших приложений.
Я бы хотел, чтобы наши внутренние приложения продолжали обращаться к базе данных точно так же, как и всегда, через частные IP-адреса, но каким-то образом давали приложению удаления общедоступный адрес, по которому оно могло получить доступ к базе данных.
По-видимому, стороннее приложение не может использовать SSH-туннель или VPN. Требуется прямое TCP-соединение с общедоступным IP-адресом.
Мне не удалось найти на Amazon никакой документации для этого типа установки.
Если у вас нет грантов или ACL на основе исходного IP-адреса в mysqld, в этом случае просто создайте микро-экземпляр aws и настройте на нем перенаправитель портов, например rinetdдля перенаправления входящих подключений, предназначенных для порта mysqld, с IP-адресов из белого списка на ваш экземпляр RDS.
На всякий случай кому еще пригодится. Вот как я это сделал ...
1) Запустил небольшой EC2 в своей частной подсети.
2) Настроил минимальный экземпляр nginx.
В версию пакета не входил потоковый модуль, поэтому я построил его вот так ...
./configure --with-stream --without-http_rewrite_module
Этот экземпляр будет использоваться только для этой конкретной цели, поэтому мне не понадобились другие модули nginx.
3) Затем я настраиваю свой nginx.conf вот так ...
events {
worker_connections 1024;
}
stream {
upstream rds_db_1 {
server [aurora_endpoint_1]:3306;
}
upstream rds_db_1 {
server [aurora_endpoint_2]:3306;
}
...
server {
listen 33061;
proxy_pass rds_db_1;
}
server {
listen 33062;
proxy_pass rds_db_2;
}
...
}
В моем случае у меня было несколько подключений к прокси, поэтому я использовал специальные высокие номера портов, чтобы различать каждое подключение (33061, 33062, ...). Эти порты совершенно произвольны.
Если вы выполняете только одно соединение, вы можете просто заставить nginx прослушивать обычный номер порта mysql.
4) Настройте балансировщик сетевой нагрузки NLB в общедоступной подсети для пересылки запросов к экземпляру.
Я также мог бы просто поместить экземпляр прокси в публичную подсеть и пропустить балансировщик нагрузки, но это казалось более безопасным способом сделать это.
Затем я настраиваю группу безопасности для экземпляра, чтобы разрешить запросы от VPC CIDR (для проверки работоспособности экземпляра NLB->) и от внешних IP-адресов поставщиков.
Балансировщики сетевой нагрузки нельзя настроить напрямую с группами безопасности, поэтому правила безопасности необходимо настраивать непосредственно на целевом экземпляре.
5) Я создал специальных пользователей mysql специально для поставщика.
6) Наконец, я настраиваю удобную для клиента запись DNS, указывающую на мою NLB.