Cerrar
InicioCertificadosPublicar y Balancear Servicios Web via KEMP LoadMaster

Publicar y Balancear Servicios Web via KEMP LoadMaster

Siempre os he comentado la necesidad de contar con un reverse-proxy para publicar vuestros servicios a Internet, desde vuestra web hasta los servicios de Exchange, SharePoint, ADFS, Lync/SkypefB etc.. :

Siguiendo la misma línea de estos artículos, voy a mostrarmos como utilizar KEMP LoadMaster como reverse-proxy y balanceador para publicar nuestros servicios Web (y no Web). Los KEMP LoadMaster se pueden adquirir en versión hardware o software (soportado en Hyper-V, VMWare), en mi caso yo lo prefiero en versión software para montarlo en mi entorno de virtualización (lo tenemos disponible en Azure también) o del cliente, aprovechándonos así de todos los beneficios implícitos de la virtualización. Os dejo la URL de KEMP en donde podéis ver los diferentes modelos y sus características: https://kemptechnologies.com/es

Si lo queréis probar, tenéis una versión trial de 30 días para que podáis hacer todas las pruebas que necesitáis antes de adquirir una versión final del producto. También, para los que no tenéis grandes necesidades de rendimiento, tenéis una versión 100% gratuita:

Después de esta breve introducción, os voy a mostrar la topología sobre la que voy a argumentar este artículo:

Ahora os muestro la reglas de Firewall que tengo configuradas para el esquema anterior, las configuraciones en cada Firewall ya es cosa vuestra (todo no lo puedo documentar, lo siento):

Como podéis apreciar, tengo una topología con varias subredes (DMZ, LAN  SERVIDORES, LAN USUARIOS), en donde tengo diferentes servidores con sus servicios a publicar. Lo que quiero es publicar diferentes servicios que tengo en On-Premises, para que las conexiones que tengan como origen Internet pasen por el balanceador y algunas de las que tienen como origen la red de usuarios también las hagamos pasar por el balanceador (esto lo comentaré con más detalle).

No voy a entrar en el detalle de la instalación del KEMP, aquí os dejo algunos artículos en donde se detalle dicho proceso (muy sencillo por cierto):

En mi escenario yo cuento con KEMP que tiene dos tarjetas de red, una la tengo en la DMZ Pública (172.16.0.0/24) y otra en la DMZ Privada (192.168.250.0/24). Por delante del KEMP, tengo un Firewall, el cual es el primer elemento de seguridad al cual se le envían las peticiones desde Internet y luego desde ahí utlizando PAT (Port Address Traslation) le envío las conexiones a la interface WAN del KEMP. Una vez que tengamos la instalación completada, voy a mostraros algunas configuraciones importantes que debemos tener en cuenta:

  • Como el KEMP está en una subred diferentes a los servidores, dichos servidores no tienen como default gateway al KEMP, por lo que he deshabilitado la opción de NAT y habilitado que  podamos publicar servidores en una subred diferente a la que tengamos configuradas en las interfaces de red.

Eso si, para poder publicarlos, necesitamos que el KEMP tenga acceso a la subred de los servidores que queramos publicar, por lo que como en la interface de la DMZ Privada no tenemos default gateway configurado, tenemos que configurar rutas estáticas en el KEMP. Estas configuraciones las realizamos desde la sección de System Configuration – Additional Routes y añadimos las rutas como en cualquier otro sistema:

  • Como vamos a publicar servicios mediante SSL, debemos instalar nuestro certificado público (o no, pero eso sería lo suyo),en el KEMP. Para ello, accedemos a la web de configuración y añadimos el certificado que tengamos para tal fin (en mi caso ya lo veis asociado a dos VSs (Virtual Servers)), estos los utilizaremos para configurar luego nuestras reglas de publicación

 En mi escenario, tengo varias configuraciones:

  • Publicación de varias URL mediante una única IP Pública
  • Balanceado de distintos servicios para ser consumidos desde los usuarios de la red interna

Para publicar varios servicios Web mediante HTTP o HTTPS por una sola IP Pública, tenemos primeramente que configurar las Content Rules (Content Rules), lo que permitirán a una única VIP (Virtual IP) poder saber a quien le tiene que enviar la solicitud de conexión en base a la URL. En mi caso estas son las reglas de contenido que he creado, básicamente he creado una por cada URL que quiero publicar:

