Paso a Paso Servidores DNS, Apuntes de Redes de Computadoras

¡Descarga Paso a Paso Servidores DNS y más Apuntes en PDF de Redes de Computadoras solo en Docsity!

Autor: Javier Cuenca Pérez

Autor: Javier Cuenca Pérez

Índice

1. Introducción

2. Objetivos del laboratorio

3. Arquitectura de red

4. Diseño de direccionamiento IP

5. Despliegue de los servidores DNS

• 5.1 Preparación de las máquinas virtuales
• 5.2 Instalación del servidor DNS (BIND9)
• 5.3 Configuración del servidor DNS principal (Master)
• 5.4 Configuración del servidor DNS secundario (Slave)

6. Configuración del servidor DHCP

• 6.1 Instalación del servidor DHCP

7. Configuración de reglas de firewall en IPFire

8. Integración DHCP y DNS dinámico (DDNS)

• 8.1 Creación de la clave TSIG
• 8.2 Configuración de la clave en BIND
• 8.3 Creación de la zona inversa
• 8.4 Creación del archivo de zona inversa
• 8.5 Configuración de permisos de la zona
• 8.6 Validación de configuración DNS
• 8.7 Configuración de DHCP para actualizaciones dinámicas

9. Pruebas de disponibilidad DNS

10.Incidencias detectadas y resolución

Autor: Javier Cuenca Pérez

• Configurar la resolución de nombres para servicios internos, permitiendo acceder a los

distintos servidores del laboratorio mediante nombres de dominio en lugar de direcciones IP.

• Permitir la resolución del servicio Nextcloud alojado en la DMZ, el cual se encuentra

desplegado en contenedores Docker y será accesible desde la red interna a través del nombre de dominio configurado en el DNS.

• Aplicar segmentación de red mediante IPFire, separando los servicios internos de los

servicios expuestos en la DMZ y configurando las reglas de firewall necesarias para permitir el acceso seguro entre las diferentes zonas de red. Mediante la consecución de estos objetivos, se pretende recrear una infraestructura básica de servicios de red similar a la que puede encontrarse en entornos corporativos, reforzando conocimientos relacionados con administración de sistemas Linux, servicios de red, alta disponibilidad y diseño de arquitecturas de red seguras.

3. Arquitectura de red

La infraestructura desarrollada en este proyecto se basa en una arquitectura de red segmentada que separa los distintos servicios según su nivel de exposición y función dentro del laboratorio. Para ello se utiliza IPFire como firewall y elemento central de la red, permitiendo gestionar el tráfico entre las diferentes zonas y aplicar políticas de seguridad adecuadas. La red se divide principalmente en dos zonas:

• GREEN (Red interna): zona destinada a los servicios internos de infraestructura y a los equipos cliente del laboratorio.
• ORANGE (DMZ): zona desmilitarizada donde se ubican los servicios que deben estar aislados de la red interna, como el servidor de Nextcloud. Esta segmentación permite aumentar la seguridad de la infraestructura, evitando que los servicios expuestos en la DMZ tengan acceso directo a los sistemas internos de la red GREEN. Dentro de la red interna se encuentran desplegados los servidores que proporcionan los servicios esenciales de red, concretamente los servidores DNS redundantes y el servidor DHCP, además de otros sistemas del laboratorio como el servidor de monitorización o la máquina bastión utilizada para la administración. Por otro lado, en la zona DMZ se encuentra desplegado el servicio Nextcloud, ejecutándose en contenedores Docker sobre un host Linux. Este servicio es accesible desde la red interna mediante resolución DNS proporcionada por los servidores configurados en GREEN. La siguiente tabla resume los principales elementos de la infraestructura y su ubicación dentro de la red:

Servidor Función Red Dirección IP

IPFire Firewall y enrutamiento

GREEN /

ORANGE

dns1 Servidor DNS principal (Master) GREEN 192.168.10.

dns2 Servidor DNS secundario (Slave) GREEN 192.168.10.

dhcp Servidor DHCP GREEN 192.168.10.

bastion Acceso administrativo al laboratorio GREEN 192.168.10.

Autor: Javier Cuenca Pérez

Servidor Función Red Dirección IP

zabbix Monitorización de la infraestructura GREEN 192.168.10.

nextcloud

Servicio de almacenamiento en la

nube (Docker)

ORANGE 192.168.20.

En esta arquitectura, los clientes de la red interna obtienen automáticamente su configuración de red mediante el servidor DHCP, que les asigna una dirección IP dentro del rango definido, así como los servidores DNS primario y secundario. Cuando un cliente necesita acceder a un servicio, como por ejemplo nextcloud.lab.local, realiza una consulta al servidor DNS. Este resuelve el nombre de dominio y devuelve la dirección IP correspondiente al servidor ubicado en la DMZ. Posteriormente, el tráfico es gestionado por IPFire, que permite el acceso desde la red GREEN hacia el servicio específico en la red ORANGE mediante las reglas de firewall configuradas. Esta arquitectura permite mantener una infraestructura organizada, segura y escalable, separando adecuadamente los servicios internos de aquellos que se encuentran en zonas más expuestas de la red.

