Как я могу настроить виртуальную машину 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 Forwarding. Таблица маршрутизации, подключенная к подсети прокси-виртуальной машины, настроена для маршрутизации трафика, предназначенного для частного CIDR моего AWS VPC, обратно через VPN-шлюз.
Для простоты группы безопасности в средах AWS и Azure настроены на разрешить весь входящий и исходящий трафик между частными IP-адресами обеих сред и общедоступным IP-адресом региональной конечной точки Microsoft.Sql.
Что в настоящее время работает:
Мой экземпляр EC2 в AWS VPC может пинговать и ssh в мою прокси-виртуальную машину через VPN, используя свой частный IP-адрес. Прокси-виртуальная машина может получить доступ к моей базе данных SQL через конечную точку службы, используя свой частный IP-адрес.
Что не работает:
Я не могу успешно выполнить ping или ssh на прокси-виртуальную машину из моего экземпляра EC2, пытаясь подключиться к региональный общедоступный IP-адрес Microsoft.Sql (тот, который я настроил для пересылки на прокси-виртуальную машину), ни имя домена моей базы данных SQL (запись, которую я установил в Route53 для регионального общедоступного IP-адреса Microsoft.Sql). Когда я выполняю захват пакетов на прокси-виртуальной машине, я не вижу входящего трафика от моего экземпляра EC2. Трафик увеличивается, как принято в моих журналах потоков VPC.
Я понимаю, что это то, для чего предназначены управляемые экземпляры базы данных SQL, однако у меня нет возможности использовать эту службу.
В настоящее время я не настроил ни один из них. пересылка с помощью iptables и не выполняла никаких специальных настроек хоста на прокси-виртуальной машине, так как я сначала хотел увидеть сетевой трафик, отображаемый в захвате пакетов, а затем убедиться, что я могу успешно подключиться к экземпляру прокси-виртуальной машины, прежде чем пытаться настроить любой пересылка в базу данных SQL.
Более того, возможно ли решение такого типа для обхода ограничений конечных точек служб в Azure? Есть ли способ попроще?
С уважением и наилучшими пожеланиями.
Моя таблица маршрутов настроена для пересылки трафика на этот IP-адрес через мой виртуальный частный шлюз.
Я не Я не думаю, что этот конкретный подход сработает, потому что ...
У меня есть таблица маршрутов подсети моего шлюза, настроенная для пересылки трафика, предназначенного для общедоступного IP-адреса региональной конечной точки Microsoft.Sql, на мою прокси-виртуальную машину, как если бы это было виртуальное устройство.
Эта таблица маршрутизации применяется к трафику, исходящему в этой подсети, а не там, где он возникает.
Вам необходимо туннелировать этот трафик между двумя машинами, а не просто маршрутизировать его, потому что адреса источника и назначения, которые, по мнению сети, должны быть адресом s отдельных виртуальных машин. Это часть того, что делает туннель - говоря в общем и упрощенном виде, туннель оборачивает трафик от / к хостам с адресами 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-адрес виртуальной машины Azure ... поэтому настройки безопасности должны разрешать трафик соответственно, и вы не будете использовать общедоступный IP-адрес, который вы обсуждали - вы бы использовали EC2 IP-адрес экземпляра и управление доступом через группу безопасности EC2, и вам потребуется предоставить виртуальной машине Azure доступ к базе данных. С точки зрения всего, что обращается к базе данных, экземпляр EC2 выглядит как SQL Server.
SQL Server может предложить одну или несколько ошибок, требующих большего количества портов или другого порта, чем я показал выше, но общая идея здесь надежен - я использовал эту стратегию для других протоколов, таких как RDP (TCP-порт 3389) и MySQL (TCP-порт 3306), но не припоминаю, чтобы когда-либо пробовал ее с MSSQL.