Cerrar
InicioAzureMoviendo nuestros servicios y máquinas virtuales a Azure (Parte II)

Moviendo nuestros servicios y máquinas virtuales a Azure (Parte II)

Siguiendo con esta serie de artículos, voy a mostrar lo que para mi es el primer paso a dar si realmente ya estamos seguros (definición de estrategia previa) de que Azure es nuestro proveedor de Cloud. Yo siempre doy por hecho que tenemos Office 365 con nuestro Azure AD Connect configurado, sincronizado y en en muchos casos (recomendado) ya tenemos nuestro ADFS implementado. Sino fuese así, aquí os dejo un artículo donde MSFT explica muy bien para que sirve y el proceso de configuración:

La integración de nuestro AD con O365/Azure nos permitirá de forma cómoda, delegar permisos de administración a usuarios y grupos de nuestro AD On-Premises, además de SSO, etc… vamos un sin fin de beneficios que os invito a descubrir si no las conocéis todavía.

Dicho esto y esperando que tengáis ya un entorno sincronizado y federado, lo que quiero hacer es mover mis máquinas virtuales a Azure. Por lo que tendré que realizar unas configuraciones previas, puesto que quiero tener mi Directorio Activo disponible en Azure. Para ello, crearé un nuevo controlador de dominio en una máquina virtual, el cual ofrecerá los servicios de dominio para todas las máquinas que tengamos en Azure. Esto evitará que si la VPN que tendremos configurada entre Azure y On-Premises se cae, los servicios que dependen de tener contacto con el AD no dejen de funcionar. Esto es algo que siempre hacemos cuando tenemos sedes remotas con cierto número de usuarios/servicios, tener un DC en la misma oficina para tener disponibilidad de dichos servicios.

Como he comentado, configuraremos una VPN entre Azure y On-Premises, lo que nos permitirá conectarnos a los servidores que tengamos en Azure de forma segura a través del túnel IPSec. Una vez que tengamos la VPN implementada, ya podemos empezar a desplegar el resto de servicios y máquinas virtuales. Como queremos tener un nuevo DC en Azure, tenemos que tener contacto (no obligatorio, pero … recomendado) con los DC que tengamos en On-Premises, de tal forma que para eso tenemos la VPN.

Para esta serie de artículos había publicado una topología de red creada en MSFT Visio, para que tuviéramos una referencia de que tenemos en On-Premises y ver como mover ciertos servicios a Azure. El artículo al que hago alusión es el siguiente: Moviendo nuestros servicios y máquinas virtuales a Azure (Parte I) y ahí tenéis la topología que os estoy comentando. Para los siguientes artículos (este lo es) iré modificando poco a poco la topología para que vayamos viendo los cambios que va sufriendo, así que este  es el que toca ahora:

AZURE VPN

He sombreado todo el esquema y sólo he querido resaltar (en blanco) todo lo que se va a tener que “tocar” para este primer paso hacia Azure, como se puede apreciar, lo que haré será configurar la VPN entre Azure y la sede central, pero además, aprovechar para comunicar a todas las sedes con Azure mediante el router de la sede central (o también podemos configurar una VPN entre Azure y cada una de las sedes). Como también tenemos clientes con DirectAccess, también la daremos acceso a conectarse con Azure sin realizar ningún cambio en los clientes. De esta forma, si empezamos a desplegar servicios en Azure, los usuarios internos y externos se podrán conectar sin problema.

Ahora voy mostraros un pequeño guión a seguir, porque hay que hacer varias cosas antes de empezar con la configuración de la VPN en Azure. Todas estas configuraciones son ya en Azure, para que quede claro antes de empezar:

  1. Crear los grupos de recursos
  2. Crear la red virtual
  3. Crear las subredes
  4. Configurar la VPN en Azure
  5. Configurar la VPN en On-Premises

Me falta por comentar que no voy a explicar como crear una suscripción de Azure, porque creo que no tiene nada de técnico y no creo que sea ámbito de interés para este artículo. De todas formas, os dejo un enlace para que podáis ver que es una suscripción y como crear una: Cree su cuenta gratuita de Azure hoy mismo, además recordad en la contratación podéis disponer de un crédito de 170€ para el primer mes, por lo que podéis iniciaros cuando queráis:

