Как настроить виртуальную машину Azure в качестве прокси-сервера для подключения к базе данных SQL через конечную точку службы?
В настоящее время Azure не разрешает доступ к базам данных SQL через конечную точку службы через шлюз VPN. Моя идея обойти это ограничение - настроить виртуальную машину Azure для функционирования в качестве прокси-сервера, чтобы все взаимодействие с базой данных SQL осуществлялось через этот экземпляр (чей трафик к базе данных SQL и из нее затем можно направлять через конечную точку службы). Однако я не смог заставить это решение работать и мог использовать некоторые рекомендации.
Моя настройка:
У меня есть среда AWS с VPN-подключением, установленным в моей среде Azure. У меня есть частная размещенная зона, настроенная с помощью Route53, чтобы разрешить доменное имя моей базы данных SQL в общедоступный IP-адрес соответствующей региональной конечной точки Microsoft.Sql (это IP-адрес, к которому обращается имя домена моей базы данных SQL при доступе База данных SQL от моей прокси-виртуальной машины). Моя таблица маршрутов настроена для пересылки трафика на этот IP-адрес через мой виртуальный частный шлюз.
На стороне Azure у меня есть таблица маршрутов моей подсети шлюза, настроенная для пересылки трафика, предназначенного для общедоступного IP-адреса региональной конечной точки Microsoft.Sql, на мою прокси-виртуальную машину, как если бы это было виртуальное устройство. Сетевой интерфейс прокси-виртуальной машины настроен на разрешение пересылки IP. Таблица маршрутов, подключенная к подсети прокси-виртуальной машины, настроена на маршрутизацию трафика, предназначенного для частного CIDR моего AWS VPC, обратно через шлюз VPN.
Для простоты группы безопасности в средах AWS и Azure настроены так, чтобы разрешать весь входящий и исходящий трафик между частными IP-адресами обеих сред и общедоступным IP-адресом региональной конечной точки Microsoft.Sql.
Что в настоящее время работает:
Мой экземпляр EC2 в AWS VPC может пропинговать и подключаться к моей прокси-виртуальной машине через VPN через свой частный IP-адрес. Прокси-виртуальная машина может обращаться к моей базе данных SQL через конечную точку службы, используя свой частный IP-адрес.
Что не работает:
Я не могу успешно пропинговать или подключиться по ssh к прокси-виртуальной машине из моего экземпляра EC2, пытаясь подключиться к региональному общедоступному IP-адресу Microsoft.Sql (тот, который я настроил для перенаправления на прокси-виртуальную машину), а также имя домена моего SQL База данных (запись, которую я установил в Route53 для регионального публичного IP-адреса Microsoft.Sql). Когда я выполняю захват пакета на прокси-виртуальной машине, я не вижу входящий трафик из моего экземпляра EC2. Трафик увеличивается, как принято в моих журналах потока VPC.
Я понимаю, что для этого предназначены управляемые экземпляры баз данных SQL, однако у меня нет возможности использовать этот сервис.
В настоящее время я не настроил переадресацию с iptables и не настроил какую-либо специальную настройку хоста на прокси-виртуальной машине, так как сначала я хотел увидеть, как сетевой трафик обнаруживается при захвате пакета, а затем проверить, могу ли я успешно подключиться к экземпляру прокси-виртуальной машины перед попыткой настроить любой вид пересылки в базу данных SQL.
Кроме того, возможно ли вообще решение такого типа, позволяющее обойти ограничения конечных точек служб в Azure? Есть ли более простой способ?
Спасибо и наилучшие пожелания.
1 ответ
Моя таблица маршрутов настроена для пересылки трафика на этот IP-адрес через мой виртуальный частный шлюз.
Я не думаю, что есть возможность этого конкретного подхода, потому что...
У меня есть таблица маршрутов моей подсети шлюза, настроенная для пересылки трафика, предназначенного для общедоступного IP-адреса региональной конечной точки Microsoft.Sql, на мою прокси-виртуальную машину, как если бы это было виртуальное устройство.
Эта таблица маршрутов применяется к трафику, исходящему из этой подсети, а не туда, откуда исходит трафик.
Вам необходимо туннелировать этот трафик между двумя компьютерами, а не просто направлять его, поскольку адреса источника и назначения, которые видит сеть, должны быть адресами отдельных виртуальных машин. Это часть того, что делает туннель - если говорить в общем и упрощенно, туннель переносит трафик с / на хосты с адресами a и b во внешние пакеты с из / на хосты с адресами x и y, так что промежуточные сети и шлюзы не нужно понять "настоящий" источник и пункт назначения. Ограничения платформы, вероятно, делают невозможным простую маршрутизацию и пересылку этого трафика как неинкапсулированного IP-трафика с сохранением источника и назначения. (Или, без надлежащего туннеля, вам понадобится NAT или двойной NAT-трафик на экземплярах на обоих концах.)
Существует несколько туннельных решений, работающих на разных уровнях, включая openvpn и HAProxy, но самое простое - по крайней мере для целей концепции - это SSH-туннель.
Из экземпляра EC2, предполагая, что база данных использует TCP-порт 1433:
$ ssh -L 1433:private-ip-of-db:1433 -i keyfile.pem username@ip-of-azure-vm
При этом открытом соединении SSH также имеется сокет, прослушивающий TCP-порт 1434 на экземпляре EC2, и любое соединение с частным IP-адресом экземпляра EC2 на этом порту будет туннелироваться через открытое соединение SSH и передаваться в базу данных. База данных увидит исходный IP-адрес соединения как IP-адрес лазурной виртуальной машины... поэтому в настройках безопасности необходимо разрешить соответствующий трафик, и вы не будете использовать обсуждаемый вами публичный IP-адрес - вы будете использовать EC2 IP-адрес экземпляра и контроль доступа через группу безопасности EC2, и вам потребуется предоставить виртуальной машине Azure доступ к базе данных. С точки зрения доступа к базе данных, экземпляр EC2 выглядит как SQL Server.
SQL Server может предлагать одну или несколько ошибок, для которых требуется больше портов или порт, отличный от того, что я показал выше, но общая идея здесь ясна - я использовал эту стратегию для других протоколов, таких как RDP (порт TCP 3389) и MySQL (TCP-порт 3306), но не помню, чтобы когда-либо пробовал его с MSSQL.