Para crear una regla de contenido, nos vamos nuevamente a la web de administración del KEMP y vamos a la sección de Rules & Checking – Content Rule y pulsamos en Create New…

Ahora definimos nuestra regla, en mi caso es muy sencilla, puesto que no quiero más que poder leer identificar las URL que quiero publicar y poco más. Esta sección es muy potente, puesto que podemos hacer miles de configuraciones (redirecciones de URL, Rewrite, etc…)

En la opción de Match String es donde especificamos la URL a publicar, debemos especificar las expresiones regulares que necesitemos. Yo he utilizado ^ (Matches the beginning of the string/line) y * (Matches the previous expresssion zero or more times), puesto que me encaja en lo que quiero publicar:

Dicho esto, sé que ha sido muy breve la explicación, pero creo que esto es mejor que lo veáis en la web de KEMP, viene mucho mejor explicado: https://support.kemptechnologies.com/hc/en-us/articles/203125019-Content-Rules. Ahora vamos a la configuración de las VIP (Virtual IP), que son las IP virtuales que configuraremos en el KEMP para utilizar como listener y ahí publicar los servicios hacia los RSs (Real Servers), que son los servidores que tienen los servicios a publicar. El listener es donde vamos a configurar el puerto que utilizarán los usuarios para conectarse, el certificado si es SSL etc… esto es un concepto muy similar a lo que hacíamos con el TMG y los listeners, para los que conozcáis de momento KEMP y podáis tener una referencia del concepto listener. Al final, es una IP virtual sobre el que realizar diferentes configuraciones y publicaciones.