AZURE

Pues ahora si que empezamos, así que siguiendo el orden descrito anteriormente, lo primero que tenemos que hacer es crear los grupos de recursos en Azure. Si alguien no sabe lo que es un grupo de recursos en Azure, aquí os dejo una descripción de MSFT al respecto:

Grupos de recursos

Hay algunos factores importantes que se deben tener en cuenta al definir el grupo de recursos:

  1. Todos los recursos del grupo deben compartir el mismo ciclo de vida. Se implementan, actualizan y eliminan de forma conjunta. Si un recurso, como un servidor de base de datos, debe existir en un ciclo de implementación diferente, debe estar en otro grupo de recursos.
  2. Cada recurso solo puede existir en un grupo de recursos.
  3. Puede agregar o quitar un recurso de un grupo de recursos en cualquier momento.
  4. Puede mover un recurso de un grupo de recursos a otro. Para obtener más información, consulte Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción.
  5. Un grupo de recursos puede contener recursos que residen en diferentes regiones.
  6. Un grupo de recursos puede utilizarse para definir el ámbito de control de acceso para las acciones administrativas.
  7. Un recurso puede interactuar con los recursos de otros grupos. Esta interacción es común cuando ambos recursos están relacionados, pero no comparten el mismo ciclo de vida (por ejemplo, aplicaciones web que se conectan a una base de datos).

Al crear un grupo de recursos, es preciso proporcionar una ubicación para dicho grupo de recursos. Pero puede preguntarse: “¿Por qué necesita un grupo de recursos una ubicación? Y si los recursos pueden tener ubicaciones distintas de las del grupo de recursos, ¿por qué es importante la ubicación de este?” Los grupos de recursos almacenan metadatos acerca de los recursos. Por consiguiente, al especificar la ubicación del grupo de recursos, se especifica el lugar en que se almacenan dichos metadatos. Por motivos de compatibilidad, es posible que sea preciso asegurarse de que los datos se almacenan en una región concreta.

Mi objetivo con los grupos de recursos son  es poder:

  • Delegar permisos
  • Conocer el coste
  • Clasificar los recursos (discos duros, máquinas virtuales, webs, etc…) que vayamos contratando

Está claro que luego sirven para muchísimas más cosas, pero con estas tres yo me doy inicialmente por satisfecho. Porque son las tareas más elementales, poder delegar los permisos sobre un grupo de recursos a un administrador de nuestra empresa o de terceros. El poder conocer el coste que nos está suponiendo todos los recursos que tenemos asociados para un proyecto o servicio en concreto, es muy útil y necesario. Por último, el poder encontrar todos los recursos en su sitio en función de su rol, naturaleza u objetivo del recurso. Eso lo iremos viendo a continuación, según vayamos avanzando en este artículo.

Bueno, pues ahora si  que si, venga, lo primero será acceder al portal de Azure: https://portal.azure.com, por defecto no tenemos nada, puesto que aún no hemos empezado a contratar ningún servicio:

Grupo Recursos Azure

Para poder crear un grupo de recursos, tenemos que pulsar en Grupos de recursos en el menú lateral izquierdo, una vez dentro nos mostrará todos los grupos de recursos que tengamos. En este caso aún no he creado ninguno, por lo que empezaremos desde cero. Todo esto se puede crear vía PowerShell, pero creo que primero es empezar a conocer y familiarizarse con la interface gráfica, por lo que empezaremos desde aquí:

Grupo Recursos Azure

Pues como en todo Azure, siempre que tengamos que crear algo, tenemos el botón de Agregar dentro de la pantalla en la que nos encontramos y tengamos posibilidad de crear algún objeto, así que dentro de Grupos de recursos pulsamos en Agregar. Ahora nos solicitará el nombre del grupo de recurso, la suscripción y la ubicación de dicho grupo de recursos. Esto es muy importante, siempre debemos colocar el grupo de recursos en la zona que deseemos, teniendo en cuenta que queremos estar lo más cercano a nuestra ubicación física (o coste de los recursos), yo voy a elegir Norte de Europa por proximidad.  Lo de la ubicación está bien descrito aquí:

Al crear un grupo de recursos, es preciso proporcionar una ubicación para dicho grupo de recursos. Pero puede preguntarse: “¿Por qué necesita un grupo de recursos una ubicación? Y si los recursos pueden tener ubicaciones distintas de las del grupo de recursos, ¿por qué es importante la ubicación de este?” Los grupos de recursos almacenan metadatos acerca de los recursos. Por consiguiente, al especificar la ubicación del grupo de recursos, se especifica el lugar en que se almacenan dichos metadatos. Por motivos de compatibilidad, es posible que sea preciso asegurarse de que los datos se almacenan en una región concreta.

De aquí, a parte de la ubicación de los recurso (que es lo más importante), me gustaría comentar lo de los nombres de los recursos. A mi personalmente me gusta mucho la estandarización de la cosas (en general), en este caso de la nomenclatura de los grupos de recursos me parece vital. Aquí os dejo un vídeo excepcional donde os dan las pautas para nombrar todos los recursos que crearemos en Azure:

Y luego también os dejo un enlace en donde también os explicarán las buenas prácticas para nombrar los recursos que vayamos contratando en Azure: Naming conventions. Una vez que hayamos definido como vamos a nombrar los distintos grupo de recursos que vamos a ir creando, nos ponemos a ello. Mi primer grupo de recursos para las vNet, de ahí el nombre para mi grupo de recursos sea RG-NorthEurope-Network

Grupo Recursos Azure

Una vez finalice el proceso de creación del grupo de recursos ya lo tendremos disponible:Grupo de Recursos

Como lo primero que voy a conectar es mi vNet, sino tenemos la sección de Red Virtuales visible desde el menú de favoritos de Azure, simplemente pulsamos en Más servicios lo buscamos y pulsamos en la estrella que tenemos a la derecha del nombre del recurso a seleccionar:Red Virtual Azure

De esta forma ya lo tenemos disponible de forma rápida, muy útil tenerlo siempre a mano. Bien, pues ahora vamos a crear nuestra primera vNet, para ello podemos pulsar en AgregarCrear Redes VirtualesRed Virtual Azure

Tenemos que cubrir el siguiente formulario, donde debemos cubrir los siguientes campos:

  • Nombre: especificaremos el nombre para nuestra vNet, yo como siempre trato de seguir las buenas prácticas para nombrarla.
  • Espacio de direcciones: definiremos la subred IP que tendrá nuestra red, la cual luego tendremos que repartirla entre las diferentes subredes que vayamos creando
  • Suscripción: elegiremos la suscripción en la que se nos facturará este servicio
  • Grupo de Recursos: Yo utilizaré uno existente, justo el que acabamos de crear, pero podríamos crearlo en este mismo momento si fuese necesario
  • Ubicación:  En que datacenter vamos a ubicar esta red, en mi caso colocaré todo en el Norte de Europa
  • Subred: Ya nos pide crear nuestra primera subred, el nombre que yo les pongo va en función de los servicios que tengamos en dicha subred. En este yo tendré mis DC, de ahí que le llame Identity
  • Intervalo de direcciones: especificaremos una subred dentro del intervalo que hemos creado para dicha subred

Red Virtual Azure

Lo mismo que antes, esperamos unos segundo y en breve tendremos nuestra primera vNet lista

Y aquí está, nuestra vNet disponible, ubicada en el Norte de Europa y en grupo de recursos RG-NorthEurope-Network y la suscripción que hayamos elegido

Ahora podemos acceder a nuestra vNet y ver las diferente opciones de configuración que tenemos, desde un resumen de dispositivos conectados hasta los DNS configurados para los equipos conectados a dicha subred.

Vemos el espacio de direcciones asociadas, donde podemos realizar ciertas modificaciones:

En la sección de subredes es donde podemos ver las actuales (la que veis es la primera que hemos creado con la creación de la vNet) y las nuevas que podemos ir creando

Para crear un subred simplemente pulsamos en Agregar y nos lleva al siguiente formulario, debemos especificar el nombre de la subred, intervalo de direcciones IP que no esté siendo utilizado por otra subred y luego si queremos aplicar un grupo de seguridad y tabla de rutas a dicha subred. De momento no haremos nada de eso, sólo comentar que los Grupos de Seguridad de Red son reglas de Firewall que podemos aplicar a la subred entera o en su momento a una máquina virtual. Esto nos permite controlar quien se puede conectar a que servicios, es muy práctico y muy simple de manejar:

En cuestión de segundos ya tenemos nuestra nueva subred disponible:

En la sección de Servidores DNS podemos dejar que Azure le asigne sus servidores DNS a las máquinas virtuales que vayamos creando o podemos definir nosotros mismos los servidores DNS que queremos pasarle a las máquinas virtuales. En mi caso voy a colocar la IP del nuevo controlador de dominio que voy a crear, para que el resto de máquinas virtuales que vaya creando ya tengan acceso al DNS interno y puedan encontrar mi dominio de Active Directory.

Hay muchas más opciones, pero no quiero tocarlas todas porque sino me voy a liar demasiado. Quiero centrar este artículo en configura la vNet y configurar la VPN entre Azure y CPD On-Premises. Por lo que seguimos con ello, una vez que tenemos las subredes definidas o por lo menos algunas, no las necesitamos declarar todas ahora, lo podemos hacer en función de nuestras necesidades, pero bueno, por lo menos ya tengo donde voy a poner a mis controladores de dominio.

Antes de poder crear la puerta de enlace VPN , debemos crear nuestra subred de puerta de enlace. Dicha subred, es la que tendrá las direcciones IP públicas que se utilizarán en las máquinas virtuales de la puerta de enlace que crearemos más adelante. Este proceso tardará unos 45 minutos, por lo que es bueno hacerlo cuanto antes, El proceso es muy simple, desde la sección de subredes dentro de nuestra red virtual tenemos la opción de Subred de puerta de enlace, pues pulsamos en dicha opción:

Ahora le indicamos el intervalo de direcciones donde se situará, yo le he puesto la subred que no voy a utilizar con máquinas virtual, la 172.16.0.0/24 (recordad que yo he creado una subred con la red 172.16.0.0/16) y pulsamos en Aceptar

Ahora toca esperar eso 45 minutos ..

Una vez que se ha creado, ya la tenemos disponible desde la sección de Subredes:

Pues ahora tocar crear una la puerta de enlace de red virtual, esto es un tipo de puerta de enlace de red virtual que envía tráfico cifrado hacia un extremo (Azure u On-Premises) mediante una conexión pública. Es como si estuviéramos configurado nuestro “router virtual” en Azure, en donde luego configuraremos IPSec para conectarnos con nuestros CPD de On-Premises. En este caso es algo más complejo realmente, pero a nosotros no se nos traslada dicha complejidad. Mirad la descripción de MSFT con respecto a que es técnicamente una subred de puerta de enlace:

¿Qué es una puerta de enlace de red virtual?

Una puerta de enlace de red virtual se compone de dos o más máquinas virtuales que se implementan en una subred específica llamada GatewaySubnet. Las máquinas virtuales que se encuentran en GatewaySubnet se crean al crear la puerta de enlace de red virtual. Las máquinas virtuales de puerta de enlace de red virtual están configuradas para contener tablas de enrutamiento y servicios de puerta de enlace específicos de la puerta de enlace. No puede configurar directamente máquinas virtuales que formen parte de la puerta de enlace de red virtual y nunca debería implementar recursos adicionales en GatewaySubnet.

Cuando se crea una puerta de enlace de red virtual con el tipo de puerta de enlace “Vpn”, se crea un tipo específico de puerta de enlace de red virtual que cifra el tráfico: una puerta de enlace de VPN. Una puerta de enlace de VPN puede tardar hasta 45 minutos en crearse, ya que sus máquinas virtuales se implementan en GatewaySubnet y se configuran con los valores especificados. La SKU de la puerta de enlace seleccionado determina la potencia de las máquinas virtuales.

Crear una  puerta de enlace virtual es muy simple, vamos a agregar un nuevo servicio y buscamos por Puerta de enlace y elegimos la que os marco en verde. La que os marco en rosa es la que tendremos que configurar para definir la conexión con la red de On-Premises, vamos lo que representaría el otro extremos, pero de momento nos olvidamos de ello:

Previamente hemos seleccionado Puerta de enlace de red virtual, así que aquí solo nos queda pulsar en Crear

