Uno de los escenarios más comunes entre las PYMES es la creación de una nube privada en el CPD de algún proveedor de servicios de Data Center, en donde se implementan todos los servicios de la compañía. En donde solemos tener un hipervisor (Hyper-V, VMWare, etc..) para montar nuestra nube privada, para implementar nuestra infraestructura IT:
- Controladores de Dominio
- Lync Server
- Exchange Server
- SharePoint
- CRM
- Aplicaciones de negocio
Además, se suele llevar al CPD algunos elementos de comunicaciones como son el Router y Switch, lo que nos permiten configurar nuestra red privada a nuestro antojo. También pretendemos minimizar el impacto económico para la organización, que aún siendo muy beneficioso el estar en el CPD (seguridad física, capacidad de crecimiento, conectividad, etc..), tiene sus costes que debemos poder justificar. Por lo que llevaremos un único servidor para montar nuestra plataforma, por lo que nos llevaremos nuestro servidor físico para instalar Windows Server 2012 R2, en el cual habilitaremos el rol de Hyper-V para crear nuestra nube privada. Claramente la idea es montar un sistema tolerante a fallas (clúster o replicación de MV con Hyper-V), pero no todos las compañías se lo pueden permitir aun siendo IT una pieza estratégica de negocio, por lo que tienen un sistema de backup externo bien gestionado o externalizado para garantizar la integridad de la infraestructura en caso de algún desastre. Pero ahora no nos vamos a centrar en esto, simplemente era para comentaros que este es un escenario de muchas empresas pequeñas y medianas, que quieren/necesitan tener su infraestructura en la nube. En este artículo os mostraré un esquema bastante común para empresas que tienen entre 10 y 50 trabajadores y que cuentan con sedes físicas en distintas zonas geográficas (pulsar en la imagen para ampliarla):
El esquema es muy sencillo, tenemos una nube privada en un CPD de algún proveedor de servicios y allí desplegamos toda nuestra infraestructura IT. El resto de sedes consumen los servicios que hemos implementado desde sedes físicas conectadas vía VPN (
Cisco VPN IPSec Site-to-Site con Certificados Digitales) o MPLS (en nuestro caso hemos puesto VPN), pero vamos a ver como se accederá a esos servicios (Lync concretamente) si utilizamos split-dns o no. Los equipos de la organización están unidos al dominio que hemos desplegado en el CPD, los usuarios de la red inalámbrica se autentican vía certificado digital (
NPS: Autenticación 802.1x para nuestra red inalámbrica) en un servidor NPS que también está en el CPD claramente. Queremos evitar en la medida de lo posible tener servicios en cada una de las sedes,
confiamos plenamente en las líneas de datos que nos conectarán con el CPD vía VPN (IPSec). En cada sede tenemos un router para configurar la VPN y que nos permite interconectar todas las sedes, los routers de las sedes remotas además serán servidores DHCP para entregar direccionamiento IP (IP, Máscara, Gateway, DNS) a los equipos de la sede. Además, el router de la sede central tendrá alguna configuración adicional para publicar los servicios hacia Internet (Lync, Exchange, Office Web App) para los usuarios que accedan fuera de la VPN. Como solo tenemos una dirección IP Pública en el router del CPD (esta es una limitación forzada para el articulo claramente), tendremos que adaptar nuestra configuración de Lync (
Cómo publicar todos los servicios de Lync, Exchange y WAC únicamente con una IP Pública) y además como tenemos solo dos tarjetas de red (configuración forzada para este artículo) en el servidor de virtualización, debemos configurar distintas VLAN porque queremos separar las interfaces externas e internas de nuestros servidores (Lync, Exchange, Reverse-Proxy, Controladores de dominio, etc..). Si tenemos un switch L3 realizaremos las configuraciones de las VLAN en el propio switch, en el caso contrario debemos configurarlo en el router, como lo haré con Cisco configuraremos Router on a Stick (
http://www.cisco.com/c/en/us/support/docs/lan-switching/inter-vlan-routing/14976-50.html). Lo que quiero hacer es que las interfaces externas de las MV estén en una VLAN (
15), las interfaces internas de los equipos expuestos a internet (Reverse-Proxy y EDGE de Lync) también en otra VLAN (
20) y los equipos del dominio tendrán también su propia VLAN (
25). Lo que quiero es evitar el tráfico entre las distintas VLAN, tratando de "simular una DMZ" con VLAN y ACL (filtrados). Además, como en cada VLAN tendremos un direccionamiento IP diferente (lo normal), será muy sencillo crear las ACL para filtrar el tráfico en el origen del mismo y así evitar accesos indeseados. Dicho esto, aquí os muestro el esquema de la NUBE PRIVADA:
Como vemos tenemos un Switch L3 en donde crearemos las interfaces SVI (switch virtual interface), las cuales serán tendrán su dirección IP la cual será utilizada por los equipos de cada VLAN como gateway. Lo primero será crear las VLAN en la base de datos del switch (VLAN XXXX), luego crear y configurar la SVI
SwitchCPD(config)# vlan 15
SwitchCPD(config)# interface vlan 15
SwitchCPD(config-if)# ip address 172.26.0.1 255.255.255.0
SwitchCPD(config-if)# description VLAN Interfaces Externas EDGE y Reverse-Proxy
SwitchCPD(config-if)# no shutdown
SwitchCPD(config)# vlan 20
SwitchCPD(config)# interface vlan 20
SwitchCPD(config-if)# ip address 172.26.1.1 255.255.255.0
SwitchCPD(config-if)# description VLAN Interfaces Internas EDGE y Reverse-Proxy
SwitchCPD(config-if)# no shutdown
SwitchCPD(config)# vlan 25
SwitchCPD(config)# interface vlan 25
SwitchCPD(config-if)# ip address 172.26.2.1 255.255.255.0
SwitchCPD(config-if)# description VLAN Interfaces LAN servidores
SwitchCPD(config-if)# no shutdown
SwitchCPD(config)# vlan 30
SwitchCPD(config)# interface vlan 30
SwitchCPD(config-if)# ip address 172.26.10.2 255.255.255.0
SwitchCPD(config-if)# description VLAN enlace entre Router y Switch L3
SwitchCPD(config-if)# no shutdown
Ahora mismo tenemos el switch L3 configurado y con su dirección IP para cada SVI, ahora nos queda asignar cada VLAN a cada interface física del switch. Recordar que solo tenemos una tarjeta de red disponible en el servidor para utilizarla en Hyper-V y crear los vSwitch, por lo que configuraremos uno de los puertos del switch como un enlace troncal en donde transportaremos únicamente las VLAN 15, 20 y 25:
SwitchCPD(config)#interface gigabitethernet0/1
SwitchCPD(config-if)#switchport mode trunk
SwitchCPD(config-if)#switchport trunk allowed vlan 15,20,25
SwitchCPD(config-if)#description Puerto para Hyper-V
Y por último debemos configurar otra interface para la VLAN 30 que se utilizará para conectar con el router, aunque también es cierto que podríamos configurarlo en la VLAN 15, pero de esta forma nos sera más sencillo configurar las ACL de entrada que vamos a requerir configurar en el Switch L3 para filtrar el tráfico desde el origen:
SwitchCPD(config)#interface gigabitethernet0/2
SwitchCPD(config-if)#switchport mode access
SwitchCPD(config-if)#switchport access vlan 30
SwitchCPD(config-if)#description Enlace Swithc-Router
En este caso es un puerto de acceso, puesto que solo transportaremos la VLAN 30, y de hecho en el router solo vamos a configurar la interface pero sin asignarle VLAN porque no lo necesitamos. Todo el tráfico que salga de la interface gigabitethernet0/2 del Switch L3 ya va etiquetado con la VLAN 30. Y para la interconexión entre VLAN configuraremos Inter-VLAN Routing que por defecto ya lo tenemos habilitado, ahora debemos configurar las ACL para filtrar el tráfico entre las distintas VLAN (pero esto ya os lo dejo a vosotros sino se va de alcance el artículo) configuradas en el Switch. Por último comentaros que en cada MV debemos configurar el etiquetado en la interface de cada MV para asignar su VLAN, su configuración es muy simple:
Con esta configuración, tenemos un enlace troncal entre la interface del servidor utilizada en Hyper-V y el Switch L3, permitiendo que se transporte tráfico de las VLANs 15, 20 y 25 (switchport trunk allowed vlan 15,20,25). Y con la configuración de cada MV especificando el ID. de VLAN a la que corresponde, ya tenemos la configuración finalizada. Ahora toca crear las rutas estáticas entre el Switch y el Router, para que ambos tengan conocimiento de toda la red. En el Switch debemos crear una ruta estática de último salto (ip route 0.0.0.0 0.0.0.0 172.26.10.1), porque queremos que los equipos de la red tengan internet saliendo por el Router (que es quien tiene la conexión a Internet), y como los equipos tienen como gateway el Switch, debemos indicarle al Switch que para el tráfico que no conozca (internet o Sedes VPN) lo envíe al router (172.26.10.1 IP de la interface Interna que tenemos en la VLAN 30 en donde el Switch tiene la IP 172.26.10.1). Y en el router, debemos configurar las rutas estáticas que le lleven a las redes de la VLAN 15, 20 Y 25 (VLAN 15: ip route 172.26.0.0 255.255.255.0 172.26.10.2; VLAN 15: ip route 172.26.1.0 255.255.255.0 172.26.10.2; VLAN 25: ip route 172.26.2.0 255.255.255.0 172.26.10.2). Ahora tenemos comunicación entre todas las VLAN y los equipos tendrán acceso a Internet a través del router, pasando claramente por el Switch L3 porque ahí tenemos el enlace físico y la configuración de las VLAN con su troncal (TRUNK PORT).
Ahora que ya tenemos comunicación entre las VLAN del CPD, entre las sedes conectadas mediante VPN (debemos ajustar la configuración de IPSec para que esto sea así : añadir la subred de la VLAN 25 como tráfico no nateado, etc…), vamos a ver dos escenarios posibles y que dependerán del DNS. Lo normal sería que todos los equipos de las sedes remotas estuviesen unidos al dominio, para ellos los equipos de la red deben tener como servidor DNS primario la dirección IP del Controlador de Dominio (o servidor DNS de la red) y es aquí en donde debemos prestar mucha atención si queremos que nos funcione todo correctamente. Si los clientes tienen como servidor DNS el servidor de la red (nube privada), los registros que resolverá serán las IPs internas de los servicios configurados (Lync, Exchange, etc..), por lo que debemos permitir el acceso entre las sedes y dichos servicios. Hasta ahí todo normal, pero si hablamos de Lync (que en él se centran estos artículos), debemos asegurarnos que las sedes remotas tienen acceso a la interface interna del EDGE cuando se quieran comunicar con usuarios de Lync fuera de las sedes VPN, vamos usuarios externos a efectos de topología. Y además, como resolvemos los nombres de los servicios vía DNS interno, el FQDN del EDGE tendrá la IP interna ( y así debe ser), por lo que en el EDGE debemos configurar las rutas estáticas hacia las sedes remotas apuntando como gateway de destino en la ruta a la interface SVI del Switch L3 (172.26.1.1 de la VLAN 20). Esto es así porque la resolución de nombres vía DNS interno resuelve el nombre del EDGE con la IP interna, como si solo tuviéramos una red, el comportamiento es exactamente el mismo que en otras topologías y tenemos varias subredes IP. El EDGE debe poder comunicarse con los clientes internos vía Interface Interna para poder comunicarnos con los usuarios externos. ¿Pero qué ocurrirá si los equipos tienen como servidor DNS un servidor externo (8.8.8.8)? … pues que van a resolver los nombres públicos y aun a pesar de tener conectividad directa vía VPN, serán considerados usuarios externos porque se conectarán a Lync vía IP Pública. En este caso no tendremos nada que hacer, simplemente serán tratados como usuarios externos y lo harán vía EDGE por su interface externa. Pero si lo hacen desde alguna sede conectada vía VPN, si os comento que debéis ajustar la configuración de los routers, porque sino no tendréis acceso a los puertos publicados vía Port Forwarding, puesto que la configuración de IPSec entre ambos routers entenderán que tienen tráfico directo y debemos especificar que no será así y que entre las redes remotas debe permitir la conexión vía PAT de los puertos configurados. Para ello debemos realizar las siguientes configuraciones en el router del CPD en donde hemos publicado los servicios:
ip nat inside source static tcp 172.26.0.4 443 213.213.213.2 443 route-map Lync-Reverse extendable
ip nat inside source static tcp 172.26.0.5 5061 213.213.213.2 5061 route-map Lync-Reverse extendable
ip nat inside source static tcp 172.26.0.5 444 213.213.213.2 444 route-map Lync-Reverse extendable
ip nat inside source static tcp 172.26.0.5 446 213.213.213.2 446 route-map Lync-Reverse extendable
ip nat inside source static udp 172.26.0.5 3478 213.213.213.2 3478 route-map Lync-Reverse extendable
route-map Lync-Reverse permit 10
match ip address 103
access-list 103 deny ip 172.26.0.0 0.0.255.255 192.168.0.0 0.0.0.255
access-list 103 deny ip 172.26.0.0 0.0.255.255 192.168.1.0 0.0.0.255
access-list 103 permit ip 172.26.0.0 0.0.255.255 any
Aquí faltaría configurar el tráfico RTP (50.000 – 59.9999) pero ya os lo dejo a vosotros, lo que queremos es que el tráfico de las subredes IP internas de las sedes remotas pueda establecer comunicación con los distintos servicios vía IP Pública del Router sin pasar por el túnel IPSec (forzado por defecto). Esto recordar que solo ocurriría si los clientes utlizan como servidor DNS uno público y no el servidor DNS initerno, lo que hará que se resuelven los nombres públicos de los servicios y traten de conectarse directamente por la IP Pública del router (esto es algo más extenso de contar, si algiuen quieren más información sobre esto que deje algún comentario en el blog)
Lo suyo es que los equipos estuviesen en el dominio y la resolución de nombres vaya por interno (servidor DNS interno), sobre todo para conectarse de forma transparente a todos los servicios:
-
Exchange
-
Lync
-
Servidor de Ficheros
-
SharePoint
Sobre todo el poder utilizar el SSO una vez que hayamos iniciado sesión en el dominio y no tener que pasar por el Reverse-Proxy para el Exchange, SharePoint, etc… además de que no podríamos conectarnos de forma transparente al servidor de Ficheros porque no lo vamos a exponer a internet directamente sino que tendríamos que conectarmos con un cliente VPN o vía RDS para tener acceso a los ficheros. Para beneficiarnos de todos estos servicios y consumirlos vía SSO, lo suyo es tener configurado bien nuestra red y utilizar la resolución de nombres de nuestro servidor DNS interno.
Como podéis apreciar el "problema" en casi todas las topologías es la resolución de nombres y en función de esto debemos configurar las rutas estáticas en el EDGE para llegar a las subredes Internas estén o no en nuestra misma ubicación geográfica (conectados vía VPN, MPLS, etc..). No he comentado nada sobre la configuración del router en cuanto a tener solo una IP Pública y una Privada, porque con la configuración de las VLAN ya tenemos la segregación de direccionamiento y así cada servicio tenga un direccionamiento IP diferente (Edge de Lync y Reverse-Proxy: Interfaces Externas e Internas). Así evitamos tener que configurar el router con dos IPs privadas, etc… esto es más transparente para el router y más eficiente. Recordar que debéis configurar las diferentes ACL aplicadas luego a las SVI de entrada, siempre lo más cercano al origen:
Configuring Network Security with ACLs. Por el resto la configuración es sencilla, DNS interno, rutas estáticas y todo funcionando sin problema.
Al principio os comentaba que este suele ser un esquema bastante utilizado por las empresas para tener su nube privada, no tener que acondicionar su propio CPD, tener más capacidad de gestión (comunicaciones, seguridad, etc..) y amplicación, además de garantizar la continuidad de negocio en caso de que alguna de las sedes remotas esté caída. Además, a día de hoy (por lo menos en España en casi todo el territorio) la conectividad a internet es buena, en cuanto a caudal y estabilidad, por lo que es un esquema válido para muchas compañias. Siempre sería recomendable tener la infraestructura replicada (clúster o replicación Hyper-V, dos switchs y dos routers), pero lo he querido montar así para que veáis que con una infraestructura humilde también se puede hacer cosas muy interesantes y funcionales.
Espero que os sea de utilidad!!!
Leave a Reply