Creación de buzones compartidos en entornos híbridos: Exchange y Office 365

Esta semana me gustaría hablar de cómo crear buzones compartidos cuando nos encontramos en un entorno híbrido formado por un Exchange 2010 onpremise y Office 365, pero antes de nada veamos en qué consiste este tipo de buzón. Un buzón compartido es un buzón especial en el que a varios usuarios se les concede acceso sobre el mismo. Este recurso se crea en AD como un usuario deshabilitado que carece de contraseña y no tiene asociado ningún tipo de licenciamiento, sí lo tendrán los usuarios que accedan a él. Por tanto, se trata de una herramienta colaborativa bastante versátil.

Cuando nos encontramos en un entorno híbrido (por ejemplo una infractuctura con Exchange onpremise y Office 365) la creación del buzón no es directa, hay algunos parámetros asociados que si intentamos crear el buzón en Office 365 no van a aparecer. Así, el proceso tendrá varias fases: creación del buzón compartido on premise, añadir permisos sobre él y migrar el buzón a Office 365.

Creación del buzón en Exchange onpremise

Para crear el buzón debemos ir al servidor donde tengamos alojado el servicio de Exchange y darlo de alta a través de la shell de Exchange, ya que la creación de buzones de tipo compartido está deshabilitado en la interfaz gráfica.

En este ejemplo, solamente se han empleado solamente el nombre y el UPN pero podremos encontrar más parámetros para personalizarlo correctamente como la unidad organizativa donde ubicarlo, la base de datos, etc.

Asignación de permisos

Una vez creado, comprobaríamos que nos aparece en la EMC como shared Mailbox y podríamos agregarle los permisos apropiados a los usuarios.

 

Mover buzón a la nube

Después de realizar los pasos anteriores debemos esperar el tiempo necesario para que se repliquen los cambios; iniciamos sesión en nuestro Tenant de Office 365, ya que todo el movimiento se tiene que realizar desde allí. (Si intentaramos realizar el proceso desde la EMC no recibiríamos ningún tipo de feedback del proceso, tanto si se hubiera realizado como sino).

Realizamos el movimiento del buzón con el comando new-moverequest.

Una vez completado podremos observar que nos figurará en Office 365 y podremos emplearlo.

Errores que nos podemos encontrar

A la hora de realizar el movimiento del buzón nos podremos encontrar con varios errores, aquí voy a mencionar 2:

El destino tiene ya este mailbox primario. Esto se produce porque estamos ejecutando el comando desde el entorno on premise y no desde Office 365.

mail02

El buzón no puede ser encontrado. Este error puede producirse por algún error con dirsync. Entre otros: que no haya pasado el tiempo necesario de replicación, que nuestro buzón esté ubicada en una OU no sincronizada o un posible fallo en la sincronización.

mail102

Y hasta aquí el post de hoy. Un saludo y , ¡¡hasta el próximo !!!

Clonar registros DNS externos en Microsoft DNS Server

Ya explicamos en otro post como resolvimos el problema de conectar la oficina de Sevilla, que sólo podía tener IP dinámica. Para mantener el direccionamiento actualizado, en el gateway de la oficina de Sevilla tenemos un pequeño script programado que comprueba si la IP asignada por nuestro ISP ha cambiado y en caso afirmativo lo modifica en nuestro proveedor DNS.

Sin embargo, y dado que en Plain Concepts usamos split-brain DNS, necesitamos alguna forma de propagar ese cambio a nuestros DNS internos. Aunque esto podemos conseguirlo de muchas formas, dado que asumimos que esta situación en la que una de nuestras oficinas sólo tiene IP dinámica será temporal, queríamos solucionar el problema de la forma más sencilla posible, pero sin que por ello dejase de ser elegante.