Ahora se nos mostrará un formulario para que especifiquemos los siguientes campos:

  • Nombre: como para mi representará el extremos final de la VPN hacia Azure para todas las conexiones de Europa, mi nombre es tal cual especifico
  • Tipo de Puerta de Enlace: en mi caso será una VPN tradicional, pero si tenéis la idea de montar un ExpressRoute (analogía de una MPLS en Azure), pues la elegís
  • Tipo de VPN: aquí os dejos las definiciones de MSFT sobre los diferentes tipos de VPN, yo he elegido basado en rutas:

Los dispositivos VPN basados en directivas usan las combinaciones de prefijos de ambas redes para definir la forma en la que se cifra/descifra el tráfico a través de túneles IPsec. Normalmente se basa en dispositivos de firewall que realizan el filtrado de paquetes. El cifrado y descifrado de túneles IPsec se agregan al motor de procesamiento y al filtrado de paquetes. 

Los dispositivos VPN basados en rutas usan selectores de tráfico universales (caracteres comodín) y permiten a las tablas de reenvío/enrutamiento dirigir el tráfico a distintos túneles IPsec. Normalmente se basa en plataformas de enrutador donde cada túnel IPsec se modela como una interfaz de red o VTI (interfaz de túnel virtual). 

Os dejo la URL donde tendréis una excelente explicación sobre este tema: Conexión de puertas de enlace Azure VPN Gateway a varios dispositivos VPN locales basados en directivas con PowerShell Disculpad que os vaya redirigiendo a estas URL, pero es que sino este artículo se me vuelve mega extenso.

  • SKU: es el tipo de puerta de enlace que tenemos disponible, en mi caso básico. Hay varios tipo de VPN (como de MV, etc..), que se escalan en función de nuestras necesidades, claramente cada uno tiene un coste diferente:

VPN SKU AZURE

  • Red Virtual: elegimos la red virtual que tenemos en Azure, la cual queremos conectar vía VPN con el otro extremos que configuraremos más adelante
  • Dirección IP Pública: será la IP Pública que tendremos asignada para esta VPN, la cual configuraremos en nuestro router de On-Premises como terminador de la VPN. Esto es algo que tenemos que crear en este mismo proceso sino tenemos ninguna previamente creada.
  • Suscripción: lo de siempre, donde se facturará la puerta de enlace
  • Ubicación: claramente yo sigo en el Norte de Europa

Ahora vamos por partes, hay varias cosas que tenemos que ir seleccionando, la primera la de Elegir una red virtual, pulsamos ahí y nos mostrará las redes virtuales que tengamos creadas y que queremos que conecte esta VPN, simplemente seleccionamos la red virtual que queramos conectar (yo ahora mismo sólo tengo una, así que .. no tiene mucha ciencia)

Otra de las opciones es la dirección IP Pública que tendremos en Azure para la VPN, pues bien, sino hemos creado previamente una, nos la creamos ahora. Pulsamos en el símbolo + desde la opción de Elegir una dirección IP Pública

Simplemente escribimos el nombre para el objeto de la IP Pública que vamos a crear y pulsamos en Aceptar

Ahora que ya tenemos todos, estamos preparados para finalizar el proceso, simplemente pulsamos en Crear

Tocar esperar unos minutos .. más o menos 30 minutos

Listo, ya tenemos nuestra puerta de enlace virtual lista para continuar con la configuración de nuestra VPN entre Azure y On-Premises: 

Como todo lo he creado desde el grupo de recursos creado para los servicios de red, ahora todo lo tengo allí disponible. 

Si pulsamos sobre la dirección IP Pública que hemos creado antes (VPN-NorthEurope-VIP-IP), veremos la IP que tenemos asignada

Si ahora pulsamos en la Puerta de enlace de red virtual, podremos ver su configuración:

Ahora toca configurar la conexión con nuestro extremo de On-Premises, para ello en la sección Conexiones dentro de la configuración de la puerta de enlace de red virtual, pulsamos en Agregar