Ahora veamos como crear nuestro primer listener, es muy sencillo, volvemos a la web del KEMP y nos vamos a la sección de Virtual Servers – Add New:

  • Virtual Address: Dirección IP que utilizaremos la cual utilizaremos para publicar los servicios, por la que los usuarios final se conectarán para tener acceso a dichos servicios
  • Port: Puerto que utilizará el servicio a publicar, no tiene porque ser el puerto real del servidor que queremos publicar, pero si el que utilizará los usuarios finales para conectarse
  • Service Name (Optional): Nombre de la regla, algo que utilizaremos para distinguir los diferentes servicios publicados en el KEMP
  • Use Template: KEMP tiene plantillas para ayudarnos a publicar diferentes servicios, de tal forma que haría la configuración inicial por nosotros (https://support.kemptechnologies.com/hc/en-us/sections/200428856-Templates)
  • Protocol: protocolo a utilizar para este servicio

Una vez que tengamos creado nuestro Virtual Server (o listener en otras tecnologías como TMG), vamos a definir las opciones básicas para publicar nuestros servicios Web vía SSL. Lo primero, como ya teníamos agregado el certificado en el KEMP, simplemente lo tenemos que establecer en este Virtual Server. Esta regla la he creado para publicar los servicios del esquema inicial que os he puesto, de tal forma que utilizaremos SSL si o si. Esta configuración podemos hacerlo de varias formas:

  • SSL Acceleration: Las sesiones SSL de los clientes que se conecten al KEMP terminarán en el Balanceador, sino lo habilitamos, las solicitudes SSL se le enviarán directamente a cada servidor que publiquemos.
  • Reencrypt: sólo está disponible si hemos habilitado SSL Acceleration, esto lo que hará será que el KEMP inicie una sesión con el servidor a publicar mediante otra sesión SSL. Por lo que si habilitamos el Reencrypt, el servidor que publiquemos tiene que estar configurado para sesiones SSL

Recordad que este Virtual Service lo voy a utilizar para publicar varios servidores con sus diferentes servicios, por lo que ahora tenemos que ir creando las diferentes configuraciones de los servidores a los cuales le enviaremos las peticiones en base a las Content Rules. Esto se define creando los SubVSs (https://support.kemptechnologies.com/hc/en-us/articles/202138305-Sub-Virtual-Services-SubVS-), cada SubVSs se correponde con el servidor/es que vamos a publicar, digo servidores porque un mismo SubVSs para publicar diferentes servicios, puede tener varios servidores que atiendan las solicitudes de los usuarios (ejemplo: publicación de los servicios de Lync/SkypefB y tenemos varios servidores en el Pool que tienen los servicios a publicar). Dicho esto, vamos a crear un SubVSs, para ello editamos el Virtual Service y en la sección de SubVSs pulsamos en Add New..

Un mensaje nos indica que se ha creado correctamente y con el ID correspondiente, esto es en base a los SubVS que ya tenemos creados (en mi caso las capturas las estoy haciendo sobre un Virtual Service existente):

Ahora lo tenemos disponible para editarlo, como no  lo hemos editado aún, no tiene nombre y se sitúa al final del todo, para editarlo pulsamos en Modify

Aquí estamos configurado el servidor virtual que recibirá las peticiones de uno de los servicios que queremos publicar, debemos especificar un nombre (siempre debemos pulsar en el botón que tenemos al lado de cada caja de texto para que se establezca el valor que hemos puesto)

Ahora que ya tenemos el nombre del servicio, el cual sólo sirve para que nosotros diferenciemos el servicio que estamos publicando, yo suelo especificar el mismo FQDN que voy a publicar, simplemente por diferenciarlo de forma rápida. Bien, ahora, si que tenemos que crear los Real Server, los real servers son los servidores que tienen los servicios que queremos publicar (nuestro Exchange, SharePoint, Lync/SkypefB, etc..). Para ello, pulsamos en Add New … y luego cubrimos los campos que os señalo en verde:

  • Allow Remote Addresses: debemos seleccionar esta opción si el servidor está en una subred diferente a la de las subredes del KEMP (esto va ligado con las primeras capturas que os había mostrado en donde hemos configurado a nivel global la opción de Enable Non-Local Real Servers). Esto nos permite especificar si estamos publicando los servicios del Virtual Service deshabilitando Transparency, esto es que la conexión al Real Server la realiza la Interface del KEMP y no directamente el cliente desde Internet o red local.
  • Real Server: La dirección IP del servidor que queremos publicar
  • Port: EL puerto “real” del servicio que estamos publicando, digo real, porque por ejemplo en Lync/SkypefB el usuario desde internet se conecta a puerto 443 pero nosotros las publicaciones se las enviamos al puerto 4443. Por lo que si el servidor está escuchando en otro puerto, debemos espeficiarlo

Os pongo aquí una imagen de KEMP donde se entiende perfectamente que impacto tiene el habilitar o no el modo Transparency (https://support.kemptechnologies.com/hc/en-us/articles/203126369-Transparency):

Yo estoy utilizando al configuración Non-Transparency, puesto que mis Real Srrver no está en la misma subred que el KEMP y aunque lo estuviesen el Default Gateway de mis Real Servers no es el KEMP. Si queremos utilizar la configuración Transparency, los Real Server tienen que tener como Default Gateway  la IP del KEMP. En la configuración Non-Transparency el servidor puede estar en cualquier subred e igualmente publicarlo, puesto que con que el KEMP pueda llegar a conectarse al Real Server es suficiente (de ahí lo de las rutas estáticas, el habilitar la opción de Enable Non-Local Real Servers, etc…). Esto es muy largo de explicar, en este artículo no lo puedo explicar, porque ya se está haciendo bastante extenso, pero en sucesivos si que lo iré haciendo poco a poco.

Seguimos, una vez que tenemos el Real Server configurado, con uno o varios servidores configurado, debemos especificar como el KEMP sabe que están activos. Esto lo configuramos a nivel del Real Server dentro de la regla del subVSs, como veis por defecto en base al tipo de regla ya nos propone que tipo de Check Method podemos especificar, en mi caso peticiones HTTPS Protocolo al puerto 443 y luego aquí si le he especificado que chequee la URL /hosting/discovery  (este es el servicio WAC). Esto nos permite no sólo chequear el puerto, porque puede estar activo pero la Web que queremos publicar no, de ahí que pueda hacer test de conexión hacia la URL que especifiquemos. Estos test los hará sobre los Real Server que hemos configurado y que en este caso vemos en la parte inferior de la configuración, sólo he agregado un servidor, pero si tuviera varios únicamente tendría que agregarlos.

Por último, debemos especificar la Content Rule que hemos ido creando al inicio de la configuración. Recordad, que esto lo hacemos así porque tenemos un Virtual Service para publicar diferentes servicios en diferentes Real Servers (ahora ya os digo los nombres que utiliza KEMP para que nos vayamos quedando con los términos). De esta forma, el KEMP sabrá que cada regla tiene un Rule que tiene que leer y así una vez haya leído el encabezado de host de la solicitud sabrá que SubVS enviarle la solicitud. Para agregar la Rule a este Real Server simplemente tenemos que ir a al Virtual Service y buscar el SubVSs que no tiene Rules (ya lo veis en rojo)

Pulsamos en None y nos permite seleccionar las Content Rules que queremos agregar a este SubVSs, en mi caso solo voy a seleccionar una regla porque no tengo más URLs para este servicio y Real Servers:

Este proceso tenemos que hacerlo por cada SubVSs y Real Server, de tal forma que cuando tengamos todas las reglas bien configuradas, tendremos algo parecido a esto:

Como veis en mi Virtual Service con la VIP 172.16.0.20:443 tengo publicados todos los servicios web que tengo en mis Real Servers. Si tenemos un servicio con varios servidores, como es los servicios de Lync/Skype (meet.asirsl.com, pool.asirsl.com, dialin.asirsl.com), la configuración del SubVSs tiene varios Real Servers y con el puerto 4443 configurado (recordad que esta es la configuración que tenemos que tener para Lync/Skype. los servicios web que publicamos están configurados en el puerto 4443 en los servidores).

En esta regla, como tenemos varios servidores, si que es importante la configuración de Real Server Check Method, en la captura me ha quedado ICMP PING, pero tengo puesto que realice test sobre el puerto 4443. Cuando tenemos varios servidores, es interesante configurar también a nivel de subVS las opciones de balanceo de carga, esto lo configuramos en la sección de Standard Options, aquí en función del servicio elegiremos un tipo de Persistence Options

Y de Scheduling Method, lo mismo, cada servicio  se ajusta  de forma diferente

Con esto tenemos ya todos los servicios configurados, si nos vamos a la sección de  Virtual Services – View/Modify Services podemos ver todos los servicios que tenemos configurados en nuestro KEMP. Vemos los Virtual Services que tenemos configurados, los que tienen un icono en rojo es que alguno de los servidores de los subVS está desconectado o tiene algún problema, vamos, que no la regla no funcionará para ese servicio publicado. Como veis, yo tengo varias reglas configuradas, las primeras son las que he estado documentado en este artículo, todo servicios Web que vamos a publicar hacia Internet. Las siguientes dos reglas, son para poder balancear en interno los diferentes servicios de Lync/Skype, vamos que tengo dos Virtual Services con sus VIP (pero del rango privado para la DMZ Privada), no tiene Content Rules, porque son reglas independientes y que aunque van a los mismo servidores, utilizan puertos diferentes (5061 y 443), estas reglas las utilizo para que los usuarios internos (en la misma subred o no conectados vía VPN hacia donde está el KEMP y la red de servidores de Lync/SkypefB), y así también los balanceo en interno. Lo que hago es que el registro DNS pool.asirsl.com tiene la VIP del KEMP, pero ese mismo registro DNS si se consulta en internet resolverá la IP Pública del Firewall que luego enviará la petición hacia el puerto 443 de la VIP 172.16.0.20 (el Virtual Service que he estado configurando).

Si veis la topología de red con la que estamos trabajando, los usuarios externos van por la VIP de la DMZ Pública (172.16.0.20) y los internos por la VIP (192.168.250.140) de la DMZ Privada:

Las reglas de los Firewall que yo tengo en la topología son la siguientes, ahora que ya hemos leído el artículo, creo que es más fácil de entender:

Espero que no se haya hecho muy extenso este artículo, aquí os dejo el resumen de lo que pretendía explicar:

  • Publicación de varias URL mediante una única IP Pública: 1 Virtual Service, N subVSs, N Real Servers
  • Balanceado de distintos servicios para ser consumidos desde los usuarios de la red interna: Configurar varios Virtual Service con sus VIP y ajustar los DNS internos para que la IP que resuelve sea la VIP del KEMP y luego en función de las configuraciones que tengamos, el KEMP realice el balanceo de carga o en si alguno de los servidores está desconectado el usuario no se va afectado). Me ha quedado pendiente la regla del ADFS para los usuarios internos, pero vamos, básicamente sería crear otro Virtual Service con otra VIP para publicar en interno los servicios de federación (será el próximo artículo a comentar por tiene sus particularidades) y el registro DNS apuntando a la VIP del KEMP. O bien otro Virtual Service para configurar de la misma forma que hemos hecho la configuración de este artículo para servicios publicados a Internet, pues para interno, vamos, utilizando las Content Rules, etc…

La publicación y/o balanceo de los servicios Web para los usuarios internos, también nos sirve para que los usuarios con Lync/SkypefB con el cliente móvil se pueda conectar sin problemas. Porque digo esto, porque si nos conectamos desde dentro de la red, los servidores de SkypefB lo normal es que utilicen certificados de nuestras CA Privas, por lo que los clientes de Lync/SkypefB móviles no se conectarán, puesto que los móviles no tendrán o suelen tener (sino lo instalamos de forma manual) el certificado raiz de confianza, por lo que no confiaríamos en el certificado expuesto por el servidor y daría un error. Si los hacemos pasar por el KEMP y configuramos en el Virtual Service el certificado público, ya no tendrán problemas y los usuarios desde el móvil se conectarán sin problema. Esto es muy interesante, no sólo para Lync/Skype, sino sobre todo para cualquier servicio que consumamos desde dentro de la red, tengamos servicios con certificados privados y equipos que no estén en el dominio, porque no tendrán el certificado raíz, etc… Aquí os dejo algunos artículos sobre certificados que os pueden interesar a este respecto:

http://www.santiagobuitragoreis.com/pon-un-certificado-wildcard-comodin-en-tu-infraestructura-it/

  1. Requisitos que necesita cumplir un Certificiado Digital para reconocerse como válido
  2. ¿Qué certificados necesitamos para Lync?
  3. Certificados SAN o Wildcard para nuestra implementación de Lync Server
  4. Emitir Certificados con más de 2 años de validez en una CA en Windows
  5. Lync Server: Modificar el tiempo de validez de un certificado de usuario
  6. Creación de CSR para Lync de forma sencilla
  7. Asignar Certificados a un Front-END de Lync Server 2013
  8. Renovar, Instalar y Asignar Certificados a nuestro Edge de Lync Server 2010/2013
  9. Lync Server: Un Edge, Un Certificado SAN para un Dominio, Múltiples Dominios SIP y Federaciones (Actualizado 12-06-2013)
  10. Lync Server: Un Edge, Un Certificado SAN para un Dominio, Múltiples Dominios SIP y Federaciones (Actualizado 12-06-2013)
  11. Cómo publicar todos los servicios de Lync, Exchange y WAC únicamente con una IP Pública
  12. Asignar Certificados a un EDGE de Lync Server 2013

En próximo artículos iré explicando opciones más específicas del KEMP, serán menos extensos que este y más directos a configuraciones muy concretas.

Si tenéis cualquier duda, por favor, dejar un comentario y las aclararé lo más rápido posible. Entiendo que este artículo sino se maneja KEMP desde hace tiempo, es posible que no estén todos los detalles de configuración como en otros artículos. Es que si así ya ha quedado extenso, si detallado al 100% todos los pasos… sería para no leerlo 🙁

Comentaros, que no lo había hecho, es que KEMP es el sustituto natural que tenemos para TMG, por lo que hay que empezar a manejarse con él cuanto antes. Es bastante sencillo, como todos los productos tienen sus particularidades (Transparency por ejemplo), pero nada que no se pueda aprender con lectura y ganas.

Espero que os sea de utilidad y espero vuestros comentarios!!

MVP AWARD KIT 2017-
2 COMENTARIOS
  • Yoennis / 16 Julio, 2017

    Una explicación y excelente artículo. Este tipo de configuración ya le he realizado en varias empresas pequeñas que no tienen el potencial para adquirir diferentes direcciones IP publicas y funciona muy bien. He tenido algunos problemas solamente cuando hay q añadir un servicio de ADFS y enviar las peticiones desde el KEPM hasta el servidor ADFS en la red local. Felicidades por el buen trabajo y el aporte. #MVPbySURE

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies