☰

使用憑證透過 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」無法存取或不存在。檢查網路位址名稱以及本地端和遠端端點的連接埠是否正常運作。

然而有趣的是，我可以看到防火牆 (TCPPDUMP) 上的流量在兩台伺服器之間來回傳輸大約 15 秒，然後才向我吐出該錯誤。

此時，我不確定如何繼續，因為我可以從 SERVER-B 上的 SSMS 連接到 SERVER-A\BLUE 實例，並且可以從 SERVER-A 上的 SSMS 連接到 SERVER-B\RED 實例，沒有問題。我很困惑為什麼我此時會收到錯誤。兩端的端點皆在 sys.tcp_endpoints 和 sys.endpoints 中列出為已啟動。

另一個有趣的註解是前嘗試步驟 2，我可以通過 5022 從 SERVER-A telnet 到 SERVER-B，並通過 5022 從 SERVER-B 到 SERVER-A，但是在步驟 2 失敗後，我無法再從任何方向 telnet。 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:連接事件類。

錯誤 1418 只是表示在特定逾時內，鏡像會話由於某種原因未啟動並運行。當您在主體上發出 ALTER DATABASE ... SET PARTNER = 'tcp://..' 時，主體將連接到鏡像和鏡像將連接到主體作為回應。這意味著先前設定的主要「合作夥伴」值和鏡像「合作夥伴」值都會出現，並且它們都必須正確，並且底層基礎設施（路由、DNS、IPSEC、防火牆）必須允許連接到所需位址：連接埠來自兩個都夥伴。如果您有見證人，那麼您將獲得一個相當複雜的 TCP 連接性毛團，必須對其進行驗證。

如果問題是憑證安全性，則審核資料庫鏡像登入事件將清楚說明原因和問題（憑證無效、過期、使用了錯誤的憑證等）。如果問題出在底層 TCP 結構（路由、DNS、IPSEC、防火牆等），則 Broker:Connection 事件實際上會顯示問題。

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

相關內容