Categoría: General

  • LACNIC31 – dia 1

    LACNIC31 – dia 1

    Iniciando con mi primera asistencia a este evento, hoy todo ha ido muy tranquilo.

    Llegada al hotel, registro al evento y asistencia a la Sesión para Becados. La sesión fue muy interesante y saber que aplicaron casi 500 personas para asistir como becados a LACNIC31, de los cuales solo se seleccionaron 38 (conté la lista en lacnic.net) y saber que he sido uno de ellos me emociona mucho, y esa es la razón por la cual verán posts relacionados a LACNIC31 toda esta semana.

    Luego de terminar la Sesión para Becados, me quede para la segunda sesión del día que fue relacionada a las políticas que se van a discutir en esta semana.

    Es importante participar de las discusiones de políticas en LACNIC, aunque no lo he hecho anteriormente pretendo activarme en lo que a esto respecta para cambiar algunas cosas que personalmente no me gustan de cómo funciona la asignación de direcciones en LACNIC, eso es un tema para otro post.

    Aquí esta la lista de políticas que están para discusión, si les interesa claro.

    https://politicas.lacnic.net/politicas/list?state=ENDISCUSION

  • LibreNMS – backups con Oxidized.

    LibreNMS – backups con Oxidized.

    Si cuentas con una red con más de dos dispositivos (router o switch), debes considerar realizar respaldos de manera automatizada a esos equipos, está de más decir que también tenemos que monitorear el comportamiento de estos equipos. Podemos monitorear valores tales como CPU, memoria, estado de las interfaces de red y cantidad de tráfico que pasa por estas, esto es solo por mencionar algunos de los objetos disponibles en un equipo de red.

    Sorpresa, todo esto se puede hacer con LibreNMS.

    Esta plataforma de monitoreo es un fork de Observium el cual cambio su modo de distribución a uno más cerrado y esto causo que usuarios como YO se movieran a LibreNMS. Recuerdo haber usado un paso a paso de cómo mover la data de un software al otro.

    En esta entrada nos saltaremos la parte donde instalamos LibreNMS, en la página del proyecto oficial se puede encontrar esta información.

    Oxidizedhttps://github.com/ytti/oxidized

    Como dice su README en GitHub, este es un intento de reemplazar RANCID, en mi opinión este proyecto ha logrado su cometido, mi experiencia con RANCID no fue la más hermosa o placentera.

    Debian es la distribución en la cual está instalado LibreNMS, en la sección de instalación tienen varias distros, FreeBSD y Docker. Los pasos de instalación de Debian aplican para Ubuntu.

    Cuando toco instalar oxidized-web, este fallaba y al final pude determinar que faltaba g++, cuando instale Debian seleccione el mínimo de paquetes, lo extraño fue que también paso lo mismo cuando realice la misma instalación en Ubuntu.

    Configurando Oxidized –

    Una vez instalado los tres componentes, podemos proceder a generar una configuración por defecto la cual podemos editar más adelante. Es recomendado no ejecutar Oxidized como root, debemos crear una cuenta para este servicio.

    useradd oxidized

    Luego ejecutamos oxidized una vez para que sea creado el directorio y en este los archivos necesarios, aunque no usaremos algunos de ellos.

    Los Outputs son una parte esencial de la configuración, debemos seleccionar Git para contar con la funcionalidad de versiones dentro de LibreNMS.

    Aquí un ejemplo de configuración para Oxidized que funciona en LibreNMS, este es el usado en mi entorno actualmente.

    https://gist.github.com/aredan/8e44cb0485d196020472c9c870f1a60c

    En router.db no necesitamos colocar equipos, la integración de LibreNMS se encarga de eso y para que esta funcione debemos decirle a Oxidized cuál es la URL del API y crear un usuario, al mismo usuario debemos asignarle un Token para ser usado desde Oxidized.

    Oxidized como servicio –

    Muchas veces instalamos componentes que necesita inicializar con el sistema y este se encarga de colocar lo necesario, ya sea en init.d o en system.d, en el caso de Oxidized debemos hacerlo nosotros.

    https://github.com/ytti/oxidized#extra

    Para este momento debemos tener un Oxidized configurado y corriendo como servicio, ya que la manera de acceder estos respaldos será usando LibreNMS, podemos dejar oxidized-web escuchando solo en 127.0.0.1 siempre y cuando ambas plataformas están instaladas en el mismo equipo.

    Configurando LibreNMS –

    Usando la opción de configuración mediante Global Settings -> External Settings no funciono, ni siquiera presento errores en el log de LibreNMS, cuando introduje la configuración directamente en config.php, automáticamente apareció la opción de Oxidized en Overview -> Tools. Pasados unos minutos ya podía ver intentos de conexión desde la maquina con LibreNMS/Oxidized a los equipos de red que fueron definidos en la configuración de Oxidized.

    $config['oxidized']['enabled'] = TRUE;
    $config['oxidized']['url'] = 'http://127.0.0.1:8888';
    $config['oxidized']['features']['versioning'] = true;
    $config['oxidized']['group_support'] = true;
    $config['oxidized']['default_group'] = 'default';
    $config['oxidized']['reload_nodes'] = true;
    $config['oxidized']['group']['os'][] = array('match' => 'nxos', 'group' => 'nxos');
    $config['oxidized']['group']['os'][] = array('match' => 'ios', 'group' => 'ios');
    $config['oxidized']['group']['os'][] = array('match' => 'fortigate', 'group' => 'fortinet');
    $config['oxidized']['group']['os'][] = array('match' => 'routeros', 'group' => 'routeros');

    En las últimas cuatro líneas están definidos los equipos que quiero que LibreNMS compare contra Oxidized, por lo menos así lo entendí yo.

     

     

    Aquí algunas capturas de pantalla de LibreNMS accediendo a los respaldos realizados por Oxidized.

     

  • Fortigate – usando un modem 3G como failover Internet.

    Fortigate – usando un modem 3G como failover Internet.

    Desde los inicios del uso de pfSense en mi casa, me gustaba la idea de tener dos conexiones a Internet y varias veces así fue. Alta disponibilidad en la conexión a Internet, como no era un requerimiento este fácilmente se retiraba y terminaba con una sola conexión.

    ¿Porque hacerlo nuevamente? ¿Y esta vez sin pfSense?

    Últimamente la infraestructura de conectividad en nuestro país está cada vez más robusta, pero eso no quita una falla física, ya han sido tres las veces que de una u otra manera un camión se las arregla para romper la fibra que conecta mi modem Huawei con Claro. Ni modos, estoy tratando de justificar por qué he conseguido un modem USB 3G y comprado un SIM de VIVA con data ilimitada.

    Materiales:
    
    FortiWiFi 60D
    
    Huawei E397 – unlocked
    
    Paciencia ¡

    Después de varios intentos con otros equipos usb, resulto que el menos pensado fue el usado al final ya que soporta las bandas empleadas por VIVA en su red 3G/4G.

    Esta es la configuración del dispositivo usb:

    Nota: no sé si el valor de la entrada extra-init1 debe ser en mayúscula, por lo menos la parte de AT+CGDCONT, cuando estaba en minúscula no funciono.

    Un dato importante es distance y priority, estos valores deben ser iguales a los de la otra conexión a Internet si queremos usar SD-WAN sin jugar mucho con Policy Routes.

    Una vez que se habilita la funcionalidad (set status enable), tendremos una nueva opción Network -> Modem.

    Aquí se puede ver formando parte del servicio de SD-WAN.

    SD-WAN Status Check:

    Para que la configuración de failover tenga efecto y no sea un balanceo de conexión, debemos asignar prioridad a la WAN1, en mi caso:

    Listo, ahora Gabriela y Abigail podrán ver sus videos en YouTube en caso de un corte en la fibra de Claro.

     

  • Usando pfBlockerNG en pfSense 2.2.2

    pfSense es el firewall OpenSource favorito para mí, desde mucho tiempo lo he usado dentro de mi red casera y de tal manera lo he usado en lugares donde he trabajado.

    Una de las ventajas de este firewall son sus plugins que nos ayudan a adicionar funcionalidades, pfBlockerNG es uno de ellos y este nos trae funcionalidades de bloqueo de direcciones IP de países y la creación de Alias basados en listas públicas o listas creadas por uno mismo, en mi caso he creado una lista personalizada con todas las direcciones asignadas por LACNIC a República Dominicana.

    Para entender cómo funciona pfBlockerNG he usado una guía publicada en Security Artwork (Bloqueando tráfico con pfBlockerNG). Luego utilizando un poco de bash scripting he creado un pequeño script que descarga la lista oficial de LACNIC, la filtra buscando .DO y luego crea un archivo de TXT con el formato necesario para que pfBlockerNG pueda hacer uso de él.

    Este alias lo uso para varias configuraciones en mi red local, como por ejemplo no hacer uso de la VPN creada usando PIA y que todo tráfico “local” sea enviado sin encriptar.

    Posiblemente para otros esto no tengan ninguna utilidad pero a mí me pareció bien poder tener una excepción y no enviar ese tráfico vía VPN.

    http://aanetworks.org/iprange/

  • FreeLoadBalancer.org – Kemp LoadMaster para el HomeLab.

    KEMP es un proveedor de soluciones para alta disponibilidad y balanceo de carga (LoadMaster), mi primer contacto con el producto fue buscando una solución tipo empresarial para reemplazar Ngnix y/o Apache (mod_proxy). Uno de los primeros escenarios donde leí sobre el despliegue de las soluciones de LoadMaster (LVM100 para ser exacto) fue con vSphere Web Client y Exchange Server.

    Cuando fue mi turno de desplegar LoadMaster lo hice usando ESXi como plataforma y en ese momento use dos servidores físicos cada uno con una VM de LoadMaster.

    Para ese momento KEMP no tenía una versión gratuita como lo hace ahora y por esta razón no podía jugar con la solución en el homelab, ahora todo cambia, hace varios días KEMP anuncio la versión gratuita que tanto he esperado e inmediatamente un VLM y estoy probando como configurar la plataforma y reemplazar un ZenLoadBalancer que tengo corriendo desde hace un tiempo y es el usado para publicar muchos de los servicios que uso de prueba o uso personal.

    La configuración tradicional de un LoadMaster es para tener alta disponibilidad de un aplicativo web, digamos un Lync, Exchange o VMware Horizon View. En mi caso la idea de usar LoadMaster (como lo ha sido con ZenLoadBalancer) es poder publicar todo lo que necesite ya sea HTTP(80) o HTTPS(443) usando una única dirección IP (o varias si es necesario). Me gustaría aclarar que la solución ZenLoadBalancer no me ha fallado y ha cubierto la necesidad que tenía, entonces porque cambiarlo?

    La decisión podría decirse que es personal ya que pienso, es más probable que termine administrando un LoadMaster a que me encuentre o que decida instalar ZenLoadBalancer en un ambiente empresarial.

    Las funcionalidades, si miramos en http://freeloadbalancer.com. Podemos ver que la versión gratuita nos trae Layer4-7 Load Balancer, Reverse Proxy, Edge Security, WAF (Web Application Firewall) y GSLB (Global Server Load Balanceing), para ser versión gratuita tiene buena pinta, la única funcionalidad que podría hacer falta es HA pero como esto esta apuntado a pequeñas empresas o homelab como es mi caso puede que sea la razón de que no esté disponible HA.

    Para más información de las diferencias se puede ver directamente en http://freeloadbalancer.com

    La razón de este post es tratar de documentar los pasos y configuraciones que necesite para poder usar LoadMaster como un Reverse Proxy que es actualmente como uso ZenLoadMaster en mi homelab, una diferencia que aplica en mi homelab es que dos de los host ESXi están en un datacenter a unas cuantas miles de millas de mi localidad y me conecto con ellos a través de una VPN tipo mesh (Tinc VPN). Para LoadMaster los Real Servers no están en la misma subred e inicialmente falla al ser agregados en los Virtual Servers si no hacemos los cambios necesarios, esto podría aplicar si los VirtualServers están en 192.168.100.0/24, los RealServers están en 192.168.200.0/24 y el LoadMaster está en modo One-ARM.

    Aquí un pequeño diagrama de red donde se ve un VLM en un lado de la red:

    Lo primero que debemos hacer es definir algunos Content Rules.

     

     

    En mi caso quedo algo asi:

    Aquí se puede ver mientras modifico una regla llamada guacamole:

    Procedemos a agregar un Virtual Server, en mi configuración inicialmente tendré un Virtual Server para el puerto 80 y otro para el puerto 443.

    En Advanced Properties habilitamos Content Switching.

    Ahora toca crear los SubVS que queramos o necesitemos. Actualmente solo tengo 2 en la parte de HTTP:

    Como se puede ver en la imagen anterior, ya estos 2 SubVS tienen Content Rules habilitadas y seleccionadas, si hacemos click en el numero podremos remover o agregar otro Content Rule.

    Con relación a los Real Servers, estos serán agregados en cada SubVSs, cuando usamos Content Rule los Real Servers podrían ser el mismo ya que el Content Rule se encargaría de definir el Host Header y re-direccionar el tráfico a donde sea necesario.

    Lo importante es tener en cuenta los Content Rule, allí es donde decidiremos cuales dominios serían los aceptados, esto es parecido a los Virtual Name de Apache.

    Otra configuración que tuve que aplicar en mi caso fue habilitar fue la de Eable Non-Local Real Servers que se encuentra en System Configuration > Miscellaneous Options > Network Options., además de esto los Virtual Servers no pueden tener habilitado Transparency.

    Aquí la documentación oficial -> https://support.kemptechnologies.com/hc/en-us/articles/201849033-How-do-I-add-remote-Real-Servers