В настоящее время 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, на мою прокси-виртуальную машину, как если бы это было виртуальное устройство.
Эта таблица маршрутов применяется к трафику, происходящему в этой подсети, а не к тому месту, откуда он исходит.
Вам необходимо туннелировать этот трафик между двумя машинами, а не просто маршрутизировать его, потому что адреса источника и назначения, которые видит сеть, должны быть адресами отдельных виртуальных машин. Это часть того, что делает туннель - говоря в общем и упрощенном виде, туннель обертывает трафик от / к хостам с адресами 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.