4. Diseño de direccionamiento IP

Para garantizar una infraestructura organizada y fácilmente administrable, se ha definido un esquema de direccionamiento IP estructurado que separa los distintos segmentos de red según su función dentro del laboratorio. Esta organización permite simplificar la gestión de los servicios y facilita la identificación de los distintos sistemas desplegados. La red del laboratorio se encuentra segmentada en dos subredes principales gestionadas por el firewall IPFire:

• Red interna (GREEN): destinada a los servidores de infraestructura y a los equipos cliente.

• Red DMZ (ORANGE): destinada a los servicios que se encuentran aislados de la red interna.

Cada una de estas redes utiliza un rango de direcciones IP distinto, lo que permite aplicar políticas de seguridad y control de tráfico entre segmentos de red. Red GREEN – Infraestructura interna La red GREEN utiliza el rango de direcciones 192.168.10.0/24, donde se encuentran los servicios principales de la infraestructura, como los servidores DNS, el servidor DHCP y los sistemas de administración y monitorización. Dispositivo Función Dirección IP IPFire Puerta de enlace de la red interna 192.168.10. bastion Servidor de acceso administrativo 192.168.10. zabbix Servidor de monitorización 192.168.10. dns1 Servidor DNS principal 192.168.10. dns2 Servidor DNS secundario 192.168.10.

Autor: Javier Cuenca Pérez Para facilitar la comprensión y la trazabilidad del procedimiento, este apartado se dividirá en varias fases, incluyendo la preparación de las máquinas, la instalación del software necesario, la configuración de zonas DNS y la implementación de la transferencia de zona entre el servidor principal y el secundario. 5.1 Preparación de las máquinas virtuales Para implementar la infraestructura DNS redundante se han desplegado dos máquinas virtuales dentro de la red GREEN del laboratorio. Estas máquinas serán las encargadas de proporcionar el servicio de resolución de nombres a los dispositivos de la red interna. Ambos servidores se han instalado utilizando Debian GNU/Linux como sistema operativo base, debido a su estabilidad, seguridad y amplia adopción en entornos de servidores. Cada máquina ha sido configurada con una dirección IP estática dentro del rango de la red interna, garantizando así que los servicios de infraestructura mantengan siempre la misma dirección en la red. Las máquinas virtuales utilizadas para este servicio son las siguientes:

Servidor Función Dirección IP Red

dns1 Servidor DNS principal (Master) 192.168.10.20 GREEN

dns2 Servidor DNS secundario (Slave) 192.168.10.21 GREEN

Ambos servidores utilizan como puerta de enlace el firewall IPFire, el cual actúa como router entre las distintas redes del laboratorio.

Parámetro Valor

Gateway 192.168.10.

Máscara de red 255.255.255.

Dominio interno lab.local

Durante esta fase inicial también se ha procedido a verificar la conectividad de red entre los distintos sistemas del laboratorio, asegurando que ambos servidores DNS pueden comunicarse correctamente con el firewall y con el resto de equipos presentes en la red interna. Para comprobar la conectividad básica se han realizado pruebas de red utilizando el comando ping hacia la puerta de enlace y entre los propios servidores DNS.

Autor: Javier Cuenca Pérez 5.2 Instalación del servidor DNS (BIND9) Una vez preparadas las máquinas virtuales destinadas a proporcionar el servicio DNS dentro de la infraestructura, el siguiente paso consiste en instalar el software que permitirá gestionar la resolución de nombres en la red. Para este proyecto se utilizará BIND9 (Berkeley Internet Name Domain), uno de los servidores DNS más utilizados en sistemas Linux y ampliamente adoptado en entornos profesionales. La instalación del servicio DNS se realiza en ambos servidores, tanto en el servidor principal (dns1) como en el servidor secundario (dns2), ya que ambos formarán parte de la infraestructura de resolución de nombres. En primer lugar, se actualiza la lista de paquetes disponibles en el sistema para asegurar que el software se instala desde los repositorios más recientes. A continuación se instala el servidor DNS junto con herramientas de administración. Verificamos su funcionamiento con systemctl. Una vez completada la instalación del software en ambos servidores, el siguiente paso será proceder con la configuración del servidor DNS principal (dns1), donde se definirán las zonas DNS que serán utilizadas dentro del laboratorio.

Autor: Javier Cuenca Pérez Mediante estos registros se establece la resolución de nombres para los distintos servicios del laboratorio, permitiendo acceder a ellos mediante nombres de dominio en lugar de direcciones IP. Por ejemplo para entrar al Nextcloud usaríamos nextcloud.lab.local, que sera resuelto por el servidor DNS hacia la dirección IP correspondiente al host. Validación de la configuración Antes de reiniciar el servicio DNS es recomendable comprobar que la configuración y el archivo de zona no contienen errores. Para ello se pueden utilizar las herramientas incluidas en BIND9: Si no se detectan errores reiniciamos el servicio Con esto, el servidor dns1 queda configurado como servidor DNS principal del laboratorio y preparado para resolver las consultas de nombres realizadas por los clientes de la red interna. Comprobamos que entra con el dns… 5.4 Configuración del servidor DNS secundario (Slave) El segundo servidor DNS se configura como servidor secundario (Slave) con el objetivo de mantener una copia sincronizada de las zonas DNS definidas en el servidor principal. Esta configuración permite garantizar la disponibilidad del servicio de resolución de nombres en caso de fallo del servidor principal. El servidor dns2, ubicado en la red interna con dirección IP 192.168.10.21, obtendrá automáticamente la información de las zonas DNS desde el servidor dns1 mediante el mecanismo de transferencia de zona (Zone Transfer) proporcionado por BIND9. Para configurar el servidor secundario se edita el archivo de configuración local del servicio DNS:

