He estado unos días configurando, con la ayuda del inestimable José Manuel Tella, el servicio de enrutamiento en IIS, de tal forma que nos va a permitir tener un servidor IIS de cara a Internet mostrando el frontend de varios sitios web que vamos a poder tener instalados en diversos servidores de nuestra red interna.
En el servidor que vamos a tener de cara a Internet vamos a montar un Server 2012 R2, y una vez finalizada la instalación del server le añadimos el rol de IIS. En principio le añadí todas sus características, aunque en un servidor en producción podemos afinar más e instalarle sólo aquello que vayamos a necesitar. Así mismo, en las pruebas le instalé un servidor DNS para resolver correctamente los dominios internos, aunque también se puede emplear un DNS ya existente.
Una vez instalado IIS, el siguiente paso es instalar ARR. Para ello lo primero es instalar Web Platform Installer, que podemos encontrar en el siguiente enlace:
https://www.microsoft.com/en-us/download/details.aspx?id=6164
Tras completar la instalación, abrimos la consola de administración de IIS y veremos que nos ha aparecido un nuevo icono para administrar la instalación de componentes de la plataforma web.
Lo ejecutamos y en “Productos” buscamos el complemento “Enrutamiento de solicitud de aplicaciones 3.0” (Application Request Routing 3.0 si el servidor lo tenemos en inglés). Tras la instalación reiniciamos el servicio IIS.
En el árbol de la izquierda vemos que nos ha aparecido una rama “Server Farms”, que aunque no es objeto de este artículo, nos permitirá distribuir la carga de trabajo recibida en el servidor web frontend entre varios servidores. La opción que nos interesa ahora es la de “Reescritura de dirección URL”, dentro de la web por defecto.
Una vez estamos dentro de “Reescritura de dirección URL” seleccionamos en “Acciones” del panel derecho la opción “Ver variables de servidor”
Y añadimos las dos que muestro a continuación:
HTTP_ACCEPT_ENCODING
HTTP_X_ORIGINAL_ACCEPT_ENCODING
y volvemos a reglas
Es el momento de añadir la primera regla, que nos permitirá redirigir las solicitudes http que entren en nuestro frontend con el encabezado “http://www.gericom.es/” al servidor interno 192.168.1.32. Si al añadir la regla nos pide confirmación para iniciar el proxy de enrutamiento, le decimos que sí.
Creamos una regla en blanco, le damos un nombre y le indicamos que la url solicitada coincide con el patrón, usando expresiones regulares y poniendo como patrón (.*)
Con esto conseguimos que lo que se solicite en la url de entrada tras el primer “/” coincida exactamente con lo que se redirige al servidor interno.
En cuanto a las condiciones, le agregamos una de tipo {HTTP_HOST} que coincida con el patrón “www.gericom2.es”. Este es el dominio que tendremos que tener registrado en Internet apuntando a la IP de nuestro servidor web frontend y que vamos a redirigir al servidor interno 192.168.1.32.
En variables de servidor añadimos a la regla las dos que hemos definido anteriormente, como podemos ver en la imagen. Por fin, añadimos una acción de tipo reescribir que apunte a la dirección de nuestro servidor interno
http://192.168.1.32/{R:1}
No debemos olvidar pinchar en “Aplicar” para que se guarden los cambios.
Seguidamente creamos una regla de salida en blanco que relacione los nombres de dominio internos (o direcciones ip del servidor interno) al nombre de la url externa que nos habían solicitado. Le ponemos como condición “ResponseIsHtml1”, marcamos todas las coincidencias de contenido y le ponemos como patrón ^http(s)?://192.168.1.32/(.*) y como acción que reescriba a http{R:1}://gericom2.es/{R:2}
Volvemos a crear una nueva regla en blanco, ahora con condición “NeedsRestoringAcceptEncoding”, y los valores que vemos a continuación.
Una vez hecho todo lo indicado, veremos que el servidor web enruta las solicitudes que recibe de la dirección “www.gericom2.es” al servidor interno, que las resuelve y las devuelve al frontend para que las devuelva a su vez al cliente que las solicitó. El cliente siempre ve en su navegador que la url coincide con “www.gericom2.es”, y no ve la url o dirección del servidor interno que ejecuta la aplicación web.
Podemos realizar esto para múltiples aplicaciones web soportadas por más de un servidor web interno, añadiendo al servidor frontend tantas reglas de entrada y salida como necesitemos.
Como resultado de lo indicado en este artículo, el web.config del sitio por defecto del servidor frontend queda como sigue:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="ReverseProxyInboundRule4" stopProcessing="true">
<match url="(.*)" />
<action type="Rewrite" url="http://192.168.1.32/{R:1}" />
<conditions>
<add input="{HTTP_HOST}" pattern="www.gericom2.es" />
</conditions>
<serverVariables>
<set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="{HTTP_ACCEPT_ENCODING}" />
<set name="HTTP_ACCEPT_ENCODING" value="" />
</serverVariables>
</rule>
</rules>
<outboundRules>
<rule name="ReverseProxyOutboundRule4" preCondition="ResponseIsHtml1">
<match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="^http(s)?://192.168.1.32/(.*)" />
<action type="Rewrite" value="http{R:1}://gericom2.es/{R:2}" />
</rule>
<rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding">
<match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
<action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
</rule>
<preConditions>
<preCondition name="ResponseIsHtml1">
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
</preCondition>
<preCondition name="NeedsRestoringAcceptEncoding">
<add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
<httpErrors>
<remove statusCode="404" subStatusCode="-1" />
<error statusCode="404" prefixLanguageFilePath="" path="http://www.gericom2.es" responseMode="Redirect" />
</httpErrors>
<urlCompression doStaticCompression="false" doDynamicCompression="false" />
</system.webServer>
</configuration>
Comentarios recientes