☰

Base de datos SQL 2008 reflejada a través de un enlace WAN con certificados

tag-icon • tag-icon sql-server sql-server-2008 database-mirroring certificate
Base de datos SQL 2008 reflejada a través de un enlace WAN con certificados

Estoy configurando la duplicación de la base de datos a través de un enlace WAN entre dos instancias con nombre de SQL 2008 cuyos servidores host no son miembros del dominio y uso certificados para la autenticación. Después de muchos intentos de hacer que esto funcione por mi cuenta, comencé desde cero y fui paso a paso de acuerdo con BOL.http://technet.microsoft.com/en-us/library/ms191140.aspx, sin embargo, el problema que estaba intentando resolver sigue presente.

El problema está en el conjunto de pasos finales que establece el estado del socio en cada servidor. Cuando realizo el paso 2 para establecer el estado del socio en "HOST_A", aparece el siguiente error:

Mensaje 1418, Nivel 16, Estado 1, Línea 2

No se puede acceder a la dirección de red del servidor "TCP://server-b.our-domain.com:5022" o no existe. Verifique el nombre de la dirección de red y que los puertos para los puntos finales locales y remotos estén operativos.

Sin embargo, lo interesante es que puedo ver el tráfico en el firewall (TCPDUMP) yendo y viniendo entre los dos servidores durante unos 15 segundos antes de que me respondan ese error.

En este punto, no estoy seguro de cómo proceder porque puedo conectarme a la instancia SERVER-A\BLUE desde SSMS en el SERVIDOR-B y puedo conectarme a la instancia SERVER-B\RED desde SSMS en el SERVIDOR-A sin problemas. Estoy muy confundido por qué recibo el error en este momento. Los puntos finales de ambos lados se enumeran como iniciados en sys.tcp_endpoints y sys.endpoints.

Otra nota interesante es queantesAl intentar el paso 2, puedo hacer telnet desde el SERVIDOR-A al SERVIDOR-B a través de 5022 y desde el SERVIDOR-B al SERVIDOR-A a través de 5022, sin embargo, después de que falla el paso 2, ya no puedo hacer telnet en ninguna dirección. TCPDUMP mostrará el tráfico que va de uno al otro, pero no hay tráfico de retorno después de que falla el paso 2.

El problema principal para mí es que este error parece tener una descripción incorrecta de lo que sea que esté sucediendo, ya que claramente la dirección de red existe y se puede alcanzar y los puntos finales también están operativos (al menos hasta que la operación falle [Rolleyees]). También intenté hacer la configuración en la dirección opuesta (haciendo una copia de seguridad/restauración completa sin recuperación, etc. yendo en la otra dirección) y falla exactamente de la misma manera, generando los mismos errores, pero nuevamente con todo el tráfico mostrándose en el firewall.

Por último, en los registros de SQL también aparece el error "Error: 1443, Gravedad: 16, Estado: 2". Lo cual parece estar directamente relacionado, y algo de lo que encontré en línea sugiere un problema con la autenticación de Windows; sin embargo, ese no debería ser el caso ya que mis puntos finales están configurados con certificados.

Cualquier ayuda con esto sería muy apreciada.

Aquí está el T-SQL real utilizado para configurar esto, que sigue lo que se encuentra en el artículo de 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

Respuesta1

Adjunte Profiler a ambas instancias (las tres si hay un testigo) y monitoree los eventosAuditar clase de evento de inicio de sesión de duplicación de base de datosyAgente: Clase de evento de conexión.

El error 1418 simplemente indica que dentro de un tiempo de espera específico la sesión de duplicación no estaba en funcionamiento, por cualquier motivo. Cuando emite ALTER DATABASE ... SET PARTNER = 'tcp://..' en el principal, el principal se conectará al espejoyel espejo se conectará al director en respuesta. Lo que significa que tanto el valor de 'socio' principal como el valor de 'socio' espejo, establecidos previamente, entran en escena, y ambos tienen que ser correctos y la infraestructura subyacente (enrutamiento, DNS, IPSEC, firewalls) tiene que permitir la conexión. a la dirección deseada: puerto desdeambossocios. Agregue el testigo si tiene uno y obtendrá una bola de pelo bastante compleja de conectividad TCP que debe verificarse.

Si el problema es la seguridad del certificado, entonces el evento de inicio de sesión de Audit Database Mirroring indicará claramente la causa y el problema (certificado no válido, caducado, certificado incorrecto, etc.). Si el problema es la estructura TCP subyacente (enrutamiento, DNS, IPSEC, firewall, etc.), entonces el evento Broker:Connection realmente mostrará el problema.

Si desea comprender exactamente cómo funciona la autenticación basada en certificados, siga leyendo en¿Cómo funciona la autenticación basada en certificados?.

información relacionada