miércoles, 7 de diciembre de 2016

Crear tabla de rutas y cambiar reglas de Firewall


Cuando el servidor recibe información, este la encamina a la dirección indicada; si es una dirección de dentro de su red, la enviará por la interfaz de la red local y, si es otra dirección desconocida, la envía al exterior.

El problema es que nuestro servidor sólo reconoce como direcciones de su propia red a las direcciones 192.168.100.0/24, es decir, a las direcciones de nuestra subred 10.0.116.0/24 no las reconocerá como red interna.

Para cambiar esto crearemos una tabla de rutas.




En ajustes de red/ajustes de IPv4/Rutas nos encargaremos de indicarle al servidor la dirección de la tarjeta de red que da a aula116 para que, cuando el servidor tenga que enviar información a direcciones de este segmento de red, lo reconozca como una dirección de su red y no la envíe al exterior de vuelta.



Introduciremos los siguientes datos a la tabla de rutas.





Ahora, cuando el servidor reciba un mensaje hacia la nuestro segmento de red aula116 lo reconocerá como dirección de su propia red y lo encaminará a su destino.


Una vez creada la tabla de rutas, estableceremos una serie de reglas en nuestro Firewall para que PFsense permita que todo el proceso de transmisión funcione correctamente.

Entraremos en Firewall/Rules/WAN

Añadimos regla.

Dejamos todo igual y en protocolo ponemos Any.





Acudimos a Interfaces/WAN y desmarcamos las dos casillas de abajo.




De este modo ya tendremos el Firewall configurado correctamente.

Centralizar DHCP y DNS en un servidor

Hasta ahora, tanto PFSense como el servidor DNS se encargaban cada uno de otorgar las distintas direcciones de red para su propio segmento de red. Lo que pretendemos hacer en esta práctica es que el servidor principal sea el único que se encargue de otorgar direcciones de red automáticamente, tanto en la red principal como en las demás subredes.

Para ello necesitaremos entrar en Webmin desde el servidor principal y acudir a DHCP server.

Crearemos una subred donde introduciremos los siguientes parámetros:



Aquí le estamos diciendo al servidor que la dirección 10.0.116.0 es una subred, además estamos detallando el rango de direcciones que puede contener esta subred.

Una vez guardado, seleccionaremos DHCP server/subred 10.0.116.0/Edit Client Options




Nos aparecerá una ventana en la que introduciremos la siguiente información:




Con esto el servidor será el único encargado de resolver las peticiones de toda la red local, por lo que se centraliza la caché y facilita la configuración.

Ahora acudiremos a la interfaz del PFSense para habilitar DHCP Relay, lo que hará que cuando reciba una solicitud de DHCP este lo reenvíe al verdadero servidor DHCP (servidor principal).


Primero deshabilitaremos DHCP en PFSense y seguidamente activaremos DHCP Relay.






Ahora tenemos los servicios centralizados en el servidor principal, aún así el servidor no será capaz de detectar la red 10.0.116.0 ya que el servidor sólo escucha la red 192.168.100.0 por defecto, para solucionar esto será necesario agrupar todas las redes.

En nuestro servidor, acudiremos a BIND  y utilizaremos la herramienta ACL (acces control list). Esta se encarga de definir quién tendrá permisos de acceso.



Introduciremos los siguientes datos:




Ahora introduciremos un allow query para que allaulas, que engloba todas nuestras redes, tenga permitido consultar el servidor de nombres.

Iremos a BIND/Edit Config File y entraremos en el fichero options. Introduciremos los datos que aparecen en la siguiente imagen:




Guardaremos y aplicaremos configuración.


Deshabilitar NAT en router PFSense

Hasta ahora, nuestro router se encargaba de hacer NAT con todas las direcciones que le llegaban desde dentro del nuevo segmento de red, esto no nos interesa porque queremos saber exactamente qué máquina está enviando información a los equipos de dentro de la red local, solamente necesitamos que haga NAT el servidor DNS.

Para deshabilitarlo acudiremos a la máquina virtual portatil, que está en el nuevo segmento de red, y accederemos al router desde ahí, ¿cómo podemos acceder? simplemente accediendo al navegador e introduciendo la IP de nuestro router PFsense.



Por defecto el usuario es admin y la contraseña pfsense.

Una vez dentro, acudiremos a Firewall/NAT/outbound.




Guardaremos los cambios y ya lo tendremos deshabilitado.


miércoles, 30 de noviembre de 2016

Nueva estructura de red. PFSense

Tenemos la intención de crear otro segmento de red para otras máquinas nuevas, queremos que esta sección se conecte a una misma red interna llamada "aula116"y esté conectado a un router diferente.

