> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/es/pam/deploy-operate/network-requirements.md). # 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](/es/pam/reference/ports.md). 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. {% hint style="danger" %} 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. {% endhint %} ## 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) | {% hint style="info" %} 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](/es/pam/reference/ports.md#puertos-usados-por-las-automatizaciones). {% endhint %} ## 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. {% hint style="warning" %} 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. {% endhint %} ## 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](/es/pam/administration/connectivity/proxy.md) | 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](/es/pam/administration/connectivity/broker.md) | 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 | {% hint style="danger" %} 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. {% endhint %} 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](/es/pam/administration/connectivity/gateways.md). ## 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](/es/pam/reference/ports.md) | | 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=:` 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](/es/pam/administration/identities/ldap-and-ad.md) | ## 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](/es/pam/reference/ports.md) | | 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](/es/pam/deploy-operate/requirements.md) * [Puertos y protocolos](/es/pam/reference/ports.md) * [Broker](/es/pam/administration/connectivity/broker.md) * [Gateways](/es/pam/administration/connectivity/gateways.md) * [Proxy](/es/pam/administration/connectivity/proxy.md)