Como era de esperar, todo lo que necesitábaos era una estupenda combinación de PowerShell y el programador de tareas. Una de las grandes novedades del servidor DNS de Windows Server 2008 R2 fue que este podía administrarse desde PowerShell, dejando -desde mi punto de vista- de lado al ya clásico dnscmd.exe. Así pues construí rápidamente un pequeño script que realiza las siguientes tareas:

  1. Consulta a un DNS externo (como Google u openDNS) la resolución del dominio pertinente, ej: oficina-sevilla.plainconcepts.com. Recordad que este dominio lo mantenemos siempre actualizado en nuestro proveedor DNS.
  2. Obtenemos de nuestro DNS interno el registro pertinente al dominio oficina-sevilla.plainconcepts.com. Como de costumbre, se nos devuelve un objeto de PowerShell.
  3. Clonamos el objeto y aplicamos la IP obtenida en el paso 1.
  4. Actualizamos el registro de nuestro DNS interno con el nuevo objeto clonado

El resultado sería el siguiente:

Todo lo que nos quedaría ahora es incluir este escript en el programador de tareas para que se ejecute automáticamente de forma periódica y tendríamos la IP siempre sincronizada con el DNS externo.

Happy resolution!

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.

Extender el esquema de Active Directory

Introducción

Active Directory nos proporciona toda la información que necesitamos para poder trabajar con cuentas de usuario en entornos multitarea Windows, pero ocasionalmente, necesitamos añadir información adicional sobre la que un despliegue estándar nos proporciona. El componente que define todos los atributos y objetos que AD usa para almacenar datos se llama Active Directory Schema. Para poder hacer cambios el en esquema, es necesario que una cuenta de usuario pertenezca al grupo “Schema Admins”.

schemaAdmins

Este artículo va a enseñar cómo extender el esquema de Active Directory agregando atributos personalizados.

Cómo agregar un atributo personalizado a Active Directory

Agregar un atributo personalizado consta de los siguientes pasos:

Preparar la MMC

En primer lugar, hay que instalar el complemento “Esquema de Active Directory” para la Microsoft Management Console (MMC).

Para ello, hay que abrir la ventana del símbolo del sistema y escribir “regsvr32 schmmgmt.dll”
Este comando registrará schmmgmt.dll en el equipo.

installExtension

Para ejecutar el complemento de esquema de Active Directory:

Hay que abrir la MMC, para ello, hay que hacer clic en Inicio y en Ejecutar, se escribe “mmc /a”. En el menú Archivo, haga clic en Agregar o quitar complemento y, después, en Agregar. Finalmente, en Complementos independientes disponibles, hay que añadir el snap-in “Esquema de Active Directory”.

MMC_snapin

Con el complemento de MMC ya cargado, es posible empezar a ampliar el esquema de Active Directory.

Agregar un atributo personalizado

Para ello, hay que hacer un click derecho en la carpeta de “Atributos” y seleccionar “Crear Atributo…”

New_attribute_mmc

Al hacerlo, aparece un diálogo de advertencia informándonos de que la creación de objetos del esquema es una operación de carácter permanente, y que aunque se pueden deshabilitar a posteriori, no se pueden eliminar y por tanto se convertirán en una parte permanente del AD.

permanency_schema_mmc

En el diálogo que se abre, hay que aportar una serie de información, como el “Nombre Común” del atributo (por ejemplo, “SyncCustomers” o “SyncOffice365”), un DisplayName para LDAP, un identificador X500 único (ver Anexo, un script PowerShell que genera identificadores X500 válidos), un comentario descriptivo (opcional), la Sintaxis (Lo más habitual para estos casos es elegir “Unicode String”), los valores mínimo y máximo (opcionales), y un checkbox para indicar si va a ser un atributo multivaluado o no. En este caso, no va a ser multivaluado.

AttributeCreation

Añadir el atributo a una clase

El atributo que se acaba de crear se puede añadir a una o más clases. Para hacerlo, hay que seguir los siguientes pasos:

  • En la herramienta administrativa de Esquema, ir a “Classes”, elegir la clase que hay que actualizar, y abrir sus propiedades.AddClassToUser
  • Una vez abiertas las propiedades, hay que acudir a atributos, hacer clic en “Añadir”, y elegir el atributo que acaba de ser creado.

AddAttributeToUser2

