Tareas #6212

Tareas #6160: Implementación de la solución tecnológica

Tareas #6211: Implementación de los servicios

Servicios de infraestructura

Added by Victor Alem 7 months ago. Updated 4 months ago.

Status:ResueltaStart date:05/16/2019
Priority:NormalDue date:
Assignee:TLecom% Done:

90%

Category:-Spent time:-
Target version:-

dns1.png (137 KB) Junhor Archondo, 05/28/2019 03:59 PM

dns2.png (135 KB) Junhor Archondo, 05/28/2019 03:59 PM

dns3.png (118 KB) Junhor Archondo, 05/28/2019 03:59 PM

dns4.png (143 KB) Junhor Archondo, 05/28/2019 03:59 PM

dns5.png (90.9 KB) Junhor Archondo, 05/28/2019 03:59 PM

dhcpdefault.png (76.4 KB) Leonardo Olivera, 06/10/2019 01:33 PM

dhcp_dominio.png (29.4 KB) Leonardo Olivera, 06/10/2019 02:16 PM

subredservicios.png (21.7 KB) Leonardo Olivera, 06/10/2019 02:37 PM

estaticas.png (52.8 KB) Leonardo Olivera, 06/10/2019 02:54 PM

estaticas1.png (26.9 KB) Leonardo Olivera, 06/10/2019 02:55 PM

subredadmin.png (18.8 KB) Leonardo Olivera, 06/10/2019 03:28 PM

subredvoip.png (15.9 KB) Leonardo Olivera, 06/10/2019 03:30 PM

dhcprelay.png (211 KB) Leonardo Olivera, 06/10/2019 03:59 PM

instalacionrelay.png (143 KB) Leonardo Olivera, 06/10/2019 04:02 PM

dhcrelayconfigurado.png (66.9 KB) Leonardo Olivera, 06/10/2019 04:11 PM

dns7.png (127 KB) Junhor Archondo, 06/20/2019 07:06 PM

dns6.png (160 KB) Junhor Archondo, 06/20/2019 07:06 PM

dns8.png (141 KB) Junhor Archondo, 06/20/2019 07:06 PM

dns9.png (136 KB) Junhor Archondo, 06/20/2019 07:06 PM

dhcprelay2.png (134 KB) Junhor Archondo, 07/25/2019 05:31 PM

dhcp_dominio2.png (41.4 KB) Junhor Archondo, 08/01/2019 04:44 PM

4232
4233
4234
4235
4236
4283
4284
4286
4287
4288
4289
4290
4292
4293
4294
4318
4319
4320
4321
4433
4458

Related issues

Related to 2019 - TLecom - Tareas #6168: DHCP y DNS Cerrada

History

#1 Updated by Victor Alem 7 months ago

#2 Updated by Junhor Archondo 6 months ago

DNS

Instalación:

Instalamos bind9 para tener un servicio DNS.
Primero actualizamos los repositorios, con el siguiente comando:

$ apt-get update

Instalamos bind9 con el siguiente comando:
$ apt-get install bind9


Configuración de las zonas:

La siguiente configuración avanzada de BIND es apta para un servidor Debian con número IP estático y conectado permanentemente a Internet.
Para definir un nuevo dominio y hacer que el servidor actúe como su DNS autoritativo, primero se necesita haber comprado un dominio en un registro de nombres de dominio y definir el servidor de nombres primario del nuevo dominio con el número IP y FQDN del servidor BIND.
En nuestro caso el dominio que utilizamos es: tlecom.cure.edu.uy.
BIND, a pesar de ser un servidor DNS, funciona en base a zonas y no dominios. Una zona es una parte del árbol de dominios sobre el cual el servidor tiene total información y autoridad. Contiene todos los nombres de dominio a partir de cierto punto del árbol.
Entonces, agregamos la zona directa que vamos a administrar en el archivo de configuración local de BIND (/etc/bind/named.conf.local), también agregamos su zona inversa para que puede responder pedidos en ambos sentidos.

