Archivo de la etiqueta: Firewall

Actualizar reglas del firewall de SQL Azure desde Powershell

Para acceder a determinados servicios de Azure, como puede ser una Base datos  Azure SQL es necesario que la ip remota  esté englobada dentro de los rangos permitidos por el firewall de la  suscripción . En ocasiones, encontramos la problemática de querer acceder desde una IP dinámica lo que implica cambiar continuamente las reglas establecidas en el firewall para esa IP.  Así pues, esta semana voy a hablar sobre cómo actualizar de forma automática  las reglas que tenemos creadas en el Firewall de Azure por medio de un script en PowerShell.

Autenticación en Azure

La forma en la que nos vamos a autenticar a través de PowerShell será gracias al fichero PublishSettings. Se trata de un archivo en formato XML que podemos descargar desde nuestra cuenta de Azure  y que contiene información relativa a la suscripción así como un certificado asociado.  Para descargar el fichero PublishSettings únicamente tenemos que ejecutar desde PowerShell el siguiente comando:

Este comando automatiza la apertura de la web de descarga del fichero. Nos logamos en el explorador web con una cuenta que tenga permisos sobre la suscripción, descargamos el archivo y a continuación lo importamos:

001-mod

Una vez realizado esto, tendremos instalado un certificado el cual podremos emplear para conectarnos a Azure, dicho certificado se guarda automáticamente en el almacén personal del usuario. Una vez empleado el fichero publishSettings  por motivos de seguridad es conveniente eliminarlo.

Script de actualización

Realizados los pasos  anteriores podremos automatizar el proceso de actualización de la IP en el firewall. Partimos de la situación  y el script realizados por Carlos Milán en un post anterior, que completaremos añadiendo nuestro código a continuación . Empleamos la IP obtenida por la resolución DNS como dato a añadir en el firewall. Los pasos serían los siguientes:

  1. Establecemos la suscripción sobre la que nos conectaremos por medio del certificado.
  2. Obtenemos los servidores de esa suscripción.
  3. Por cada servidor obtenemos las reglas que hay en cada uno y lo comparamos con el nombre de la regla de Sevilla.
  4. Si el valor no es nulo y la IP que tenemos es diferente cambiamos el rango de IP.
El script tendría la siguiente forma.

Y hasta aquí el tema de hoy¡Nos vemos en el próximo post!

Como llevar nuestro servidor a la nube

Actualización (2015/07/03): Añadida otra forma de autenticación en Azure con PowerShell.

Cada vez es más común aprovechar las ventajas de la nube para nuestros servidores, y en Azure se puede hacer de una manera sencilla. Pero no siempre empezamos desde cero, muchas veces necesitamos migrar los servidores físicos. En este artículo vamos a ver cómo podemos realizar esta migración.

En este último caso, lo primero es comprobar que está habilitada la opción de Remote Desktop (o escritorio remoto), ya que la vamos a utilizar cuando nuestra máquina este en Azure. También tenemos que permitir las conexiones RDP en el Firewall de Windows para las redes públicas, ya que Azure crea una nueva interfaz de red, que de manera predeterminada es de este tipo.

clip_image001

Después tenemos que crear un VHD (Virtual Hard Disk), que es el formato que utiliza Azure para sus máquinas virtuales, al igual que Hyper-V. Para ello tenemos varias opciones, dependiendo de nuestros servidores:

  • Si tenemos un servidor virtualizado en Hyper-V, deberemos comprobar si el disco tiene formato VHD o VHDX. En el caso de tener el segundo formato, deberemos convertirlo con el comando:
  • Si tenemos un servidor virtualizado (que no sea Hyper-V), deberemos hacer una conversión como ya nos explicó Elena.
  • En el caso de tener un servidor físico, podemos usar la herramienta Disk2vhd que ya mostró Antonio.

Subir VHD a Azure

El siguiente paso es crear una cuenta de almacenamiento en Azure, que será donde subiremos el disco creado. Es importante tener en cuenta que la máquina virtual solo se podrá situar en la región donde este localizada la cuenta de almacenamiento.

clip_image002

