我正在尝试将我们客户的一个“原样”程序连接到远程数据库而不是本地数据库,他们认为他们已经对其进行了编码以使其以这种方式工作,但由于某种原因,程序在尝试连接到远程数据库时崩溃。我没有源代码,所以我无法深入挖掘,而且该公司不提供任何升级或自定义修改。我可以通过 SqlDbx 和 HeidiSQL 成功连接到数据库,所以我知道服务器设置正确。
这就是为什么我需要找到一种方法来欺骗端口 1433 上的远程连接,使其看起来像是程序的本地数据库连接。我考虑过编辑 hosts 文件,但如果我将 localhost 绑定到 127.0.0.1 以外的其他 IP,它很可能会使其他程序崩溃。
有任何想法吗?
更新:
我尝试过按照建议的方法用其他方式解决此问题,但我已经尝试了所有能想到的方法。
- 所有程序都是相同版本
- TCP/IP 代替本地主机上的命名管道,并与 SqlDbx 和 HeidiSQL 等 sqlviewer 配合使用
- 身份验证与 sqlviewers 配合使用
- 配置只是数据库连接字符串所需的字段
我唯一能看到的就是代码内部有一些东西限制了它,而我无法控制。
答案1
本质上,您是在尝试解决别人的糟糕实现。这对我来说似乎是合理的,有时,这是必要的。如果这个程序在尝试连接到一个数据库而不是另一个数据库时确实“崩溃”,而不是显示错误消息,那就太弱了。
我在 Linux 中有一个备用解决方案(“redir”)...但没有 Windows;但是,我在 Google 机器中发现了这个:
http://www.vakuumverpackt.de/tcptunnel/
我刚刚用“Cygwin”版本测试了它——无需安装,它有一个 exe 和一个 DLL,在我的 Windows 7 笔记本电脑上“刚好可以运行”。还有一个小优点,它有一个--log-to-stdout
选项,与结合>
到文件中,记录从流中嗅探到的字节(可能很有趣)。我手边没有 SQL Server,但我用其他一些 TCP 服务测试了它,它似乎按预期工作——它监听本地套接字,当连接进来时,它会连接到远程计算机上的指定套接字,并将管道的两端连接在一起。监听 1433,“应该”可以解决问题。
无论如何,它都会进入我的工具包中。
答案2
虽然你当然可以使用如下技术SSH 端口转发使远程监听 TCP 套接字看起来像本地套接字,这可能没有任何帮助。
如果您的客户端在连接时“崩溃”,它很可能不会因为您使用了不同的目标 IP 地址而停止这种情况。
软件在连接本地数据库时运行良好,但在连接远程数据库时却出现问题,原因可能有多种,包括但不限于:
- 版本问题
- 使用不同的协议(命名管道与 TCP/IP)
- 身份验证问题(集成身份验证可能在本地有效,但在远程系统上却不起作用)
- 配置问题
您应该将精力集中在问题的诊断上,而不是尝试可疑的解决方法。
答案3
其他答案似乎表明您应该修复应用程序 - 这在现实中并不总是可能的,因此这里有一点创可贴/回形针/泡泡糖修复。
我还没有尝试过 MSSQL,但对于 MySQL,我能够通过 Nginx 配置 TCP 代理。设置是将 Nginx 部署在与应用程序相同的机器上,配置如下这个答案;希望它能为你工作,只需将端口更改为 1433 即可:
stream {
upstream db {
server mssql.example.com:1433;
}
server {
listen 1433;
proxy_pass db;
}
}
编辑:如果涉及使用命名实例和 SQL 浏览器服务(使用 UDP),您还可以添加 UDP 代理配置:https://dev.to/jordonr/reverse-proxy-ms-sql-with-nginx-3e90
stream {
upstream dbtcp {
server db1:1433;
}
upstream dbudp {
server db1:1434;
}
server {
listen 1433;
proxy_pass dbtcp;
proxy_connect_timeout 1s; # detect failure quickly
}
server {
listen 1434 udp;
proxy_pass dbudp;
proxy_connect_timeout 1s; # detect failure quickly
}
}