Se puede observar en la imagen que llamamos a la zona como el dominio y es de tipo “master”, porque ésta zona contiene los datos de todos los dominios que cuelgan a partir de la etiqueta “tlecom” e indicamos que se encuentran en el archivo /etc/bind/db.tlecom.cure.edu.uy. Además permite cualquier consulta.
Se sigue el mismo procedimiento para crear la zona inversa.
Una vez definidas nuestras zonas primarias, pasamos a crear sus correspondientes archivos donde detallaremos la zona.

Archivo de configuración de la zona directa:

En el directorio /etc/bind / creamos el archivo de la zona “tlecom.cure.edu.uy”, utilizamos el siguiente comando:

$ touch  db.tlecom.cure.edu.uy


Luego abrimos el archivo de texto recién creado y lo dejamos como se aprecia en la siguiente imagen.
Los archivos de zona contienen información sobre un espacio de nombres particular y es nombrado de acuerdo a la opción file en la declaración zone en el archivo de configuración local.
Cada archivo de zona contiene directivas y registro de recursos. Las directivas le dicen al servidor de nombre que realice tareas o aplique configuraciones especiales a la zona, las mismas son opcionales. Los registros de recursos son obligatorios para proporcionar los servicios, definen los parámetros de la zona y asignan identidades a hosts individuales.
Los comentarios se realizan después del símbolo “;”.
Las directivas comienzan con el símbolo “$”, seguido de su respectivo nombre. En este caso agregamos la directiva “$TTL”, es el tiempo en segundos que un registro de recurso de zona es válido.
Luego pasamos a definir el registro de recursos de la zona.
El registro SOA (Start of Authority) es el primero en el archivo de zona y sólo puede haber uno en cada archivo de la zona. Sólo está presente si el servidor es autoritario del dominio, declara la información de autoridad. El símbolo @ equivale a la directiva “$ORIGIN” o al nombre de la zona como el espacio que está siendo definido por el registro SOA.
Seguido colocamos el nombre del host del servidor de nombres que tendrá autoridad para este dominio, es decir, el servidor DNS primario del dominio y su administrador (también puede ser el correo del administrador).

Directivas a tener en cuenta:

• Serial: es un identificador del archivo, puede tener un valor arbitrario pero se recomienda que tenga la fecha con una estructura AAAA-MM-DD y un consecutivo. Cada vez que entramos al archivo a modificar algo tenemos que cambiar el consecutivo que hay después de la fecha por su siguiente.
• Refresh: número de segundos que un servidor de nombres secundario debe esperar para comprobar de nuevo los valores de un registro.
• Retry: número de segundos que un servidor de nombres secundario debe esperar después de un intento fallido de recuperación de datos del servidor primario.
• Expire: número de segundos máximo que los servidores de nombre secundarios retendrán los valores antes que expiren.
• Negative Cache TTL: es el número de segundos que los registros se mantienen activos en los servidores NS caché antes de volver a preguntar su valor real.
Después de tener definido el registro SOA, agregamos los demás registros. Para ello colocamos el nombre del host, seguido del tipo de registro y su IP correspondiente. Aquí agregamos los servicios de los otros compañeros.

Otros tipos de registros utilizados son:
A: es una IP asociada a una etiqueta.
MX: es el nombre de la máquina que recibe correo para un dominio.
NS: es el nombre del servidor de nombres para este dominio.
CNAME: es el alias (apodo) de una etiqueta.
PTR: es el nombre asociado a una dirección IP.

Archivo de configuración de la zona inversa:

Creamos el archivo de la zona inversa, el cual se utiliza para traducir una dirección IP en un nombre de dominio. Es muy similar a un archivo de zona estándar, excepto que se usan registros de recursos de tipo PTR para relacionar las direcciones IP a un nombre de dominio completamente cualificado (FQDN).
Para crear el archivo de configuración de la zona inversa hay que tener en cuenta si en el archivo name.conf los octetos de la red en los cuales se está trabajando están puestos a la inversa.
Ponemos los 3 primeros octetos a la inversa de la dirección 164.73.226.196, obtenemos 226.73.164 y en el archivo de configuración ponemos solo el octeto faltante.
En el directorio /etc/bind / creamos el archivo de la zona inversa, utilizamos el siguiente comando:

