Requisitos de red y conectividad

La conectividad que necesita la propia solución: quién alcanza la consola y en qué puertos, qué origina la solución hacia fuera, cómo publicarla con seguridad y por qué no necesita acceso propio a int

Qué cubre esta página

Las reglas de firewall que necesita la solución: qué debe alcanzarla, qué debe alcanzar ella, y en qué dirección.

No es la lista de puertos que se usan para alcanzar activos. Esa lista es por plataforma y vive en Puertos y protocolos. Redacte desde allí sus solicitudes de firewall del lado de los activos, y use esta página para las reglas de la propia solución.

Una vez desplegada, la propia solución no requiere ningún acceso a internet. Bloquéelo.

Despliéguela en una red segmentada y segregada. Si su red es plana, la solución no puede entregar aquello para lo que existe. Regularice el diseño de la red antes de desplegarla, no después.

Tráfico que la solución necesita

Origen	Destino	Servicio	Puerto	Motivo
Usuarios de la consola	La solución	HTTP	80	Acceso a la consola por HTTP
Usuarios de la consola	La solución	HTTPS	443	Acceso a la consola por HTTPS
Usuarios de la consola	La solución	SSH	2222	Acceso a la solución por línea de comandos
La solución	Host de acceso web	SSH	22	La solución se conecta al host para desplegar el agente y el mecanismo de control
La solución	Host de acceso web	RDP	3389	Lo mismo que arriba, cuando el host se alcanza por RDP
Host de acceso web	La solución	HTTPS	443	El host se autentica de vuelta contra la solución
Host de acceso web	La solución	HTTP	80	Lo mismo que arriba, por HTTP
Host de acceso web	Internet	Depende de los sitios publicados	Depende	Solo las URL efectivamente publicadas en la solución: HTTP, HTTPS, o un puerto no estándar como el 8080. Enumere las URL publicadas y abra exactamente esas
Su servidor de monitorización	La solución	Agente Zabbix	10050	Agente Zabbix v1, cuando monitoriza el nodo con Zabbix
La solución	Activo Windows	WinRM	5985	Ejecución remota de automatizaciones (recolección de cuentas, rotación de credenciales)

Dos observaciones sobre esa tabla.

HTTP y HTTPS figuran ambos. Que realmente necesite el puerto 80 depende de si la instancia pretende responder por HTTP. Confírmelo antes de abrirlo: una instancia a la que solo se llega por HTTPS no lo necesita.

La regla de WinRM pertenece a la solución, no a su servidor de monitorización. La tabla de origen se la atribuye al servidor Zabbix, lo que parece una copia de la fila anterior: las automatizaciones las ejecuta el servicio de tareas de la propia solución. Consulte Puertos usados por las automatizaciones.

El host de acceso web es la excepción al "sin internet"

Son dos máquinas distintas, y confundirlas produce o bien una funcionalidad rota o bien un agujero innecesario en el perímetro:

• La solución no necesita acceso a internet. Bloquee su salida.

• El host de acceso web, el host que ejecuta las sesiones web publicadas, necesita acceso de salida hacia los sitios que usted publica, y nada más. Ábralo por URL.

Publicar la consola fuera del perímetro

Si los usuarios deben alcanzar la consola desde fuera, publíquela mediante NAT detrás de un WAF, exclusivamente por el puerto 443 (HTTPS). Desde ese único punto de entrada, el usuario alcanza todos los activos internos (RDP, SSH, Telnet, VNC, bases de datos) sin conectividad directa entre el dispositivo del usuario y los activos protegidos.

No publique la consola en internet sin un firewall y un WAF por delante. Si esa protección no está en pie, permita el acceso únicamente a través de una VPN controlada.

Redes hacia las que la solución no puede enrutar

Dos mecanismos, en direcciones opuestas. Un activo usa uno o el otro y nunca los dos: el registro del activo obliga a elegir.

	Dirección	Qué debe permitir la red
