一般在同城的情况下,分支机构向总部传输数据有几种方式:专线连接;硬件VPN或软件VPN连接;Web应用的模式;通过Internet直接远程连接。
在业务量较小的C/S模式下,通过外网直接远程接入Windows SQL 2008 R2是一种比较经济可行的方式。
笔者单位需要将3个外单位体检点的检测数据传入单位的服务器中,在不增加体检点额外的成本、不改变体检点原来的工作流程的原则下,我们采用了通过Intenet直接远程接入WINDOWS SQL 2008 R2的方式,实现了3个体检点将数据传入本部服务器。其具体连接方法如下。
网络拓扑图见图1。
本部服务器的操作系统是Windwos Server 2008,数据库安装的是Windows SQL 2008 R2,服务器单独接在天融信防火墙的接口3,划成了DMZ区。
检查服务器的1433是否打开:SQL的默认连接端口是1433,如未打开,应先进行设置。
为确保设置正确,用一台笔记本电脑(也安装有WINDOWS SQL 2008 R2)直连服务器,用本地连接的方式成功连上服务器的SQL,然后继续进行下一步的工作。
图1 单位网络拓扑图
将笔记本电脑连入与服务器不同的另一宽带线路中,打开笔记本电脑的SQL Server Managerment Studio,在登录窗的“服务器名称”中输入服务器所联宽带线路的公网IP(下称IP2),“身份验证”选择SQL SERVER身份验证,并依次输入登录名及密码。一会儿,出现如下错误信息,连接失败,如图2所示。
按照出现的错误信息分析:之前用笔记本电脑直连服务器的SQL,是能成功接入的,因此可排除SQL实例的错误;于是检查SQL允许远程连接的配置是否正确。检查方法如下:
(1)以SQL Server身份验证的方式,以SA账号登录进入服务器的SQL R2,然后右键选择“属性”, 选择“连接”,看是否勾选“允许远程连接此服务器”,如未勾选则勾选。
(2)右击数据库,在下拉菜单中选择“方面”, 在右侧的方面下拉框中选择“服 务 器 配 置”;检 查“RemoteAccessEnabled” 属性是否为“True”,如不是将其设为“True”。经检查,服务器的SQL设置没有问题。又在服务器上运行“netstat-an”命令,再次确认1433是开启的。因此确认远程连接SQL失败的原因不是由服务器、SQL R2的设置引起的,另外,两端安装的都是同一版本的SQL R2,排除了版本差异引起的设置问题。于是分析单位的网络拓扑图。
图2 连接失败
从网络拓扑图看,服务器接在天融信防火墙的接口3,单位的局域网接在防火墙的接口2,两者处于不同的链路上,天融信防火墙之前只有路由器,因此,排查范围就只有防火墙和路由器上。登录进路由器中查看配置,发现配置只是配置了几条策略路由而,没有什么可疑之处,因此将排查重点放在防火墙的设置上;又登录进防火墙,也只是常规配置、一般的安全配置及VPN的设置。然后找出防火墙的随机光碟,看了半天,也找不出问题所在。会不会配置少了什么规则呢?
突然间想到:会不会和建网站一样,要做地址映射?防火墙前接有路由器,路由器是可以做地址映射的,但是服务器是接在防火墙的口3的,因此决定在防火墙上做地址映射。于是再次翻阅随机光碟,终于找到了天融信防火墙设置地址映射的方法。
以管理员身份登录进防火墙的管理界面,进行如下操作:
点击左侧栏“资源管理”,服务,在右侧窗口中点击“自定义”,再点击“添加”,增加一条服务,名称填写“linksql”;类型选择 TCP;端口填写1433,然后点击“确定”。
点击左侧栏“防火墙”,再点击“地址转换”,然后在右侧栏点击添加,在模式中选择“目的转换”,源地址选择“任意”,目的地址选择“Eth1”(服务器所联的宽带线路),服务选择linksql,目的地址转换为:选择服务器地址(主机),目的端口转换为:选择“linksql(TCP:1433)”, 然后点确定并保存设置。
将笔记本电脑联入另一条宽带线路,打开Server Managerment Studio,在 登录窗中输入IP2,很快就进入到管理界面,就如进入到本地SQL管理界面一样,至此,成功地远程接入SQL R2,虽然使用起来有点卡顿。
虽然成功地远程接入了SQL R2,但是由于是直连互联网的,所以必须考虑安全性。鉴于连接方式及单位的密级,我们采取了如下措施:
SQL R2的默认连接端口1433,为了防止扫瞄,我们将1433端口改为不常用的端口。
修改SQL R2的默认端口后,服务器的防火墙开启1433的规则也要将端口改为对应的端口。当然天融信防火墙的地址映射规则也要做相应的改变。
在应用程序的开发中,将连接参数:链接套接字、SQL R2的登录账号、密码全部进行加密处理,以防备被截取,其实际的实现方法就不在此文讨论了。