$ touch   db.226.73.164.in-addr.arpa

Luego abrimos el archivo de texto recién creado y lo dejamos como se aprecia en la siguiente imagen.

DNS asignado por ISP:

ISP (Internet Service Provider) es un proveedor de servicios en Internet el cual nos permite utilizar un DNS público para el exterior. Es una configuración opcional, pero es útil utilizarla ya que tiene ciertas ventajas como la velocidad de respuesta y su estabilidad.
Para utilizarlo, configuramos el archivo /etc/bind/named.conf.options.
Descomentamos la línea “forwarders” y agregamos los servidores de nombres, elegimos Google Public DNS.
Aparte de habilitar el ISP, agregamos una condición para permitir únicamente que las máquinas internas realicen consultas del DNS, para estar más protegidos y no ser visibles en el exterior de nuestra red.
Se pueden mantener ambos servicios de DNS, el primario es necesario para que nuestra red funcione, el ISP es opcional.

Después de las configuraciones realizadas reiniciamos el servicio con el siguiente comando:

$ /etc/init.d/bind9 restart

Verificación:

El comando host sirve para realizar búsquedas DNS que traducen nombres de dominio a direcciones IP y viceversa. También se puede utilizar para enumerar y verificar varios tipos de registros DNS como NS y MX, probar y validar el servidor DNS del ISP y la conectividad a Internet, registros de correo no deseado y listas negras, detección y resolución de problemas del servidor DNS, entre otros.

Referencias:

https://proyectos.interior.edu.uy/projects/gestion-de-la-sala-de-telecomunicaciones/wiki/DNS_configuraci%C3%B3n
https://proyectos.interior.edu.uy/issues/6168
https://proyectos.interior.edu.uy/projects/gestion-de-la-sala-de-telecomunicaciones/wiki/DNS_y_DHCP
http://transparencia.munilaunion.cl/Documentos/CostosReprod/23988467-DNS-BIND9.pdf

#3 Updated by Victor Alem 6 months ago

Junhor, muy buen trabajo, esta tarea cumple con todo lo que charlamos en clase, investigación, implementación y cómo verificar.

#4 Updated by Leonardo Olivera 6 months ago

DHCP
instalacion
Para poder instalar el servicio dhcp abrimos una terminal en el servidor de servicios como root e ingresamos el comando:

apt-get install isc-dhcp-server

Luego de instalado el servicio comenzamos a configurarlo.

configuracion
Lo primero es editar el archivo /etc/default/isc-dhcp-server con permiso de root, especificando la interfaz por la cual brindaremos el servicio DHCP.

INTERFACES="eth0"

Despues de agregar la interfaz pasamos a configurar el archivo principal de configuracion del servidor DHCP, dhcpd.conf que se encuentra en /etc/dhcp/.

Comenzamos agregando las siguientes lineas:

default-lease-time 600;
max-lease-time 7200;

En esas lineas especificamos el tiempo por defecto de alquiler de la dirección IP brindada y el tiempo máximo de alquiler. Es decir, el tiempo por defecto es el tiempo mínimo que le da el servidor a un cliente para que use la IP y el otro es el tiempo máximo por el cual el servidor le dará esa IP. Cuando se sobrepasa este límite de tiempo, el servidor le pregunta al cliente si va a desear quedarse con la IP nuevamente.

Luego agregamos las siguientes lineas que seran: el nombre del dominio y la direccion ip del dominio.

option domain-name "www.tlecom.cure.edu.uy";
option domain-name-servers 164.73.128.8;

#5 Updated by Leonardo Olivera 6 months ago

#6 Updated by Leonardo Olivera 6 months ago

Luego de establecer los parámetros mencionados, proseguimos a configurar las subred, es decir, configurar el rango de IPs que nuestro servidor DHCP brindara de forma dinámica.

DHCP dinamico