Dentro de esa cuenta de almacenamiento hay que crear un contenedor, donde estarán los VHDs.

clip_image003

Para subir la imagen, tenemos que utilizar PowerShell y el comando Add-AzureVhd:

Opción 1, autenticación por certificado:

Opción 2, autenticación por credenciales:

Crear disco de máquina virtual

Una vez subido el disco, vamos al apartado máquinas virtuales y seleccionamos discos. Ahí tenemos la opción de crear un nuevo disco a partir de un VHD existente en nuestra cuenta de almacenamiento.

clip_image004

Usar el disco al crear una máquina virtual

Por último, debemos crear una máquina virtual nueva. Para ello, lo realizamos seleccionando la opción desde la galería.

clip_image005

De entre todas las opciones que aparecen, debemos seleccionar mis discos, y ahí aparecerá el disco que acabamos de añadir.

clip_image006

Después de esto, solo nos queda señalar las características de la máquina, y comenzar a disfrutar de ella en la nube.

Cuidado con los puertos dinámicos

Aunque el soporte de Windows Server 2003 ya acabó hace tiempo (el principal, el extendido todavía está vigente), al igual que pasa con el puesto cliente y Windows XP, seguimos encontrándolos en la mayoría de proyectos.

Es por eso que me gustaría recuperar un post de mi blog personal que escribí hace tiempo y que fue un caso recurrente en mis días de soporte en Microsoft.

Nos podemos encontrar con problemas de comunicación en un entorno donde tenemos servidores con Windows Server 2003 mezclados con Windows Server 2008 o superior. Esto viene por un cambio importante relativo al rango de los puertos dinámicos o efímeros que se produjo entre ambas versiones.

En la documentación oficial de Microsoft, esta es la razón que se dio para este cambio:

A fin de cumplir las recomendaciones de la Agencia de asignación de números Internet (IANA), Microsoft ha aumentado el intervalo de puertos de cliente dinámicos para las conexiones de salida en Windows Vista y en Windows Server 2008. El nuevo puerto de inicio predeterminado es el 49152 y el puerto de fin predeterminado es 65535. Se trata de un cambio con respecto a la configuración de versiones anteriores de Microsoft Windows, que utilizaban un intervalo de puertos predeterminado comprendido entre el 1025 y el 5000.

Este es el artículo de KB donde viene toda la información: http://support.microsoft.com/kb/929851

Debemos tener esto en cuenta a la hora de configurar nuestros Firewall si estos son restrictivos con los puertos utilizados internamente para conectar nuestras máquinas.

Si tenemos un entorno con Windows Server 2003 con el rango de puertos dinámicos que va del puerto 1025 al 5000, los firewalls pueden estar configurados para aceptar únicamente conexiones dirigidas a estos puertos.

Si añadimos equipos con Windows Server 2008 o superior, debido a este nuevo rango de puertos, podemos experimentar problemas con la comunicación RPC entre los servidores.

  • Una opción en estos casos sería añadir las reglas del firewall que permitan el tráfico en el intervalo de puertos dinámicos comprendido entre el 49152 y el 65535.
  • Otra opción es modificar en cada servidor Windows Server 2008 el intervalo de puertos dinámicos utilizado para que se ajuste a los de 2003 (con la pérdida en cantidad de ellos que supone).

Este intervalo se ajusta mediante el comando netsh:

El puerto de inicio es número y el número total de puertos es intervalo.

A continuación se muestran algunos ejemplos de comandos:

El puerto de inicio mínimo que puede establecer es el 1025. El puerto de fin máximo, según el intervalo establecido, no puede superar el 65535.

Para duplicar el rango al comportamiento predeterminado de Windows Server 2003 (1025 – 5000) podemos utilizar en los servidores con 2008 o superior el ejemplo expuesto, en el que 1025 es el puerto de inicio y 3975 es el intervalo para TCP y UDP.

Esperamos que esta información os sirva, sobre todo en entornos donde empezáis a actualizar la infraestructura de servidores a versiones más modernas y tenéis un Firewall restrictivo por ahí.

Happy networking!