Con esto, se añade el atributo personalizado a la clase “Usuario”. En el caso de AADSync, también habría que añadir este atributo a la clase “Contacto”, lo que nos permite modificar este atributo a discreción para poder hacer un ajuste fino a los contactos que se van a sincronizar con Office 365.

Desactivar Atributos

Como los atributos añadidos a AD toman residencia permanente en el directorio, en ocasiones puede ser necesario desactivarlos, sea por el motivo que sea. En tal caso, la información de los siguientes enlaces puede ser sumamente útil:

http://social.technet.microsoft.com/wiki/contents/articles/22411.how-to-deactivate-schema-objects-in-active-directory.aspx

http://social.technet.microsoft.com/wiki/contents/articles/22414.how-to-get-the-list-of-deactivated-schema-objects-in-active-directory-using-powershell.aspx

 

Anexo: Script Generador de OID

Cómo migrar CORREO de Google Apps Gmail a Office 365

 

Una de las muchas tareas que se realizan al cambiar de Google Apps  a  Office 365 es la migración de correo.  Esto es una buena idea si planteas dejar de utilizar tu vieja cuenta y centrarte en la nueva . De esta forma, es posible tener todo tu correo en un único sitio.

image

Por supuesto, existen múltiples formas de mover tus buzón de correo. Podemos contar con las herramientas propias de Office 365 , utilizar aplicaciones de  terceros que realizan migraciones IMAP o software diseñado para servicios de migración de la nube (si quisiéramos migrar nuestros contactos o el calendario) .

Aparte de lo ofrecido, Office 365 da  a cada usuario la posibilidad de conectar su cuenta de Gmail a su cuenta de Exchange Online desde OWA. Pero,  ¿qué ventajas nos ofrece este método frente a  las otras herramientas mencionadas?

  • Es fácil y rápido. El proceso se puede hacer en cuestión de pocos minutos.
  • No es necesario el acceso administrativo.  Es el usuario quien hace todo el proceso librando carga de trabajo al administrador.
  • Coste cero frente al pago por obtener herramientas de terceros.

Estas ventajas son muy útiles si queremos migrar nuestra correo de Google Apps a Office 365,  dado que el servicio de Google no ofrece acceso administrativo para este tipo de migraciones y la única forma es resetear la contraseñas de todas las cuentas a una clave común tal y como indica Microsoft aquí.

Entonces, ¿cómo puedo  conectar mi cuenta de correo de Google Apps a la de Office 365 para migrar todos mis mensajes?

Antes de iniciar la conexión hay que tener en cuenta lo siguiente :

  1. Debes habilitar el acceso POP en tu cuenta de Google Apps  ya que es el  único acceso soportado si queremos conectar la cuenta de este servicio.
  2. Cuando agreguéis la cuenta de Gmail como cuenta conectada, todo mensaje proveniente será almacenado en la carpeta de Bandeja de Entrada , incluyendo los mensajes enviados. Esto sucede por que Google usa etiquetas para clasificar los mensajes y no carpetas como en Exchange Online.  Es recomendable crear alguna regla que os permita reordenar todo el correo que vais a descargar si queréis que quede almacenado en las carpetas que tengáis.
  3. Sólo puedes conectar hasta cinco cuentas adicionales en Office 365. Con lo que una vez completado el proceso de migración , es recomendable eliminar la conexión si el número de cuentas a migrar supera el límite establecido.

Dicho esto,  para agregar la cuenta de correo de Google Apps como cuenta conectada, basta con acceder mediante OWA a nuestro buzón de Office 365.  Desde ahí, deberemos desplegar el menú de configuración y seleccionar el apartado de Opciones. Dentro de la sección de Cuentas , seleccionamos Cuentas Conectadas.

image

En la página de Cuentas Conectadas, agregamos (haciendo click en el símbolo ‘+’) la cuenta de correo que deseamos conectar e indicamos sus credenciales.

image

No os preocupéis si Office 365 os muestra un mensaje avisando  que no es posible establecer una conexión segura.  Aunque Google no reúne los requisitos de Microsoft para establecer una conexión automática de forma segura, se nos dará la posibilidad de utilizar un asistente de configuración para establecer la conexión de forma manual.

