Tunel GRE + Multicast

Hace poco me toco trabajar de manera independiente sobre un problema que requeria hacer ingenieria inversa sobre una aplicación.

Escenario:

  • 5 sitios distribuidos geográficamente
  • Aplicación de gestión centralizada en un sitio
  • Equipamiento routers Cisco 1921 en cada uno de los sitios

Objetivo:

  • Sitios conectados entre si a través de conexiones a internet con capacidad de hacer uso de la aplicación de gestión.

A priori, parecía un trabajo bastante sencillo en donde una solución de VPN aplicaba perfectamente. Se me ocurrió hacer una captura con wireshark sobre un endpoint mientras hacía uso de la aplicación para entender un poco más sobre el tipo de tráfico y protocolos que utiliza para funcionar. Para mi sorpresa, para descubrir los servidores esta aplicación utiliza LLMNR (Link-Local Multicast Name Resolution), un protocolo simil DNS sobre multicast. Ouch!

LLMNR genera queries a direcciones multicast como la siguiente dirección:

  • IPv4 – 224.0.0.252, MAC address of 01-00-5E-00-00-FC
  • IPv6 – FF02:0:0:0:0:0:1:3 (this notation can be abbreviated as FF02::1:3), MAC address of 33-33-00-01-00-03

Leyendo un poco sobre como podría hacer para armar una configuración que permitiese tranmisitir tráfico multicast me encontré con túneles tipo GRE (Generic Routing Encapsulation), los cuales proveen una manera versatil de encapsular distintos protocolos, de capa 2 y 3 inclusive, y transportarlos sobre un vínculo P2P sobre una red IP. Si GRE se encapsula sobre paquetes IP como en este caso, se utiliza el valor 47 (0x2F) del campo Protocol del header IP.

Me fué de utilidad el filtro que se muestra en la captura de la Query LLMNR, que toma los paquetes con el bit menos significativo en 1 del byte más significativo de la MAC Address (eth.dst[0]&1)(definición de direcciones multicast). Se excluyen las direcciones broadcast ya que estan incluidas en el primer término de la regex !eth.dst==ff:ff:ff:ff:ff:ff.

 

Filtro para multicast Wireshark: (eth.dst[0]&1) && !eth.dst==ff:ff:ff:ff:ff:ff

Finalmente, el esquema de la topología se definió como 4 (N-1) túneles GRE entre el sitio central y cada uno de los sitios remotos.

Configuración túnel sitio A

Configuración túnel Sitio B

 

Las configuraciones más importantes son, por un lado, la habilitación global de ip multicast-routing y, por el otro, ip pim sparse-dense-mode, el cual habilitará a la interfaz virtual del tunel GRE a reenviar tráfico multicast. Esta configuración debe habilitarse en todas las interfaces Tunnel creadas. Además, se configuran rutas ip mroute para validar el tráfico entrante de multicast desde una interfaz túnel. No me detengo en otro tipo de configuraciones requeridas ya que no es el objetivo del post, pero harán falta listas de acceso, route-maps, NAT, etc.

Otra forma mas sencilla pero menos elegante de resolver este problema es utilizando la feature ip helper-address IP-SERVIDOR en las interfaces LAN de cada uno de los sitios remotos. ip helper-address no solo se utiliza en contextos de DHCP relay sino, también, para reenviar tráfico broadcast/multicast a un servidor puntual fuera de la red. Como en este caso el application server es único, hubiese sido una opción válida.

Fuentes:

  • http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/9356-48.html#dense
  • http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/43584-mcast-over-gre.html
  • http://librosnetworking.blogspot.com.ar/2016/05/ip-helper-address.html

:wq!

nerdear.la

Mañana asistiré por primera vez al evento nerdear.la y la verdad es que tengo mucha expectativa. Contenido de ediciones anteriores (publicado y a diposición de todos), podcasts y videos (polemica en /var) que viene armando el grupo sysarmy tienen un gran nivel. Además, la iniciativa propone entradas gratuitas y posibilidad de trabajar durante las sesiones asi que, si bien todavia no viví en carne propia la experiencia, aplaudo a los organizadores y a la iniciativa. Ojala el grupo crezca y contagie esta manera de compartir y hacer networking.

En nerdear.la la idea es aprender, divertirse y conocer más gente como vos. No nos importa qué Sistema Operativo usás, si sabés programar o no y ni siquiera si tenés experiencia. Es un evento de tres días en donde podés venir y:

  • Buscar ayuda para resolver problemas (y ayudar a otros)
  • Asistir a charlas y talleres
  • Compartir en qué estás trabajando
  • Conocer gente fantástica
  • Jugar juegos en grupo

:wq!

Historia puerto 22 en SSH

Por que no todas las historias son rebuscadas…

