打算升級一個舊系統, 採購了新的設備、新的OS和SQL Server, 裝機是較單純的部份, 複雜的是長年累積的資料容量不小, 又得維持現有系統線上使用, SQL備份還原時間太長, 不是首要選項, 最後的做法是採行SQL排程, 依業務需求進行差異抄寫同步。
舊的SQL Server是2005, 新的是2019, 這版本差的夠大了吧? 建立排程線上同步, 第一點就是做連結伺服器, 我打算由新版本建立連到舊版本上。噹噹! 一做立刻出了下面的錯誤。就這個錯誤, 瞎耗了不少時間, 一開始朝向SQL Server設定、防火牆設定、是不是少了某個SQL Server或Windows的更新、網路設備問題等等, 但事後看來都不是這些因素。還建了測試用的對照環境來比對, 竟然不會有此問題。

接著就是針對2個環境再進行比對, 使用Network Monitor來錄製封包, 果然慢慢找到了問題點。下面這個是對照用的測試環境, 也就是能正常建立連結伺服器的這一台,

下面這個則是有問題的環境, 看來是HandShake一發出就沒下文了。

最後把觀注點放到了TLSCipherSuite上, 這也就是這次造成遠端主機強制關閉一個現存連線的原因。以下這個是線上新環境建立連結伺服器時錄到的第一個封包發出的內容

而下面這個則是對照組環境錄到的第一個封包發出內容, 在最下方多出了一個TLS_RSA_WITH_3DES_EDE_CBC_SHA

再來看HandShake中由遠端回來的第二個封包, 遠端SQL Server 2005這台則只有一個TLSCipherSuite, 也是TLS_RSA_WITH_3DES_EDE_CBC_SHA。

在連線雙方進行HandShake時, 以對照組來說, 因為雙方都有這個TLS_RSA_WITH_3DES_EDE_CBC_SHA, 而且是其中唯一對應得上的一個, 雖然這裡的TLS是1.0版, 而近端雖是最新版本系統, 但尚未關閉TLS1.0, 故可以成功以TLS1.0來進行連通, HandShake成功。
反觀線上環境, 因為近端發出的第一個封包未含這個遠端唯一有的CipherSuite, 因此HandShake失敗。再透過以下工具來查看, 以下是線上環境的狀態, 因為弱掃因素, 在安裝好環境後被管理人員關掉了這個Triple DES 168, 正好就是對應到TLS_RSA_WITH_3DES_EDE_CBC_SHA的項目, 而對照組因為是自我測試使用, 自然在安裝好之後, 不會把這項設定關閉, 因此測試環境才能正常連線。接下來就是政治問題了, 留給大人們去運作吧…

以下是一些網路相關資源:
- https://support.microsoft.com/en-us/topic/kb3135244-tls-1-2-support-for-microsoft-sql-server-e4472ef8-90a9-13c1-e4d8-44aad198cdbe (SQL Server 2005不在支援TLS1.2之列)
- https://docs.microsoft.com/zh-tw/windows/win32/secauthn/cipher-suites-in-schannel?redirectedfrom=MSDN (介紹CipherSuite基本資訊和各OS版本使用的資訊連結)