Este router recibirá una IP automática del servidor DHCP, y proporcionará una IP automática con rango de 10.0.116.101 a 10.0.116.131 pero no tendrá NAT, puesto que nuestra intención es que las máquinas de esta sección puedan enviar información a través de la red local a máquinas de otras secciones de red (con NAT enmascararía la dirección y no nos interesa de cara a la red local).

Vamos a hacer una explicación completa de cada elemento de la red. En conjunto, este es el esquema completo de la red que deseamos tener.



Empezaremos con las características del segmento de red antiguo, que son las máquinas que hicimos en las primeras entradas.

- El servidor DNS tiene 2 tarjetas de red, una conectada a la red interna aulaser  con IP fija 192.168.100.254 máscara 24 y la otra en DHCP, esta será la puerta al exterior de toda la red local.

En Webmin, habremos configurado los parámetros necesarios para que este funcione como
DHCP, accedemos a  Webmin/DHCP Server/Manually Edit Configuration


Nos aparecerá un fichero, en el cual borraremos toda la información e introduciremos lo siguiente:




- El cliente estará configurado como hicimos en entradas anteriores

- El servidor del nuevo segmento de red, que es el router PFSense, lo configuraremos de la siguiente forma:


2. Set interfaces IP address.




Introduciremos la IP de la tarjeta de red que da a la red interna del nuevo segmento de red (10.0.116.254).



Permitiremos DHCP en el router para que asigne direcciones automáticas al nuevo segmento de red.




Introduciremos el rango de IPs que queremos que asigne a los equipos que se conecten a este segmento.





Y finalizaremos la configuración.




Ya habremos configurado el router PFSense, por el momento.



- Respecto al Portatil, es una máquina clonada del cliente que configuramos en las primeras prácticas, con una mac diferente que tendremos que conocer y con la tarjeta de red puesta en red interna y configurada para que busque automáticamente la IP a asignar (automática DHCP).




jueves, 24 de noviembre de 2016

Práctica: Montando servidores. Sun y Marte

En esta práctica montaremos un servidor principal en una máquina cliente llamada "marte" y un servidor secundario que contendrá una copia de la información del servidor principal, la cual denominaremos "sun". Además se instalarán dos nodos adheridos al servidor principal con diferentes servicios, uno de los nodos se llamará "earth" y el otro "jupiter".

Para iniciar esta práctica necesitaremos dos máquinas virtuales con ubuntu o derivados, una de ellas con dos tarjetas de red; tener instalado Webmin y BIND y haber habilitado forwarding tal como hemos hecho en posts anteriores, con la diferencia de que las IP's para el servidor y el cliente del otro post las cambiaremos por las de sun y marte respectivamente, tal como aparece en la imagen.




MARTE


Empezamos con la máquina marte abriendo Webmin desde el explorador (localhost:10000) y entramos en Servers/BIND DNS Server. Entre las múltiples opciones del menú Global Server Options nos interesa empezar con el que tiene aspecto de mando, el llamado Setup RNDC, esta opción nos permite actualizar las zonas sin necesidad de reiniciar cada vez el BIND. 

Pulsaremos Yes, Setup RNDC para aplicarlo.

Una vez terminado este paso toca empezar con las zonas maestras. En el menú principal de BIND hay un apartado que toquetearemos bastante de ahora en adelante situado al inferior del menú, Existing DNS Zones.

 Vamos a crear la primera zona maestra, desde Create master zone se abrirá una ventana 
Introduciremos los datos de la zona maestra (marte) tal como figura en la pantalla de arriba, crearemos la zona y nos aparecerá el nuevo menú perteneciente a esta zona, donde introduciremos los datos de la zona secundaria también llamada sun.



Haremos click en Name Server e introduciremos lo siguiente:




El punto al final del nombre de servidor indica que es un FQDN.

Una vez creadas las dos zonas principales, volveremos al menú principal de BIND y comprobaremos que aparece solarsystem.edu en la sección de Zonas.

Ahora crearemos una zona inversa, volveremos a Create master zone como en pasos anteriores e introducimos lo siguiente:



Al igual que con la anterior creación de zona, nos aparecerá el menú de esta y de nuevo entraremos en Name Server.





El @ indica que estamos hablando de la zona a la que pertenece, será necesario conocer este término para más adelante.

Si nos fijamos en la dirección de abajo, vemos que la dirección aparece invertida.

Ahora iremos al menú principal de BIND observaremos que ya tenemos creadas tanto la zona solarsystem.edu como la zona 10.116.