image

Al inicio del asistente,  deberemos indicar que la conexión será POP por los motivos que ya hablábamos al principio del artículo.

image

En el siguiente paso,  rellenamos la información de nuestra cuenta con los siguientes datos para que Office 365 pueda acceder a la cuenta a conectar y descargar el correo :

    • Nombre :  el nombre que queremos que se asigne a la cuenta a conectar.
    • Dirección de correo electrónico :  nuestra dirección de correo de Gmail
    • Nombre de Usuario :  el usuario con el que accedemos a nuestra cuenta.
    • Contraseña : la clave con la que nos logamos para acceder al buzón de correo de Gmail.
    • Servidor entrante : pop.gmail.com
    • Tipo de autenticación : Básica
    • Cifrado : SSL

image

Introducidos  dichos datos, el asistente empezará a importar correo a nuestro buzón de Office 365. Podremos seguir el estado del proceso de migración en la página principal de  Cuentas Conectadas. Una vez finalizado,  (el estado de la conexión mostrará el mensaje   ACEPTAR  u OK)  todo el correo descargado podrá ser consultado en nuestro buzón.

image

image

¡Feliz Migración!

¿Cómo estar al día en Office 365?

La gente que trabaja a menudo con la suite de productividad por excelencia de Microsoft, seguro que se habrá hecho esta pregunta en innumerables ocasiones.

La nube avanza a velocidades de vértigo, cambiando completamente el paradigma de estudio necesario para estar al día de las novedades y cambios importantes que nos puedan afectar a nuestro entorno. Office 365 como conglomerado de varios productos, cada uno de ellos con unas posibilidades enormes y con su propia línea de desarrollo, hace que la actualización de la información relativa a los mismos fluya constantemente y sea difícil de seguir.

En este artículo, y derivado tanto de nuestra experiencia con clientes como de la formación interna, os planteamos los recursos que consideramos más importantes para estar al día en Office 365:

  • Grupo mundial de Yammer:

    Otra manera muy práctica de estar al día de las novedades es suscribirnos al grupo oficial de Yammer. De esta manera estaremos en contacto directo con el grupo de producto, MVPs (Microsoft Most Value Proffesionals), y personas de todo el planeta con las que compartir información, problemas y experiencias

    Yammer Office 365 Network: https://www.yammer.com/itpronetwork

    image

  • User voice:

    Durante los últimos años Microsoft ha proporcionado a los usuarios una plataforma llamada User Voice para poder dar feedback sobre cualquiera de sus productos. De esta forma el grupo de producto tiene una fuente importante de sugerencias, proveniente directamente de las necesidades de los usuarios, para poder orientar el desarrollo de las novedades.

    Office 365 User Voice: http://office365.uservoice.com/

    image

  • Centro de mensajes:

    Dentro de la administración de Office 365, existe un panel de información básico para que estemos al día. Se trata del Centro de Mensajes, y en él podremos encontrar advertencias sobre incidencias, información sobre novedades, etc.

    image

    También tenemos el panel inicial con el estado de salud de los servicios, para tener en un vistazo rápido la situación de cada uno de ellos:

    More controls for you to stay informed and manage change in Office 365 4

  • Office 365 Roadmap:

    Parada absolutamente obligatoria para conocer qué novedades están al caer, qué está en desarrollo, e incluso qué cosas han sido descartadas.

    Roadmap: http://roadmap.office.com/en-us

    image

  • Blog de Office 365:

    El blog es otra de las maneras de estar enterados de las novedades y además poder profundizar en aquellos temas que nos interesen. Con contenidos muy variados y de muy alta calidad, suscribirnos al RSS, seguir a la cuenta de Twitter o guardarlo entre nuestros favoritos es una tarea muy recomendable.

    Office Blogs: http://blogs.office.com/

    image

Esperamos que toda esta información os sea de utilidad y no volváis a tener problemas en estar actualizados con todo lo que rodea Office 365.

Happy studying!

Conectando redes con NAT e IP dinámicas mediante VPN site to site a Azure

