我有下面的设置
目标是能够使用Azure托管的VM作为代理将Local连接到SQL。
我尝试用两种方式设置它,Nginx + RTMP流模块,如这里所描述的,使用TCP代理通过VPN连接到SQL数据库,以及下面的nginx.conf
events {
worker_connections 1024;
}
stream {
upstream sqlvm {
server sqldb.database.windows.net:1433;
}
server {
listen 1433;
proxy_pass sqlvm;
}
}第二种方式是在HAProxy模式下使用tcp模式。
listen sqldb
bind *:1433
mode tcp
server sqldb sqldb.database.windows.net:1433 check port 1433 inter 1000在这两种情况下,与SQL (例如sqlcmd)的连接都以同样的方式失败。
# 10.x.x.x is the IP of Azure VM in this setup
$ sqlcmd -S 10.x.x.x,1433 -d dbName -U user@sqldb.database.windows.net -P password
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Cannot open server 'sqldb' requested by the login. Client with IP address '91.x.x.x' is not allowed to access the server. To enable access, use the Windows Azure Management Portal or run sp_set_firewall_rule on the master database to create a firewall rule for this IP address or address range. It may take up to five minutes for this change to take effect..在代理VM上执行时,相同的命令可以工作。
因此,Azure SQL知道原始客户端IP地址并阻止它,即使它是通过代理进行的。
既然我们在TCP级别上进行代理,这怎么可能呢?是否有此设置的解决方案/工作配置?
发布于 2020-04-28 10:24:15
似乎这个问题的答案在Azure SQL连接体系结构上的文档中。
连接策略默认值:除非您显式地将连接策略更改为代理或重定向,否则这是创建后所有服务器上有效的连接策略。对于来自Azure内部的所有客户端连接(例如,来自Azure虚拟机)的默认策略isRedirect和来自外部的所有客户端连接的代理(例如,来自本地工作站的连接)。
这意味着第一个连接通过代理,但是在重定向之后它会完全绕过代理。
在上述设置中,解决方案是将代理VM移出Azure之外。也可以这样做,方法是将DB连接模式更改为代理模式(但以换取性能)。
https://serverfault.com/questions/1014453
复制相似问题