Espelhamento de banco de dados SQL 2008 através de link WAN com certificados

Question

Estou configurando o espelhamento de banco de dados em um link WAN entre duas instâncias nomeadas do SQL 2008 cujos servidores host não são membros do domínio, usando certificados para autenticação. Depois de muitas tentativas de fazer isso funcionar sozinho, comecei do zero e segui passo a passo de acordo com o BOLhttp://technet.microsoft.com/en-us/library/ms191140.aspx, no entanto, o problema que eu estava tentando resolver ainda está presente.

O problema está no conjunto de etapas finais que definem o status do parceiro em cada servidor. Quando executo a etapa 2 para definir o status do parceiro em "HOST_A", recebo o seguinte erro:

Msg 1418, Nível 16, Estado 1, Linha 2

O endereço de rede do servidor "TCP://server-b.our-domain.com:5022" não pode ser alcançado ou não existe. Verifique o nome do endereço de rede e se as portas dos terminais locais e remotos estão operacionais.

O interessante, porém, é que posso ver o tráfego no firewall (TCPDUMP) indo e voltando entre os dois servidores por cerca de 15 segundos antes que o erro seja devolvido para mim.

Neste ponto, não tenho certeza de como proceder porque posso me conectar à instância SERVER-A\BLUE do SSMS no SERVER-B e posso me conectar à instância SERVER-B\RED do SSMS no SERVER-A sem problemas. Estou muito confuso por que estou recebendo o erro neste momento. Os endpoints de ambos os lados são listados como iniciados em sys.tcp_endpoints e sys.endpoints.

Outra nota interessante é queantestentando a etapa 2, consigo telnet do SERVIDOR-A para o SERVIDOR-B em 5022 e do SERVIDOR-B para o SERVIDOR-A em 5022, no entanto, após a falha da etapa 2, não consigo mais telnet em nenhuma direção. TCPDUMP mostrará o tráfego indo de um para o outro, mas não há tráfego de retorno após a falha da etapa 2.

O principal problema para mim é que esse erro parece ter a descrição errada para o que quer que esteja realmente acontecendo, pois claramente o endereço de rede existe e pode ser alcançado e os terminais também estão operacionais (pelo menos até que a operação falhe [Rolleyes]). também tentei fazer a configuração na direção oposta (fazendo um backup/restauração completo sem recuperação, etc. indo na outra direção) e falha exatamente da mesma maneira, fornecendo os mesmos erros, mas novamente com todo o tráfego exibido no firewall.

Por último, nos logs SQL também recebo o erro “Erro: 1443, Gravidade: 16, Estado: 2”. O que parece estar diretamente relacionado, e parte do que encontrei on-line sugere um problema com a autenticação do Windows, no entanto, esse não deveria ser o caso, pois meus endpoints estão configurados com certificados.

Qualquer ajuda com isso seria muito apreciado.

Aqui está o T-SQL real usado para configurar isso, que segue o que está no artigo 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

Answer 1

Anexe o Profiler a ambas as instâncias (todas as três se houver uma testemunha) e monitore os eventosClasse de evento de login de espelhamento de banco de dados de auditoriaeCorretor: classe de evento de conexão.

O erro 1418 simplesmente informa que dentro de um tempo limite específico a sessão de espelhamento não estava funcionando, por qualquer motivo. Quando você emite ALTER DATABASE ... SET PARTNER = 'tcp://..' no principal, o principal se conectará ao espelhoeo espelho se conectará ao principal em resposta. O que significa que tanto o valor do 'parceiro' principal quanto o valor do 'parceiro' do espelho, definidos anteriormente, entram em cena, e ambos devem estar corretos e a infra-estrutura subjacente (roteamento, DNS, IPSEC, Firewalls) deve permitir a conexão para o endereço desejado:porta deambosparceiros. Acrescente a testemunha, se você tiver uma, e você terá uma bola de cabelo bastante complexa de conectividade TCP que precisa ser verificada.

Se o problema for segurança do certificado, o evento Audit Database Mirroring Login indicará claramente a causa e o problema (certificado inválido, expirado, certificado incorreto usado, etc.). Se o problema for a estrutura TCP subjacente (roteamento, DNS, IPSEC, firewall, etc.), o evento Broker:Connection realmente mostrará o problema.

Se você quiser entender exatamente como funciona a autenticação baseada em certificado, continue lendo emComo funciona a autenticação baseada em certificado.