Como os hemos explicado en otras ocasiones, en Plain Concepts estamos estableciendo las redes de todas nuestras oficinas en torno a un hub central en Microsoft Azure, siguiendo una topología de estrella. La topología que tenemos diseñada se parecería –en grandes rasgos- a lo siguiente:

image

Evidentemente, utilizaríamos las capacidades del Azure Network Gateway con enrutamiento dinámico para poder establecer múltiples túneles IPsec site to site entre las distintas sedes. Sin embargo, y tal y como os hemos comentado en otros artículos, es necesario cumplir con una serie de requisitos para poder conectarse a Azure, entre los que se encuentran:

  • Disponer de un dispositivo gateway compatible, o bien una máquina Windows Server 2012 R2 ó UNIX (GNU/Linux incluido).
  • No debe haber ninguna clase de NAT entre los gateway que vamos a conectar, es decir, el nuestro y el de Azure.
  • Debemos disponer de una IP pública fija.

En una de nuestras oficinas nos hemos encontrado con un problema: no teníamos la posibilidad de disponer de IP fija, con lo que incumplíamos los requisitos y se tornaba imposible conectar la oficina dados los requerimientos. El procedimiento obvio era contratar una IP fija, pero ningún proveedor de fibra nos ha dado la opción, y como tampoco es menester de este artículo o blog discutir sobre las telcos, vamos sencillamente a tomar esa restricción como insalvable. La situación es esta:

image

Solución 1: Azure User Defined Routes e IP forwarding

Entre las grandes novedades del Build 2015 se encuentran importantes mejoras en el networking de Azure con la inclusión de las siguientes características:

Usando estas características podríamos establecer una máquina virtual en Azure como dispositivo de gateway para nuestra red virtual, de forma similar a como hicimos con Amazon Web Services. Así podríamos superar algunas de las limitaciones impuestras por el gateway de Azure.

Aunque esta sería la solución ideal, he de decir que me encontré con dificultades configurando el dispositivo y con muy poca documentación al respecto. Nada que reprocharle a Microsoft dado que son características que llevan muy poco tiempo publicadas; así que es una mera cuestión de esperar algunos meses a que tengamos documentación detallada.

Solución 2: Utilizar Amazon Web Services como intermediario

No podemos decir que no estemos sacando provecho del experimiento que hicimos para el Global Azure Bootcamp 2015. Si entre la red de Sevilla y la red de Azure ponemos alguna pasarela que sí cumpla con los requerimientos de Azure y las reestricciones de Sevilla, esta máquina podría encargarse de dirigir el tráfico entre ambos entornos.

Podríamos haber cumplido este requerimiento utilizando la red on-premises de Madrid, pero nos pareció oportuno dar a Sevilla independencia desde el punto de vista de infraestructura, por lo que desplegar una máquina en Amazon Web Services me pareció una solución ideal. El diagrama sería el siguiente:

image

Implementando la solución 2: los pasos

La implementación de la solución 2 se realiza a través de los siguientes pasos:

  1. Crear una VPC en AWS con una máquina virtual basada en GNU/Linux. En mi caso elegí Ubuntu 14.04 LTS, pero serviría cualquier distribución, incluso algún otro sabor de UNIX como FreeBSD.
  2. Configurar la red virtual de Azure y su gateway para conectar con la recién creada red de Amazon, tal y como ya explicamos en este artículo.
  3. Ya establecida la conexión en Azure y Amazon, debemos realizar lo propio en la misma máquina entre Sevilla y Amazon, asegurándonos de cumplir con los requerimientos de Sevilla, es decir, usar IP dinámica.

Estableciendo un túnel IPsec con IP dinámica en un extremo

El núcleo tecnológico de este artículo es precisamente establecer un túnel entre dos extremos: uno con IP fija y otro con IP dinámica utilizando IPsec, cosa que es posible si tenemos control de ambos. Dada la buena experiencia que nos ha dado siempre, he optado de nuevo por usar StrongSwan, con su potente implementación de IPsec con IKEv2. StrongSwan corre sobre Linux, Android, FreeBSD y Mac OSX.

