☰

通过带有证书的 WAN 链接进行 SQL 2008 数据库镜像

tag-icon • tag-icon sql-server sql-server-2008 database-mirroring certificate
通过带有证书的 WAN 链接进行 SQL 2008 数据库镜像

我正在通过两个 SQL 2008 命名实例之间的 WAN 链接配置数据库镜像，这些实例的主机服务器不是域成员，使用证书进行身份验证。经过多次尝试，我自己已经从头开始，并按照 BOL 一步一步进行http://technet.microsoft.com/en-us/library/ms191140.aspx，但我试图解决的问题仍然存在。

问题出在设置每台服务器上的合作伙伴状态的最后步骤上，当我执行步骤＃2 在“HOST_A”上设置合作伙伴状态时，出现以下错误：

消息 1418，级别 16，状态 1，第 2 行

无法访问或不存在服务器网络地址“TCP://server-b.our-domain.com:5022”。请检查网络地址名称以及本地和远程端点的端口是否正常运行。

然而有趣的是，我可以看到防火墙（TCPDUMP）上的流量在两个服务器之间来回传输大约 15 秒，然后错误才会返回给我。

此时我不确定如何继续，因为我可以从 SERVER-B 上的 SSMS 连接到 SERVER-A\BLUE 实例，并且可以毫无问题地从 SERVER-A 上的 SSMS 连接到 SERVER-B\RED 实例。我很困惑为什么此时会出现错误。两侧的端点在 sys.tcp_endpoints 和 sys.endpoints 中均列为已启动。

另一个有趣的现象是前尝试步骤 2，我可以通过 5022 从 SERVER-A 远程登录到 SERVER-B，也可以通过 5022 从 SERVER-B 远程登录到 SERVER-A，但是步骤 2 失败后，我无法再远程登录任一方向。TCPDUMP 将显示从任一方向到另一方向的流量，但步骤 2 失败后没有返回流量。

对我来说，主要的问题是这个错误似乎对实际发生的情况有错误的描述，因为网络地址显然存在，可以访问，端点也可以运行（至少在操作失败之前[Rolleyes]）我也试过做相反方向的配置（做一个完整的备份/恢复，没有恢复等，朝另一个方向走），它以完全相同的方式失败，提供相同的错误，但所有的流量再次显示在防火墙上。

最后，在 SQL 日志中，我还收到错误“错误：1443，严重性：16，状态：2”。这似乎有直接关系，而且我在网上找到的一些信息表明 Windows 身份验证存在问题，但事实并非如此，因为我的端点配置了证书。

任何帮助都将不胜感激。

这是用于设置的实际 T-SQL，它遵循 BOL 文章中的内容。

--ON SERVER-A\BLUE
use master
go

create master key encryption by password = 'password123!'
go

create certificate CA_cert
        With subject = 'CA_cert Certificate'
go

create endpoint Mirroring
        STATE = STARTED
                AS TCP (
                        LISTENER_PORT=5022
                        , LISTENER_IP = ALL
                )
        FOR DATABASE_MIRRORING (
                AUTHENTICATION = CERTIFICATE CA_cert
                , ENCRYPTION = REQUIRED ALGORITHM AES
                , ROLE = ALL
        )
go

BACKUP CERTIFICATE CA_cert TO FILE = 'c:\sql\CA_cert.cer'
go


--ON SERVER-B\RED
use master
go

create master key encryption by password = 'password123!'
go

create certificate NJ_cert
        With subject = 'NJ_cert Certificate'
go

create endpoint Mirroring
        STATE = STARTED
                AS TCP (
                        LISTENER_PORT=5022
                        , LISTENER_IP = ALL
                )
        FOR DATABASE_MIRRORING (
                AUTHENTICATION = CERTIFICATE NJ_cert
                , ENCRYPTION = REQUIRED ALGORITHM AES
                , ROLE = ALL
        )
go

BACKUP CERTIFICATE NJ_cert TO FILE = 'c:\sql\NJ_cert.cer'
go


--ON SERVER-A\BLUE
create login NJ_login WITH PASSWORD = 'password123!'
go

CREATE USER NJ_user FOR LOGIN NJ_login
go

CREATE CERTIFICATE NJ_cert
        AUTHORIZATION NJ_user
        FROM FILE = 'C:\sql\NJ_cert.cer'
go

GRANT CONNECT ON ENDPOINT::Mirroring TO NJ_login
go


--ON SERVER-B\RED
create login CA_login WITH PASSWORD = 'password123!'
go

CREATE USER CA_user FOR LOGIN CA_login
go

CREATE CERTIFICATE CA_cert
        AUTHORIZATION CA_user
        FROM FILE = 'C:\sql\CA_cert.cer'
go

GRANT CONNECT ON ENDPOINT::Mirroring TO CA_login
go


--ON SERVER-B\RED
alter database testdb
        set partner = 'TCP://server-a.our-domain.com:5022'
go


--ON SERVER-A\BLUE
alter database testdb
        set partner = 'TCP://server-b.our-domain.com:5022'
go

-- Everything works fine up until this point at which time I get the previously mentioned errors

答案1

将 Profiler 附加到两个实例（如果有见证者，则附加到所有三个实例）并监视事件审计数据库镜像登录事件类和Broker:Connection 事件类。

错误 1418 只是表示在特定超时时间内镜像会话未启动并运行，无论出于何种原因。当您在主体上发出 ALTER DATABASE ... SET PARTNER = 'tcp://..' 时，主体将连接到镜像和镜像将响应连接到主体。这意味着主体“合作伙伴”值和镜像“合作伙伴”值（之前设置）都应出现，并且它们都必须正确，并且底层基础设施（路由、DNS、IPSEC、防火墙）必须允许连接到所需的地址：端口两个都合作伙伴。如果有见证人，则将其加入，这样您就会得到一个必须验证的相当复杂的 TCP 连接。

如果问题出在证书安全上，那么审计数据库镜像登录事件将清楚地说明原因和问题（证书无效、过期、使用了错误的证书等等）。如果问题出在底层 TCP 结构上（路由、DNS、IPSEC、防火墙等等），那么 Broker:Connection 事件实际上会显示问题。

如果你想确切了解基于证书的身份验证如何工作，请继续阅读基于证书的身份验证如何工作。

相关内容