帶有證書的 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”無法訪問或不存在。檢查網路地址名稱以及本地和遠端端點的埠是否可操作。

然而，有趣的是，我可以看到防火牆上的流量（TCPPDUMP）在兩台伺服器之間來回傳輸大約 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

將 Profiler 附加到兩個實例（如果有見證，則全部三個）並監視事件Audit Database Mirroring Login Event Class和Broker:Connection Event Class。

錯誤 1418 只是說明在特定超時內，無論出於何種原因，mirroirng 會話都沒有啟動和執行。當您在主體上發出 ALTER DATABASE … SET PARTNER = ’tcp://..’ 時，主體將連接到鏡像*，並且鏡像將連接到主體作為響應。這意味著先前設置的主要“合作夥伴”值和鏡像“合作夥伴”值都會出現，它們都必須正確，並且底層基礎設施（路由、DNS、IPSEC、防火牆）必須允許連接從兩個*合作夥伴到所需的地址：埠。如果你有一個見證人，你就給自己一個相當複雜的 TCP 連接毛球，必須驗證它。

如果問題是證書安全，那麼 Audit Database Mirroring Login 事件將清楚地說明原因和問題（證書無效、過期、使用了錯誤的證書等）。如果問題是底層 TCP 結構（路由、DNS、IPSEC、防火牆等），那麼 Broker:Connection 事件實際上會顯示問題。

如果您想準確了解基於證書的身份驗證是如何工作的，請繼續閱讀基於證書的身份驗證如何工作。

引用自：https://serverfault.com/questions/105280