Proxy	Solución → red del activo	Una ruta desde la solución hasta el host del proxy, con el puerto SSH abierto en esa dirección. El proxy necesita una credencial almacenada y debe, a su vez, poder ver los activos a los que sirve
Broker	Red del activo → broker	Salida por 443/tcp desde el entorno remoto hacia el broker. No se abre ningún puerto de entrada en la red remota

Un broker debe alcanzarse por un nombre DNS, nunca por una dirección IP desnuda. La dirección queda escrita en los certificados y en los tokens de enrolamiento, y no puede cambiarse después sin reinstalar el broker. Una IP literal solo funciona para un único camino de red: detrás de NAT, la LAN e internet no ven la misma dirección.

Los gateways y los conectores se comunican en una sola dirección, elegida por entorno: permita el tráfico de salida o permita el de entrada, no ambos. El tráfico RDP y SSH puede encapsularse en HTTPS a través del túnel seguro. Consulte Gateways.

Tráfico que origina la solución

Destino	Para qué	Puerto
Activos	Sesiones de usuario y automatizaciones	Según la plataforma y el activo; consulte Puertos y protocolos
Su colector syslog o SIEM	Reenvío de eventos de auditoría	Se fija en el archivo de configuración del appliance /opt/datadike/config/config.txt, como SYSLOG_ADDR=<host>:<port> junto con SYSLOG_FACILITY. El ejemplo documentado usa el puerto 514 y la facility local2. Cambiarlo exige un ticket de soporte y un reinicio de los servicios
Su servidor de correo	Entrega de copias de seguridad, alertas y flujos de aprobación	No documentado: tómelo de la configuración de su servidor de correo
Su directorio	Autenticación LDAP / Active Directory e importación de cuentas	No documentado: tómelo de su directorio. Para LDAPS, los archivos de certificado se cargan en el appliance y se reinicia el servicio. Consulte LDAP y Active Directory

Monitorización

Apunte su monitor al endpoint de salud no autenticado /api/health/. Devuelve un JSON con status, db_status, db_time, redis_status, redis_time y time, de modo que una consulta correcta demuestra que la base de datos y Redis son alcanzables, y no solo que el servidor web está respondiendo. En un clúster, consulte la dirección virtual y cada nodo directamente.

Clústeres

Un clúster se sitúa tras una única dirección virtual, y los clientes se apuntan a esa dirección, no a un nodo concreto. Cada nodo responde además directamente en su propia dirección, y eso es lo que hace posible la monitorización por nodo. Por tanto, su origen de monitorización necesita alcanzar cada nodo, no solo la dirección virtual.

Los puertos usados entre los nodos del clúster para la replicación vienen de DataDike. Consígalos antes de situar los nodos en segmentos de red distintos.

Errores frecuentes

Síntoma	Causa	Solución
La consola no responde por su nombre de host durante la configuración inicial	El registro DNS todavía no existe	Añada una entrada temporal al archivo hosts de su propia estación de trabajo para atravesar la configuración y después cree el registro en su DNS privado, y también en el DNS público si está publicando mediante NAT
La regla de firewall está abierta pero la sesión sigue fallando	La regla se escribió a partir del puerto por defecto de la plataforma, mientras que el activo usa un puerto efectivo distinto	Compruebe el puerto en el registro del activo. Consulte Puertos y protocolos
El acceso inverso por un broker deja de funcionar tras un cambio de red, o nunca funcionó desde un lado	El broker se enroló contra una IP literal	La dirección del broker debe ser un nombre DNS. Cambiarla significa reinstalar el broker
El SSH hacia la solución en el 2222 se rechaza	El puerto está cerrado, o los contenedores no están en marcha en el nodo	Pruebe el alcance en el puerto 2222 desde la red del cliente y después revise el estado de los contenedores en el nodo
Toda contraseña de un solo uso se rechaza	El reloj del nodo se ha desviado; el TOTP se valida al segundo	Sincronice el reloj por NTP y fije la zona horaria correcta

Páginas relacionadas

• Requisitos del sistema

• Puertos y protocolos

• Broker

• Gateways

• Proxy