AGREGAR DIRECCIONES DE RESOLUCIÓN DIRECTA


Ahora que tenemos la estructura principal de los servidores principales, toca agregar las direcciones de resolucíón directa. Iremos a la zona solarsystem.edu y entraremos en Address.

Introduciremos los datos como aparece en la imagen. Recordad hacer click en "Yes (and replace existing)" y crearemos. Seguiremos así con las tres direcciones restantes:






Ya tenemos las cuatro direcciones introducidas satisfactoriamente.





ASOCIAR SERVICIOS 


Para continuar necesitaremos acudir de nuevo a la zona maestra solarsystem y entrar en la opción "Name Alias".

La zona Name Alias nos permite asociar un servicio con un nombre (que es una dirección al mismo tiempo).

Dicho esto, nuestro trabajo ahora es relacionar los cinco servicios que aparecen en el esquema del principio con su respectivo nombre (dns1 para marte; dns2 para sun; www y ftp para jupiter; smtp para earth) de la siguiente forma:









MAIL SERVER


Estamos muy cerca de acabar con la configuración de la zona solarsystem.edu, el siguiente paso es hacer que el servicio de MX de earth funcione.

El registro MX hace referencia a los servidores a los que enviar un correo electrónico, y a cuál de ellos debe ser enviado primeramente, por orden de prioridad.

En la zona solarsystem.edu, donde hemos metido todos los registros anteriores, acudiremos al apartado Mail Server e introduciremos lo siguiente:


Priority debe ser un número no nulo.


ya tenemos todos los registros de las zonas correctamente, toca transferir la zona, pero primero permitiremos que esta pueda hacerlo.


En la zona solarsystem.edu pulsaremos esta opción

Nos aparecerán las opciones de zona, donde le pediremos que nos permita la transferencia desde 10.116.255.254




Ya tenemos los registros y la zona preparada, la zona solarsystem.edu quedará de la siguiente manera:




OPTIMIZAR ZONAS


Nos interesa modificar una serie de parámetros para permitir una operabilidad más óptima en caso de que hayan cambios en un futuro, por eso vamos a cambiar los registros de zona a continuación.

Primero acudiremos a la opción Edit Recors File del menú de la zona solarsystem.edu, aparecerá el siguiente archivo:

Cambiaremos el archivo para que resulte así:






Y del mismo modo, modificaremos el archivo de zona de 10.116 desde el menú de BIND→10.116→Edit Records File.


El hecho de que el archivo tenga una extensión .rev nos indica que contiene direcciones inversas, continuaremos como hemos hecho con el otro archivo de zona y haremos que quede así:



Si queremos verificar que lo hemos hecho correctamente bastará con acudir a Check Records y nos dirá si está todo en orden.

DNSSEC


El siguiente paso será volver al menú prncipal de BIND y entrar en la opción DNSSEC Verification.

 Tanto a la opción "DNSSEC ENABLED?" como "DNSSEC response validation enabled?" le diremos que no.

¡Ya está! sólo nos queda actualizar la configuración de red que teníamos para que la máquina tenga conexión tanto con la máquina sun como con internet.

Lo configuraremos de la siguiente forma:














SUN

 El trabajo que tendremos que hacer en esta máquina es mucho menos laborioso, puesto que sólo necesitamos crear dos zonas esclavas y transferir las zonas, además de configurar las tarjetas de red de nuevo y denegar el DNSSEC.

Primeramente accederemos a Webmin→Servers→BIND  y haremos click en Create Slave Zone en la zona inferior de la página.

La primera zona será de resolución directa y la crearemos tal que así:


 Como ya conocemos todo el proceso no me andaré por las ramas. Crearemos otra zona pero esta vez de resolución inversa.




En los menús de cada zona esclava habrá una opción diferente a las zonas maestras, llamada Test Zone Transfer, le daremos y si todo sale bien las zonas quedarán transferidas.


Nuestras tarjetas de red tienen que ser modificadas, para la red WAN la configuraremos así:


Y en la red  LAN sólo cambiaremos estos parámetros:


Una vez configurado, reiniciaremos BIND  y haremos la misma configuración que hicimos con DNSSEC en la máquina de marte.




COMPROBAR FUNCIONAMIENTO




Ahora necesitamos saber si las máquinas están bien configuradas y responden correctamente a nuestras peticiones. Si todo va bien al introducir los siguientes comandos en los terminales de estas deberían dar una respuesta parecidaa esta:


Sun> ping marte

Sun> dig solarsystem.edu MX

Marte> ping sun

Marte> dig -x 10.116.1.205



Ya tenemos nuestros servidores montados correctamente.