E-Mail de Tatu Ylonen, creador del protocolo SSH, al IANA (Internet Assigned Numbers Authority) el cual es el organismo que gestionaba y gestiona la asignación de puertos a aplicaciones.

 

Quienes se encontraban a la cabeza del organismo en aquel momento eran Jon Postel  y  Joyce K. Reynolds, creadores de los RFC IP, TCP, y otros pequeños protocolos. Al respecto, es muy interesante leer el RFC 1336 (Who is who in the internet, 1992), en donde se detallan las participaciones y los aportes de las personas más influyentes durante el comienzo de las definiciones de estándares y  protocolos de la red de redes.

A las pocas horas, Tatu recibe el siguiente correo del IANA (Joyce K. Reynold)

 

Fuente:

  • https://www.ssh.com/ssh/port

FLISoL – 2017

El FLISoL es el evento de difusión de Software Libre más grande en Latinoamérica y está dirigido a todo tipo de público: estudiantes, académicos, empresarios, trabajadores, funcionarios públicos, entusiastas y aun personas que no poseen mucho conocimiento informático..

El FLISoL se realiza desde el año 2005 y desde el 2008 se adoptó su realización el 4to Sábado de abril de cada año. La entrada es gratuita y su principal objetivo es promover el uso del software libre, dando a conocer al público en general su filosofía, alcances, avances y desarrollo.

El evento es organizado por las diversas comunidades locales de Software Libre y se desarrolla simultáneamente con eventos en los que se instala, de manera gratuita y totalmente legal, software libre en las computadoras que llevan los asistentes. Además, en forma paralela, se ofrecen charlas, ponencias y talleres, sobre temáticas locales, nacionales y latinoamericanas en torno al Software Libre, en toda su gama de expresiones: artística, académica, empresarial y social.

 

Restauración CMS desde replica local (RTCLOCAL)

Hace algún tiempo, estuve comprometido con la migración de una infraestructura Lync 2010 a Skype for Business. Después de tantas implementaciones, tantas migraciones y tantos problemas con los que me he topado debo admintir de que uno ya trabaja curado de espanto, pero la vida siempre nos sorprende con algo nuevo. La última tarea pendiente de la migración que acabo de comentar, estaba asociada al movimiento de la base de datos topológica de Lync llamada CMS (Central Management Store). Esta base en particular contiene información vital de la plataforma y es desde la cual todos los servidores y roles de la misma replican la información con la cual deben funcionar.