Autor: Javier Cuenca Pérez Lo editamos: En esta configuración:

• type slave indica que el servidor actuará como servidor DNS secundario.
• masters especifica la dirección IP del servidor DNS principal desde el cual se obtendrá la zona.
• file define la ubicación donde se almacenará localmente la copia de la zona transferida. Y reiniciamos servicios: Tras reiniciar el servicio, el servidor dns2 solicitará automáticamente la zona al servidor dns1, creando una copia local que permitirá responder a las consultas DNS de los clientes de la red. Para verificar que la transferencia de zona se ha realizado correctamente se puede comprobar la presencia del archivo de zona en el directorio de cache del servidor:

1. Configuración del servidor DHCP

En este apartado se implementará el servicio DHCP (Dynamic Host Configuration Protocol)

con el objetivo de automatizar la configuración de red de los equipos cliente dentro del

laboratorio. Mediante este servicio, los dispositivos que se conecten a la red interna podrán

obtener automáticamente una dirección IP, la máscara de red, la puerta de enlace y los

servidores DNS configurados previamente.

El servidor DHCP se desplegará en la red GREEN, donde también se encuentran los

servidores DNS y el resto de servicios internos de la infraestructura. Esto permitirá que los

equipos cliente obtengan automáticamente la información necesaria para comunicarse con

el resto de los sistemas del laboratorio.

Entre los parámetros que el servidor DHCP proporcionará automáticamente a los clientes se

encuentran:

Autor: Javier Cuenca Pérez

Definimos la interfaz de red

Añadimos nuestra interfaz ens18 o eth0, la que tengamos, esto se puede ver haciendo ip a

Configurando el servidor DHCP

Modificamos lineas:

Reiniciamos servicio y comprobamos

Autor: Javier Cuenca Pérez

Probando desde la VM BASTION

Instalamos paquete dhcp cliente

Solicitamos una IP al servidor DHCP

Deberíamos ver el proceso de solicitud, algo asi:

Con ip a podemos ver que el server nos asigno la primera ip, tambien vemos que aun

tenemos la ip de antes asignadas porque aun la tenemos en modo static en el archivo de

interfaces, vamos a modificarlo

Modificamos con nano y lo ponemos en dhcp

Reiniciamos servicio o reboot

Autor: Javier Cuenca Pérez

8. Integración DHCP + DNS dinámico

Una vez desplegados los servicios DNS y DHCP, es posible integrar ambos sistemas para

permitir el registro automático de los dispositivos que obtienen direcciones IP mediante

DHCP. Este mecanismo se conoce como Dynamic DNS (DDNS).

Mediante esta funcionalidad, cuando un dispositivo solicita una dirección IP al servidor

DHCP, este puede registrar automáticamente el nombre del host en el servidor DNS,

creando o actualizando los registros correspondientes.

Este proceso permite que los dispositivos de la red interna puedan ser accesibles mediante

nombres de dominio sin necesidad de crear manualmente cada registro DNS.

Por ejemplo, si un cliente con nombre cliente1 obtiene una dirección IP mediante DHCP,

el servidor puede registrar automáticamente el siguiente registro en el DNS:

cliente1.lab.local → 192.168.10.

Esta funcionalidad mejora la automatización de la infraestructura y facilita la gestión de

dispositivos en redes con un gran número de clientes.

Para hacerlo, hay que configurar:

• una clave TSIG compartida entre DNS y DHCP
• permisos de actualización en BIND
• zonas en DHCP

8.1 Crear la clave TSIG en dns

Guardamos la clave sha

8.2 Añadir la clave en BIND (Master)

8,3 Crear la zona inversa en dns

Ahora añadiremos también una zona inversa para que DHCP pueda registrar PTR

Autor: Javier Cuenca Pérez

8,4 Creamos el archivo de zona inversa con nano /etc/bind/db.192,168,

8.5 Damos permisos al archivo

8,6 Validamos y reiniciamos servicios

8.7 Configurando el servidor DHCP para actualizaciones automáticas dinámicas

Añadimos o editamos lineas:

Autor: Javier Cuenca Pérez

Forzamos renovación de DNS en el cliente

Diagnosticamos...

9. Pruebas de disponibilidad DNS

Autor: Javier Cuenca Pérez

Antes de desconectar master comprobamos con dig desde que server estamos recibiendo

dns

Desconectamos el servidor DNSMaster(192,168,10,20)

Esperamos unos segundos hasta que reconecte con el server Slave(192,168,10,21)