Como siempre nos aparece un formulario que debemos completar:

  • Nombre: Nombre que le daremos a dicha conexión, siguiendo la nomenclatura actual pues … le establezco un nombre
  • Tipo de conexión: en este caso es De sitio a sitio (IPSec)

  • Puerta de enlace de red virtual: es lo que hemos estado creando, simplemente la seleccionamos
  • Puerta de enlace de red local: bien, aquí a lo que se refiere es por primera vez al otro extremo al que nos vamos a conectar, vamos nuestra red de On-Premises. Bien, pues se nos solicita la siguiente información:
    • Nombre: Para que podamos distinguir a quien nos conectamos, pongamos un nombre descriptivo de la oficina u otro nombre que sea representativo del dispositivo que tiene la dirección IP Pública a la que vamos a hacer referencia
    • Dirección IP: aquí especificaremos la IP Pública de nuestro terminado VPN de On-Premises.
    • Espacio de direcciones: aquí tenemos que poner las subredes locales que tenemos, las cuales queremos conectar con Azure. Esto a nivel de configuración en dispositivo Cisco sería las subred que definimos en la ACL que aplicamos al crypto-map.

Aquí os dejo un artículo sobre como configurar una VPN entre dispositivos Cisco utilizando certificados digitales: Cisco VPN IPSec Site-to-Site con Certificados Digitales

Aquí debéis poner mucha antención, porque si luego queréis modificar alguna subred local o añadir más direcciones IP, tenéis que desconectar la VPN y volver a configurarlo. No es complejo, pero bueno, que lo tengáis en cuenta ya. Una vez que hemos cubierto esta sección, simplemente pulsamos en Aceptar

Nos quedaría establecer la Clave Compartida, la cual se utilizará en la fase 1 de la negociación de IPSec. Es la clave compartida que ambos extremos (Azure y On-Premises) deben conocer y establecer la misma en ambos extremos. Ahora que ya tenemos todo listo, pulsamos en Aceptar

En cuestión de segundos ya tenemos Azure correctamente configurado a nivel de VPN, sólo nos quedaría configurar nuestro Router/Firewall de On-Premises para terminar la VPN y que se quede establecida:

En mi caso en el otro extremo tengo un Firewall de Fortinet, aquí os dejo las capturas de pantalla de la configuración que se ha realizado:

La configuración es muy sencilla, únicamente que cada uno tendrás sus subredes locales, etc… pero los parámetros para que se pueda establecer l la VPN si que serán iguales o parecidos a los que voy mostrando. Es una configuración estandard, por lo que se pueda afinar sin problema, pero ya los dejo a vosotros. Todo los parámetros que os vaya solicitando, son los que describe MSFT en sus plantillas de parámetros de dispositivos VPN  soportados para las VPN con Azure:  https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices

Aquí tenemos la Fase 1 de IPSec

La Fase 2

Un resumen de la configuración, las subredes IP local y remotas serán las que vosotros tengáis en On-Premises y en Azure

Ahora revisaremos los grupos de direcciones IP que aplicaré en las reglas IP para definir que subredes se conectarán y cursarán tráfico por la VPN:

Aquí tenéis la política definida en mi firewall, como veis se define que entre las redes de On-Premises y Azure no se utilizará NAT. He creado dos reglas como el nombre bien detalla:

Así se mostrarían como resumen de ambas directivas:

En el Firewall Fortinet se tiene que declarar una ruta estática para llevar el tráfico hacia el otro extremo (como me gusta Cisco, ahí lo dejo):

En mi caso como en al red tenemos implementado OSPF e EIGRP (protocolos de enrutamiento) pues aquí dejo la configuración básica de redistribución de rutas, de esta forma todas las sedes remotas podrán llegar a Azure de forma sencilla (en Azure ya he declarado todas las subredes locales que yo tengo, no sólo la de la sede con la que establecemos la VPN, sino todas las que se conectan entre si y la sede que se conecta directamente con Azure)

Hay algunos parámetros que tenemos que configurar desde la línea de comandos, como son los ajustes de TCP-MSS-SENDER | TCP-MSS-RECEIVER. Aquí os dejo dos artículos muy bonitos al respecto desde parámetro súper importante para el rendimiento de la VPN:

  • Fortinet: http://kb.fortinet.com/kb/viewAttachment.do?attachID=FortiGate-TCP-MSS-Option-V2.pdf&documentID=FD34973
  • Cisco: https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html

