Después de los dos primeros artículos (Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte I de IV), Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte II de IV)) de los que consta esta serie de 4, vamos a ver uno de los más comunes (no recomendados) esquemas de red en las pequeñas empresas (pulsar en la imagen para verla a tamaño real):
En este tercer artículo vamos a trabajar sobre esta topología
(pulsar en la imagen para verla a tamaño real):
Como os comentaba al principio del artículo es la configuración más "típica" entre las PYMES, puesto que con los básico en cuanto a hardware de comunicaciones, implementamos un sistema "igual" que los dos anteriores (salvando las distancias), por lo menos en cuanto a topología a nivel lógico (direccionamiento IP, PortForwarding, etc..). Aquí lo que vamos a cambiar con respecto a la anterior configuración, es que si vamos a poner en TEAM las interfaces dedicadas para las MV, pero ninguna de ellas tendrá etiquetado de VLAN (porque en este caso el switch no lo soporta). En el primero artículo os había dejado un artículo que había publicado en su momento sobre la configuración de TEAM sobre Windows Server 2012, aquí os lo vuelvo a exponer por si no lo habíais leido:
TEAMING en Windows Server 2012 (Actualizado 04-01-2013). Lo único que comentaré aquí a mayores, es que la configuración del TEAM de 3 de las 4 tarjetas de red que tiene el servidor (OJO: la foto pertence al artículo anteriormente citado, lo puntualizo para no confundiros), y el modo del TEAM será
Switch Independent:
Con esta configuración el Switch no sabe que están configurados en TEAMING, de esta forma podemos tener una tarjeta de red conectada a un switch y el resto a otro, etc… esto es lo más cómodo en este caso, puesto que el Switch no tiene gestión. De todas formas, aquí os dejo un enlace de descarga de un documento puede ser de vuestro interés sobre como configurar y administrar los TEAMING con Windows Server 2012:
Una vez que hemos seleccionado el modo del TEAMING, que el Load Balancin Mode lo hemos configurado como Hyper-V Port y que todos los adaptadores está activos, ya tenemos nuestra configuración de Hyper-V y Windows Server finalizada.
Lo siquiente que tenemos que hacer es configurar el Router con dos IPs privadas, en función del router que tengamos pues lo haremos de una u otra forma. Yo como os comentaba anteriormente lo estoy explicando todo con Cisco, así que aquí tenéis la configuración de la interface interna de un Cisco con dos IPs (o más) en la misma interface:
interface FastEhernet0
description Red Local
ip address 192.168.0.1 255.255.255.0
ip address 172.26.0.1 255.255.255.240 secondary
ip nat inside
Como véis es únicamente añadir una segunda (o más IPs) a la inteface y añadir secondary al final de la configuración. Igualmente, lo que sí queremos es que las distintas subredes están comunicadas, para esto crearemos una ACL y se aplicará a la única inteface interna que tiene el router:
- access-list 120 deny ip 192.168.0.0 0.0.0.255 172.26.0.0 0.0.15
- access-list 120 deny ip 172.26.0.0 0.0.15 192.168.0.0 0.0.0.255
- access-list 120 permit ip 172.26.0.0 0.0.15 any
- access-list 120 permit ip 192.168.0.0 0.0.0.255 any
La explicación de esta ACL es sencilla, cada punto que comento a continuación hace referencia a cada ACE configurada en la ACL:
-
Deniega todas las conexiones originadas desde la subred 192.168.0.0/24 hasta la subred 172.26.0.0/28
- Deniega todas las conexiones originadas desde la subred 172.26.0.0/28 hasta la subred 192.168.0.0/24
- Permite cualquier otra comunicación origina desde la subred 192.168.0.0/24
- Permite cualquier otra comunicación origina desde la subred 172.26.0.0/28
Ahora una pregunta para el que quiera contestar: ¿Las dos primeras líneas son necesarias? ¿Complementarias? ¿Necearias? El que quiere responder que deje un comentario y vemos la mejor forma de hacer esto.
Ahora lo único que tenemos que hacer es asignar la ACL a la interface, para ello lo utilizamos el comando ip access-group <Número/Nombre ACL> IN:
interface FastEhernet0
description Red Local
ip address 192.168.0.1 255.255.255.0
ip address 172.26.0.1 255.255.255.240 secondary
ip access-ip access-group 120 in
ip nat inside
De esta forma aunque sólo tengamos una interface física, podemos establecer un mínimo de seguridad. Con esta configuración, cualquier usuario interno (con privilegios para ello) podría cambiar la direcicón IP de su equipo y conectarse a otra subred sin problemas. Aquí es cuando es "útil" el tener una subred lo más limitada posible (comentario del primer artículo: estos servidores estarán en al subred 172.26.0.0/28 (sólo podréis tener HOST configurados con las siguientes IPs 172.26.0.1 – 172.26.0.14, esto siempre lo hago así para limitar la cantidad de equipos que tenemos en la subred pública, evitando así que tengamos algún equipo de "más" en dicha subred). Está claro que no es una medida de seguridad, pero siempre es bueno optimizar como securizar todo lo posible nuestra infraestructura. Si tenemos un rango adecuado para los equipos que vamos a tener en la red, es posible que no dejemos ninguna IP libre para que alguien pueda conectarse a ella. Pensad, que en esta topología no hay separación física (más interfaces de red en el router) ni lógica (VLAN), por lo que la segregación de la red es simplemente porque tenemos subredes diferentes configuradas en la red.
Comentaros que si en vez de ser un router Cisco es otro cualquier más sencillo, la configuración de la ACL no la tendréis disponible, así que … podréis configurar una regla de Firewall vía GPO para los equipos del dominio y que denigue la conexión con la subred 172.26.0.0/28 (OJO, esto puede responder a mi pregunta sobre las ACL).
Pues con todo esto configurado, únicamente debéis instalar vuestras MV y asignar las tarjetas de red virtuales del único vSwitch configurado, recordad que no hay VLAN, simplemente tendréis que configurar las direcciones IP correspondientes. En los equipos de la DMZ debéis añadir dos tarjetas de red y configurar cada tarjeta con una IP de cada subred a la que pertenezcan, nada más.
Como en los anteriores artículos vamos a ver los beneficios positivos y negativos en esta topología, vamos a ver las positivas:
Y aquí os expongo las negativas:
-
Penalización importante a nivel de seguridad sino tenemos un router con una mínima gestión entre las dos subredes IP
-
Únicamente tenemos seguridad lógica, es muy poco para lo que buscamos
Desde luego no es el escenario más idóneo, pero bueno, por lo menos tenemos dos subredes seperadas y con unos mínimos de seguridad, al final los €/$ tienen su impacto. Pero desde luego cosas siempre se pueden hacer, asi que …
"Nunca dejéis de "complicaros la vida" por no querer darle algunas vueltas a la cabecita, porque con POCO SE HACE MUCHO!!!"
Espero que os sea de utilidad!!!
Leave a Reply