1- Especificar la subred y la máscara.
2- Especificar el rango de IPs que el servidor va a brindar, el mismo debe estar dentro de la subred anteriormente establecida.
3- Especificar la dirección del router que deben usar los clientes.
4- Especificar la máscara de red que utilizaran los clientes.
5- Especificar la dirección de broadcast que utilizaran los clientes

Ips estaticas
Para asignar ips fijas a un equipo cuando se conecta a la red debemos escribir el nombre de nuestro host, su mac y la ip que le asignaremos.
Nota: la configuración de las IPs estáticas se puso dentro del bloque de la subred previamente configurada ya que pertenecen a la misma red.


Con esto nuestro dhcp esta listo para dar las ip dentro de la subred de Servicios, pero tambien voy a necesitar que las de dentro de la subred de Administracion y dentro de la subred de Voip.

Subred Administracion y Voip
De igual manera creo la subred de Administración y la subred de Voip en el archivo dhcpd.conf


NOTA: Aca voy a tener un problema ya que el servidor dhcp esta en la red de Servicios y solo les dará ip a los equipos en dicha red.

Una vez terminada la configuracion debemos reiniciar el servicio con el siguiente comando:

/etc/init.d/isc-dhcp-server restart

DHCP Relay
Es un protocolo usado por si tienes otro servidor de DHCP en la red. Esta sirve para que todas las peticiones que le lleguen a tu router sean reenviadas hacia el otro equipo.

En nuestro caso debemos colocar el dhcp relay en el router para que los pedididos de ips de las subredes de Administracion y Voip que vayan al router sean redirigidos a nuestro servidor dhcp en la red de Servicios.

instalacion dhcprelay
Lo primero que hago es revisar en la pagina de openwrt el paquete disponible de dhcprelay para instalar en el router.

Ahora sabiendo cual es el paquete a descargar me conecto al router por la interfaz grafica e instalo dicho paquete.

configuracion
El archivo para la configuracion de dhcp relay es dhcrelay se encuentra en /etc/config/

Los campos a modificar son:

option 'enabled' '1' Para habilitar el servicio.
option 'dhcpserver' '164.73.226.196' Se especifica la direccion del servidor dhcp que el relay usara para reenviar las
peticiones de los clientes.
option 'interfaces' 'Admin Voip' Se indican los nombres de las interfaces de red que intervienen en el proceso de
retransmisión.
option 'upstream_interfaces' 'Servicios' Colocamos la interfaz donde se encuentra el servidor
option 'downstream_interfaces' 'Voip Admin' Colocamos las interfaces que necesitan hacer el pedido al relay para llegar al servidor.
option 'relay_mode' 'replace'
option 'link_selection' 'wan' lo dejamos por defecto

NOTA: Ahora si con el dhcp relay configurado ya podemos asignarle las ips con nuestro servidor dhcp a los clientes de las 3 subredes (Servicios, Administracion y Voip) .

#8 Updated by Victor Alem 6 months ago

  • Status changed from Nueva to En curso

Perfecto Leo! Si les parece que está terminado, podemos marcar como resuelta la tarea. Estaría muy bien generar un procedimiento de verificación de que todo funciona. Hoy pensamos un poco en eso y queda pendiente escribirlo.

#9 Updated by Victor Alem 6 months ago

El servicio DNS está funcionando algo raro.. Dejo abierta la tarea por esto. Además, el servicio DNS tiene que resolver sobre cualquier consulta a la red de la empresa, y solo responderle al mundo sobre su zona de autoridad. Esto había quedado pendiente de la clase pasada.

#10 Updated by Junhor Archondo 6 months ago

#11 Updated by Mariano Hernández 6 months ago

  • % Done changed from 0 to 90

#12 Updated by Junhor Archondo 5 months ago

  • File dhcprelay.png added

#13 Updated by Junhor Archondo 5 months ago

  • File deleted (dhcprelay.png)

#14 Updated by Junhor Archondo 5 months ago

#15 Updated by Junhor Archondo 4 months ago

#16 Updated by Junhor Archondo 4 months ago

  • Status changed from En curso to Resuelta

Also available in: Atom PDF