Una vez que he aplicado toda la configuración, ya podemos ver en el Fortinet que la VPN se ha establecido correctamente:

Si ahora voy a Azure desde de la puerta de enlace de red virtual, en la sección de conexiones podemos ver que la VPN está establecida:

Que la VPN esté establecida no quiere decir que funcione, puesto que podemos tener IPSec establecido pero si las subredes (Fase2) no las tenemos bien declaradas no tendríamos tráfico. Pero bueno, si pulsamos en la conexión establecida de la captura anterior, vemos que ya tenemos algo de tráfico como os muestro a continuación.

Hasta aquí no tenía ninguna MV en Azure, por lo que poco podía probar, pero luego cree una MV de pruebas y se podía llegar a cualquier subred de cualquier sede:

Por último, comentar que al principio había dicho que se podía conectar todas las sedes con Azure pasando por la sede que tenemos directamente conectada la VPN entre Azure y On-Premises. Para esto, debéis ajustar vuestras configuraciones, pero bien podéis hacerlo así tal cual comento o sino ir añadiendo más conexiones como hemos hecho con la oficina de On-Premises. Además, si tenéis un servidor de DirectAccess en la oficina principal (por ejemplo), con dicha sede tiene conexión con Azure vía la VPN, si configuráis una ruta estática en el servidor de DirectAccess ya tendrá acceso a la subred de Azure. Los que tengáis implementado DirectAccess me habréis entendido lo de porque una ruta estática, porque si tienes una configuración de dos tarjetas de red en el DirectAccess, la tarjeta que conecta con la red local no tiene gateway configurado, por lo que tenéis que ir creando rutas estáticas a algún dispositivo L3 para que pueda llevar a los clientes a las subredes internas. En este caso Azure es una más, de ahí lo de ajustar dicha configuración de servidor de DirectAccess.  Os dejo algunos artículo sobre DirectAccess por si queréis darle una vuelta a este comentario:

Espero que más o menos os haya quedado algo claro como configurar una VPN entre Azure y tu oficina/CPD On-Premises, espero no haberme dejado detalles que os hubieran sido importantes para vuestra configuraciones. Pero bueno, creo que como primer paso para ir moviendo tus máquinas o servicios a Azure está bien, para mi siempre o casi siempre es el primer paso, primero comunicaciones y luego computación.

En el siguiente artículo sobre Azure mostraré como mover una máquina virtual que se tiene en On-Premises hacia Azure y poder configurar y tenerla ya disponible para los usuarios en menos de 10 pasos.

Microsoft Teams, con
Moviendo nuestros se
1 COMENTARIO
  • Nestor Nunes / 3 diciembre, 2017

    Saludos , Santiago y una vez mas felicitaciones por Excelente articulos

    Bien , queria colaborar con algo que esta (o asi lo creo ) en modo beta y es Azure Active Directory Domain Services , que no es mas que un servicio que consiste en dos controladores de dominio en un nuevo bosque simple . Este servivio sincroniza los grupo y usuarios con tu inquilino de Azure AD asociado a tu suscripcion de Azure . Esto nos ofrece las siguientes capacidades:
    * Anexar Maquinas Virtuales de Azure que residan en la misma V-net o en otra N-Net conectada.
    * Los usuarios del forest On-Prem sincronizados con el Conector de Azure AD podran conectarse con sus credenciales en esas maquinas virtuales.

    Existen algunas diferencias por el momento con este servicio entre as cueales podemos citar:
    *La habilitacion de este servio solo puede ser ralizado por el portal viejo de azure (Azure Cloud Services) — Creo que hasta principios de Enero de 2018
    *No se permite crear relacion de confianza entre estos dos bosques ( On-Prem y Azure Servicio de Directorio)
    *Los usuarios y grupos estan en modo lectura
    *Limitado con la creacion de politicas de grupo , tan solo dos objetos de politicas de grupo ( Uno de configuraciones de equipos y el otro de usuarios)

    En resumen aunque es un servicio relativamente nuevo , ya podemos vizualizar que sera una alternativa para no crear controladores de dominio de nuestro servicio On-Prem en azure , de modo tal que represente algun ahorro en nuestras implementaciones.

    Saludos ,

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
Share This