Cabe destacar que no hemos usado ningún protocolo adicional para el transporte comó podría ser L2TP, dado que IPsec con IKEv2 ha funcionado estupendamente en modo túnel.

La máquina GNU/Linux usada para la implementación tiene las siguientes características:

  • 1 único nucleo de CPU
  • 1 GB de RAM
  • 1 adaptador de red con dirección IP privada asociada
  • 1 IP pública que mapee los puertos 500/UDP y 4500/UDP al adaptador de la máquina virtual

 Configurando la máquina en Sevilla

Así pues entramos en la máquina GNU/Linux y ejecutamos:

Tras lo cual estamos listos para configurar el stack de IPsec en el extremo de Sevilla en el archivo /etc/ipsec.conf:

Los parámetros importantes a explicar son:

  • left. El extremo izquierdo del túnel, habitualmente la máquina que inicia la conexión. Normalmente aquí especificaríamos una dirección IP, pero recordemos que nuestra IP es dinámica, por lo que utilizamos una resolución de dominio precedida por %. Este modificador indica que aunque le vamos a sugerir una IP, aceptaremos cualquiera.
  • leftsubnet. La subred que vamos a exponer a través del túnel.
  • leftid. Importantísimo parámetro en el caso de una IP dinámica. Es un identificador que deberá cuadrar con el que el otro extremo solicite en el momento de la conexión, de forma que IPsec sepa que se está conectando al lugar correcto. Va precedido de @ para indicar que el dominio no debe resolverse, ya que se usa sólo como identificación.
  • right. El extremo derecho del túnel. Este es Amazon y aquí si tenemos una IP pública fija.
  • rightsubnet. La subred en el otro extremo a la que querremos acceder a través del túnel.
  • rightid. Similar al leftid.

Y tras ello debemos poner la PSK en /etc/ipsec.secrets:

Esta configuración nos debería permitir establecer la conexión, pero para que los paquetes que pasen por la máquina entren por el túnel debemos especificar la política correcta en iptables:

Si además estamos usando iptables para filtrar tráfico deberemos poner las reglas correspondientes para permitir los puertos 500/UDP y 4500/UDP.

Configurando la máquina en Amazon Web Services

Recordemos que esta máquina va a conectar tanto a Sevilla como a Azure, por lo que debemos configurar StrongSwan adecuadamente. Voy a presuponer que hemos realizado ya en ella los pasos detallados en este artículo y tenemos nuestro túnel con Azure ya funcionando.

¡No olvides permitir el tráfico IPsec en el Security Group de AWS!

image

Después hay que modificar el /etc/ipsec.conf:

Tras ello, de igual forma que hicimos en el gateway de Sevilla, deberemos configurar el archivo /etc/ipsec.secrets con las PSK tanto de Sevilla como de Azure, para poder establecer ambos túneles.

Y del mismo modo, las políticas de iptables:

Llegados este punto ya sólo nos queda hacer ipsec restart en ambas máquinas y consultar desde la máquina de Amazon el estado de ambos túneles. Si todo ha ido bien deberíamos poder ver algo parecido a lo siguiente:

image

Comprobamos el resultado con un PING de Sevilla a Azure:

Ping Sevilla-Azure

 

Y si hacemos un PING desde Azure a una máquina de la red de Sevilla:

Ping Azure-Sevilla

Algunos consejos ante posibles problemas

  • Muchos de los problemas de configuración que se pueden presentar estableciendo túneles IPsec suelen estar en la configuración de ambos extremos. ¡Asegurate de que cuadran perfectamente entre ellos!
  • En otras ocasiones, puede haber problemas de conectividad de red y firewalls, comprueba todas las políticas.
  • ¿Sigues con problemas? Examinar el log de StrongSwan puede ayudarnos a diagnosticar. Lo encontrarás por defecto en el Syslog, en /var/log/syslog.
  • Si el dispositivo o máquina donde establecéis el túnel es al mismo tiempo la puerta de enlace por defecto, no será necesario tocar ninguna tabla de rutas.
  • ¿Más dudas? ¡Déjanos un comentario!

Happy networking!