Cuando comencé con la tarea, me aseguré de seguir con los procedimientos recomendados por Microsoft (https://technet.microsoft.com/en-us/library/jj688013(v=ocs.15).aspx). Una vez con todo el ambiente y los cmdlets preparados empecé con lel movimiento de las bases.

Y cuando todo estaba por terminar, un hermoso mensaje que truncó el movimiento de las bases apareció

Aparentemente, la partición en donde se van a alojar los .mdf requiere de almenos 32GB libre (a pesar de que las bases pesaban, todas juntas, menos de 2GB). Este requerimiento, es de SQL Server y no de Skype for Business, por lo que en ningun momento se mencionaba en el procedimiento de Technet. Como si esto fuera poco, la situación en la cual habia quedado era la siguiente:

Es decir, el SCP (objeto de Active Directory que indica donde se encuentra el CMS) apuntaba aun al servidor 2010, pero el resto habia sido migrado. Momento que esto no es todo, si bien las bases que Skype for Business utilizaba a partir de la tarea de migración eran las de POOL2015, los datos de las bases no habian replicado…..

Por suerte la solución es bastante robusta, especialmente en el formato de Standard Edition por lo que esta situación de ausencia de CMS no llegó a afectar el funcionamiento en términos de usuario final a la plataforma. Los síntomas de este escenario eran los siguientes:

  • Servicios Skype for Business operativos
  • Usuarios registrados y utilizando el servicio correctamente
  • No hay replicación
  • No se pueden crear, modificar o borrar políticas, servidores u otros objetos de la topología

Puesto en imágenes…

Afortunadamente, Skype for Business trabaja de una manera similar a como lo hacen los protocolo de enrutamiento por estado de enlace. Es decir, funcionan con un mecanismo de replicación en donde cada uno posee una base de datos local con la información de toda la topología. Entonces…si el CMS no va a la replica, que la replica vaya al CMS.

Antes de empezar con esta tarea, se regularizo el puntero SCP hacia POOL2015 y se intentó restaurar la base del CMS con el procedimiento siguiente https://technet.microsoft.com/en-us/library/hh202172(v=ocs.15).aspx, en donde básicamente se instalan manualmente las bases de CMS (la estructura de tablas vacía), se importa el backup tomado con Export-CsConfiguration y se realiza un Enable-CsTopology.

Lamentablemente, luego de ejecutar este procedimiento de restauración, la base arrojaba errores de lectura y la situación seguía siendo la misma. Por este motivo se decidio ejecutar un restore desde la replica que el Front End de Skype for Business (POOL2015) estaba corriendo, la cual había permitido hasta el momento que todos los usuarios de la infraestructura siguieran usando el servicio. Resumiendo…estábamos a esta altura en el paso 4 del diagrama.

Finalmente, el procedimiento que dio con la solución se adjunta a continuación.

Espero sinceramente que nadie tenga que usar este procedimiento, jamás.

Fuentes

  • three65.blog/2015/09/30/skype-for-business-recover-your-deployment-from-a-deleted-or-corrupt-cms
  • ucvnext.org/2016/05/dissecting-a-failed-cms-migration-in-lync-server-2013-due-to-lrs-meeting-portal
  • ucvnext.org/2016/01/migrating-cms-in-lync-server-and-skype4b-server

Inter-trunk routing Skype for Business

Inter-trunk routing es una feature relativamente nueva en Skype for Business, fue agregada en la versión Lync 2013 por primera vez. Esta funcionalidad permite que  la solución se comporte como un enrutador de llamadas y no solamente como origen o destino de ellas. Esto será de especial utilidad en escenarios de integración o migración.

Un ejemplo de estos escenarios se puede observar en la topología que se adjunta a continuación

Aqui se puede observar que Skype for Business posee un sip trunk directo con un media gateway AudioCodes el cual, a su vez, posee dos troncales E1 con salida directa hacia la red PSTN. Por otro lado, Skype for Business se conecta con dos IP PBX a traves de un SIP trunk. La idea de utilizar inter-trunk routing es lograr la comunicacion entre extensiones de las distintas plataformas y salida directa a PSTN desde los usuarios de las IP PBX conectadas a traves de Skype for Business.

Para lograr esta configuración, deberan crearse PSTN Usages que hagan matching con los rangos de numeración asociados a las IP PBX y con la numeración pública. Luego, deberan asignarse estas PSTN Usages en el campo Associated PSTN Usages del trunk correspondiente. Por ejemplo, para poder enrutar llamadas DID a extensiones de la PBX B que ingresan a través de las tramas E1, deberán asignarse PSTN Usages con los rangos de extensiones de PBX B al trunk entre Skype for Business y el AUDC M1K, esto permitirá que las llamadas que ingresan a través de ese trunk puedan ser enrutadas hacia la IP PBX correspondiente.

El mismo procedimiento deberá realizarse sobre los trunks que Skype for Business tenga con IP PBX A y IP PBX B, pero en este caso deberán agregarse PSTN Usages con permisos para llamadas hacia PSTN como se muestra a continuación

Una última aclaración que puede llegar a ser de utilidad, es que en algunos casos he tenido problemas agregando las PSTN Usages solo a los trunk configuration pool. Estos problemas se solucionaron cuando agregue los permisos, también, en el contexto global.

Fuentes

  • http://ucken.blogspot.com.ar/2013/06/inter-trunk-routing-in-lync-2013.html
  • https://technet.microsoft.com/en-us/library/jj721940.aspx

:wq!

OpenWRT en TL-WR941D

Que es OpenWRT?

OpenWrt es una distribución de Linux basada en firmware usada para dispositivos empotrados tales como routers personales.
El soporte fue limitado originalmente al modelo Linksys WRT54G, pero desde su rápida expansión se ha incluido soporte para otros fabricantes y dispositivos, incluidos el Netgear, D-Link, ASUS y algunos otros. El router más popular sigue siendo el Linksys WRT54G y el ASUS WL500G. OpenWrt utiliza principalmente una interfaz de línea de comando, pero también dispone de una interfaz WEB en constante mejora. El soporte técnico es provisto como en la mayoría de los proyectos de Software Libre, a través de foros y su canal IRC.

Ahora la pregunta es: Sabiendo que podes tener GNU/Linux en tu router, y tunear el sistema a medida de tus necesidades instalando un SQUID, OpenVPN, un servidor DNS local o IPTABLES en el mismo hardware que actualmente solo hace de gateway con internet, por que no lo harias?

Si te decidiste a hacerlo, lo mejor es que empieces buscando si tu router es compatible con openWRT aqui: http://wiki.openwrt.org/toh/start

La wiki del modelo TL-WR941ND de TPLink v3 es: http://wiki.openwrt.org/toh/tp-link/tl-wr941nd

Caracteristicas del TP-Link TL-WR941ND

The device is a wireless N router with:

  • 2.4Ghz (HT40 capable)
  • 3 detachable antennas
  • 4 Port 100/10 Switch
  • 1 Port 100/10 Wan Interface
  • Unpopulated serial and USB headers
  • 4 MB Flash or 8 MB Flash (v1 is 8 MB)

La unica desventaja que encontre por el momento de este modelo es que solo cuenta con 4MB de memoria FLASH, lo que imposibilita instalar algunos paquetes de software.

Como se puede apreciar en la wiki de openWRT la documentacion es excelente y esta todo perfectamente detallado, pero por si alguno tuvo algun inconveniente los pasos de instalacion son los siguientes:

Se descarga la imagen y desde la GUI Web del router la instalamos como si fuese una actualizacion de firmware. Luego de esto el router se reiniciara y dejara de tener acceso via http.

 

 

 

 

 

 

 

Con un nmap a la ip 192.168.1.1 ( mantiene la que tp-link usa por default ) vemos que:

Ahora entramos por telnet y cambiamos la password de root con el comando passwd, reiniciamos y dejaremos de tener acceso via telnet para poder acceder via ssh con el user root y la pass que acabamos de configurar.

Oh sorpresa! no tenemos interfaz web y tampoco reconoce la placa Wireless del equipo!
Pero al mejor estilo debian lo solucionamos de la siguiente manera:

WiFi

Luci GUI

Ahora podemos ingresar via la GUI Web a traves del link: http://192.168.1.1/cgi-bin/luci

Para unsar servicios de Dyndns instalamos el paquete:

De aqui en adelante, pueden hacer lo que quieran 🙂
Se que hay un modelo mas arriba que el 941 que tiene puertos usb que podemos montar como unidad del sistema y usarlos para almacenar la cache de un squid y los logs del equipo entre otras cosas.

Algunos comandos dentro del equipo:

:wq!

 

SMTP Matching O365

Un escenario común durante proyectos de implementación con servicios en la nube de O365, es tener que integrar dominios de Active Directory on premise con dominios de Active Directory Azure. En algunos contextos, los usuarios en la nube ya han sido dados de alta y estan utilizando diversos servicios como Exchange, Skype for Business, Sharepoint, etc. Lo deseable en estos casos, es lograr que los usuarios on premise se sincronicen de forma tal que se realice un merge con los usuarios en O365 y se convierta en una implementación híbrida, donde el objeto usuario será único para ambas infraestructuras y será el que se encuentra en el servidor de Active Directory on premise.

Para que esto suceda, como los usuarios han sido dados de alta con anterioridad en O365, se aprovechará el campo Proxy Addresses para realizar la operación de merge a través de su dirección de correo (SMTP). A este método se lo llama SMTP Matching.

smtp_matching

Proceso SMTP Matching para unificar objetos usuario entre infraestructuras On Premise y O365

El procedimiento es relativamente sencillo,  lo que debe hacerse es relevar las direcciones de correo principales de los usuarios en O365 y popular los campos Mail y ProxyAddresses en los usuarios de Active Directory on premise, luego sincronizar. Puede suceder que se tenga un error de sincronización por valores de atributos duplicados, esto pasa debido a que el SMTP Matching se realiza, además de los campos mencionados anteriormente, a través del ImmutableID. El campo ImmutableID almacena el mismo valor que el campo ObjectGUID del Active Directory on premise pero en formato Base 64. Por lo tanto, deberá generarse un script para mapear tambien este atributo una vez que se hayan cargado los valores SMTP address.

Error:

Ejemplo del procedimiento:

  • SMTP Principal O365: joaquin.gonzalez at smartqube dot com dot ar
  • UPN Público: smartqube.com.ar

Populamos los campos en AD on premise

12

 

 

 

Mapeamos el campo ObjectGUID (AD on premise) con ImmutableID (O365)

Verificamos objetos antes de sincronizar

5

Sincronizamos Azure AD Connect

34

Verificamos que el objeto on premise hizo un merge con el objeto en O365

6

Fuentes:

  • https://support.microsoft.com/en-us/kb/2641663
  • http://www.joseph-streeter.com/?p=423
  • https://dirteam.com/dave/2014/08/15/fixing-office-365-dirsync-account-matching-issues/

Powershell y conexión a servicios de Office 365

Ultimamente me ha tocado trabajar en multiples proyectos de migración e implementación de entornos híbridos de Exchange y Skype for Business en Office 365. Lamentablemente, las consolas de administración de los servicios no se encuentran consolidadas en una sola interfaz y puede llegar a ser bastante molesto tener que conectarse una y otra vez los diferentes servicios, por eso puede ser útil generar una función que lo haga por nosotros.

Luego de creado el archivo $Profile, podemos generar nuestra funcion para conectarnos a los servicios de Office 365 de manera simultanea.

Ya tenemos nuestro método disponible en Powershell

1

2

Fuentes

  • https://thoughtsofanidlemind.com/2015/07/15/how-i-connect-to-exchange-online-with-powershell/