Los trabajos de administrador de sistemas, redes y demás similares son trabajos que trituran a la gente. Te tiene que encantar y disfrutar mucho para que no te triture, perdonad que lo diga así, pero es la pura verdad, estar recibiendo llamadas todo el día de gente nerviosa porque tienen un problema al final genera tensión y esa tensión la recibimos nosotros. El otro día a un cliente le fallaba una aplicación en un servidor suyo y llamaba, no le fallaba el servidor, pero sí la aplicación, al final es porque le estaban haciendo peticiones no deseadas desde distintos proveedores de servicios y hacían que el número de hilos del php-fpm se agotara. Esas IPs que estaban jorobando fueron descubiertas después de bucear por los logs un ratito por un compañero, no voy a decir quien, pero es el que bautizó a nuestra empresa. El tema es que al cliente, aunque es un encanto de persona (lo digo desde el corazón), le tenía yo al teléfono y claro, el cliente estaba nervioso y lo que hace es traspasarme su tensión y si esto te lo hacen 8 o 10 veces por semana durante 20 años pues algo se queda en el cuerpo. También puede ser que te de todo igual y que nada te afecte, pero la verdad es que yo eso no me lo he encontrado nunca. Pues si estás muy jodido ve a un profesional, que oye, no muerden y si no estás tan jodido pues puedes al menos hacer ejercicio, o eso es lo que nos dicen. Así que me he puesto a buscar información sobre cómo puede beneficiar al administrador de sistemas o de red el deporte. Hoy el cuerpo me pedía grabar un audio sobre esto porque con los años he descubierto que es algo fundamental en nuestro trabajo y llevo trabajando casi 30 años en esto. Después de investigar bastante he llegado a dos conclusiones.  El deporte tiene mucho que ver con nuestra profesión. El deporte nos ayuda a lidiar con los intentos diarios de traspasarnos los problemas de otros.  Aunque no parezca obvio a primera vista, hay varias conexiones entre el deporte y el trabajo de administrador de sistemas. Algunas de estas conexiones incluyen:  Trabajo en equipo: El trabajo en equipo es fundamental, en nuestra profesión y en el deporte, juntos somos mejores siempre. En un equipo de fútbol cada jugador tiene una tarea encomendada para que el equipo rinda adecuadamente, son parte de esa maquinaria. En nuestro sector igual, cada uno tiene su función y su punto fuerte y entre todos son fuertes en todo porque lo que no domina uno lo domina otro. Disciplina: Tanto en el deporte como en el trabajo de administrador de sistemas, se requiere disciplina para alcanzar los objetivos. Un deportista necesita seguir una dieta, un horario de entrenamiento, dormir adecuadamente para mantenerse en forma y competir a un nivel aceptable. Un administrador de sistemas por su parte tiene que seguir políticas y procedimientos para garantizar la seguridad, fiabilidad y rendimiento del sistema. Resolución de problemas: En el deporte muchas veces hay que tomar decisiones rápidas para solventar una situación, cómo le vas a dar con la raqueta a la pelota. En la administración de sistemas igual, tienes un problema y tienes que buscar la solución más eficiente para solventarlo. Gestión del tiempo: La gestión del tiempo es crucial en los dos mundos. Un deportista necesita planificar su tiempo cuidadosamente para asegurarse de que tiene suficiente tiempo para entrenar, recuperarse y competir. De manera similar, un administrador de sistemas necesita programar el mantenimiento y las actualizaciones del sistema para minimizar el tiempo de inactividad y garantizar que el sistema esté siempre en funcionamiento.  En resumen, aunque a simple vista parezcan disciplinas muy diferentes, tanto el deporte como el trabajo de administrador de sistemas comparten habilidades y valores fundamentales, como la disciplina, el trabajo en equipo, la resolución de problemas y la gestión del tiempo. Vale, aquí alguno me puede decir que muy bien, pero que podía haber hecho la analogía con cualquier otra cosa. Pero para poder sobrellevar ciertas incidencias y ciertos clientes hay que estar bien surtido de endorfinas que son sustancias químicas que ayudan a aliviar el dolor y mejorar el estado de ánimo, son las llamadas «hormonas de la felicidad». Esto pues ayuda mucho para superar una situación tensa derivada de una incidencia. Las endorfinas se generan haciendo deporte, no se si se podrán tomar pastillas, pero con un poco de deporte te sientes mejor. También nos pasa mucho a los informáticos que no dormimos bien, pues eso también tiene solución ¿sabéis cual? pues eso Luego hay una cosa muy importante. En nuestra profesión lo que vemos son problemas todo el rato, que es lo que menos pasa, evidentemente, pero es lo que nosotros vemos, aunque eso represente un porcentaje ridículo, así que hay gente con auténticos problemas por esto y llegan a casa hechos una mierda, tienen la autoestima por los suelos, algo que se puede superar también con el deporte, la primera vez que consigues acabar una carrera de 10km, aunque sea muriéndote, es una pasada. La primera vez que corrí 10km fue en una carrera por estas fechas en Pinto y una anciana nos gritó «Vamos, que sois los últimos«, aunque en ese momento quería insultar a la vieja (jajaja) cuando llegué la sensación fue increíble, y no, no llegué el último, algunos llegaron después, aunque es cierto que fueron pocos. Y sudar un poquito pues es cierto que reduce el estrés. Pues ya sabéis, aquí os dejo unos motivos para hacer un poco de ejercicio, no hace falta ir a las olimpiadas, pero si nos ayuda a estar mejor, pues bienvenido sea, porque cabeza sólo tenemos una.

Los trabajos de administrador de sistemas, redes y demás similares son trabajos que trituran a la gente. Te tiene que encantar y disfrutar mucho para que no te triture, perdonad que lo diga así, pero es la pura verdad, estar recibiendo llamadas todo el día de gente nerviosa porque tienen un problema al final genera tensión y esa tensión la recibimos nosotros. El otro día a un cliente le fallaba una aplicación en un servidor suyo y llamaba, no le fallaba el servidor, pero sí la aplicación, al final es porque le estaban haciendo peticiones no deseadas desde distintos proveedores de servicios y hacían que el número de hilos del php-fpm se agotara. Esas IPs que estaban jorobando fueron descubiertas después de bucear por los logs un ratito por un compañero, no voy a decir quien, pero es el que bautizó a nuestra empresa. El tema es que al cliente, aunque es un encanto de persona (lo digo desde el corazón), le tenía yo al teléfono y claro, el cliente estaba nervioso y lo que hace es traspasarme su tensión y si esto te lo hacen 8 o 10 veces por semana durante 20 años pues algo se queda en el cuerpo. También puede ser que te de todo igual y que nada te afecte, pero la verdad es que yo eso no me lo he encontrado nunca. Pues si estás muy jodido ve a un profesional, que oye, no muerden y si no estás tan jodido pues puedes al menos hacer ejercicio, o eso es lo que nos dicen. Así que me he puesto a buscar información sobre cómo puede beneficiar al administrador de sistemas o de red el deporte. Hoy el cuerpo me pedía grabar un audio sobre esto porque con los años he descubierto que es algo fundamental en nuestro trabajo y llevo trabajando casi 30 años en esto. Después de investigar bastante he llegado a dos conclusiones. <ul> <li>El deporte tiene mucho que ver con nuestra profesión.</li> <li>El deporte nos ayuda a lidiar con los intentos diarios de traspasarnos los problemas de otros.</li> </ul> Aunque no parezca obvio a primera vista, hay varias conexiones entre el deporte y el trabajo de administrador de sistemas. Algunas de estas conexiones incluyen: <ol> <li>Trabajo en equipo: El trabajo en equipo es fundamental, en nuestra profesión y en el deporte, juntos somos mejores siempre. En un equipo de fútbol cada jugador tiene una tarea encomendada para que el equipo rinda adecuadamente, son parte de esa maquinaria. En nuestro sector igual, cada uno tiene su función y su punto fuerte y entre todos son fuertes en todo porque lo que no domina uno lo domina otro.</li> <li>Disciplina: Tanto en el deporte como en el trabajo de administrador de sistemas, se requiere disciplina para alcanzar los objetivos. Un deportista necesita seguir una dieta, un horario de entrenamiento, dormir adecuadamente para mantenerse en forma y competir a un nivel aceptable. Un administrador de sistemas por su parte tiene que seguir políticas y procedimientos para garantizar la seguridad, fiabilidad y rendimiento del sistema.</li> <li>Resolución de problemas: En el deporte muchas veces hay que tomar decisiones rápidas para solventar una situación, cómo le vas a dar con la raqueta a la pelota. En la administración de sistemas igual, tienes un problema y tienes que buscar la solución más eficiente para solventarlo.</li> <li>Gestión del tiempo: La gestión del tiempo es crucial en los dos mundos. Un deportista necesita planificar su tiempo cuidadosamente para asegurarse de que tiene suficiente tiempo para entrenar, recuperarse y competir. De manera similar, un administrador de sistemas necesita programar el mantenimiento y las actualizaciones del sistema para minimizar el tiempo de inactividad y garantizar que el sistema esté siempre en funcionamiento.</li> </ol> En resumen, aunque a simple vista parezcan disciplinas muy diferentes, tanto el deporte como el trabajo de administrador de sistemas comparten habilidades y valores fundamentales, como la disciplina, el trabajo en equipo, la resolución de problemas y la gestión del tiempo. Vale, aquí alguno me puede decir que muy bien, pero que podía haber hecho la analogía con cualquier otra cosa. Pero para poder sobrellevar ciertas incidencias y ciertos clientes hay que estar bien surtido de endorfinas que son sustancias químicas que ayudan a aliviar el dolor y mejorar el estado de ánimo, son las llamadas «hormonas de la felicidad». Esto pues ayuda mucho para superar una situación tensa derivada de una incidencia. Las endorfinas se generan haciendo deporte, no se si se podrán tomar pastillas, pero con un poco de deporte te sientes mejor. También nos pasa mucho a los informáticos que no dormimos bien, pues eso también tiene solución ¿sabéis cual? pues eso Luego hay una cosa muy importante. En nuestra profesión lo que vemos son problemas todo el rato, que es lo que menos pasa, evidentemente, pero es lo que nosotros vemos, aunque eso represente un porcentaje ridículo, así que hay gente con auténticos problemas por esto y llegan a casa hechos una mierda, tienen la autoestima por los suelos, algo que se puede superar también con el deporte, la primera vez que consigues acabar una carrera de 10km, aunque sea muriéndote, es una pasada. La primera vez que corrí 10km fue en una carrera por estas fechas en Pinto y una anciana nos gritó «Vamos, que sois los últimos«, aunque en ese momento quería insultar a la vieja (jajaja) cuando llegué la sensación fue increíble, y no, no llegué el último, algunos llegaron después, aunque es cierto que fueron pocos. Y sudar un poquito pues es cierto que reduce el estrés. Pues ya sabéis, aquí os dejo unos motivos para hacer un poco de ejercicio, no hace falta ir a las olimpiadas, pero si nos ayuda a estar mejor, pues bienvenido sea, porque cabeza sólo tenemos una.

El trabajo de administrador de sistemas y el deporte

 La música de hoy, compuesta e interpretada por el gran DMNTR, podéis descargarla desde:  https://diagnoise.bandcamp.com/album/3435 https://diagnoise.bandcamp.com/album/nuclear-winter  Las notas del programa de hoy las tenéis en Motivos para cambiar tu centro de datos  Foto de Taylor Vick en Unsplash

<a href="https://diagnoise.bandcamp.com/album/nuclear-winter" rel="noopener nofollow" target="_blank"> </a>La música de hoy, compuesta e interpretada por el gran DMNTR, podéis descargarla desde: <ul> <li><a href="https://diagnoise.bandcamp.com/album/3435" rel="noopener nofollow" target="_blank">https://diagnoise.bandcamp.com/album/3435</a></li> <li><a href="https://diagnoise.bandcamp.com/album/nuclear-winter" rel="noopener nofollow" target="_blank">https://diagnoise.bandcamp.com/album/nuclear-winter</a></li> </ul> Las notas del programa de hoy las tenéis en <blockquote><a href="https://tecnocratica.net/motivos-para-cambiar-tu-centro-de-datos/" rel="nofollow" target="_blank">Motivos para cambiar tu centro de datos</a></blockquote> Foto de <a href="https://unsplash.com/@tvick?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="nofollow" target="_blank">Taylor Vick</a> en <a href="https://unsplash.com/es/fotos/M5tzZtFCOfs?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="nofollow" target="_blank">Unsplash</a>

Motivos para cambiar tu Centro de Datos

Si eres una de esas personas que utiliza Proxmox para virtualizar tu plataforma enhorabuena, estás usando una plataforma magnífica e insuperable en precio, puedes tenerla si quieres gratis, realmente no es necesario pagar nada, aunque si quieres los repositorios enterprise puedes pagar la suscripción de proxmox que va desde los 105 euros al año por socket. Pero hoy no quiero hablar de proxmox, sino de proxmox backup server, que es el servicio de backup de proxmox. La instalación es muy similar a la de proxmox VE, el hipervisor, y para entrar en vez de utilizar el puerto 8006 se utilizará el puerto 8007, lo cual, no se lo digáis a nadie, pero permite instalar el PBS en el mismo servidor que el Proxmox VE. Instalar ambos softwares en el mismo hipervisor está bien si lo que queremos es un laboratorio o si tenemos dos servidores y hacemos copias cruzadas. De todos modos, que se pueda no significa que sea buena idea. Recordad que no todo lo que se puede hacer es buena idea, se puede beber lejía, pero yo no lo haría. PBS tiene cuatro cosas muy graciosas que le hacen ser un software maravilloso:  La deduplicación en las copias de seguridad, es decir, el backup va a ocupar muy poquito espacio.En el caso de KVM que las copias son muy rápidas y ligeras. En LXC el backup no es tan eficiente, pues hace copia de la máquina completa. Retención y rotación de backups. Puedes tener las copias de seguridad y retenerlas con la antigüedad que quieras, por ejemplo backups cada hora, día, semana, mes, año. Una maravilla vamos. Por supuesto la integración con Proxmox VE es total y absoluta. PBS hace replicación entre PBS, con lo cual puedes tener siempre un backup externo en otro lado porque siempre va a estar sincronizado con tu PBS principal  PBS es un componente integral de la plataforma de virtualización Proxmox VE, y se integra perfectamente con el hipervisor Proxmox VE para proporcionar una solución de copia de seguridad completa. PBS ofrece una amplia gama de características, como la capacidad de realizar copias de seguridad de forma incremental, comprimir y cifrar los datos de respaldo, y programar copias de seguridad de manera automática. PBS utiliza la tecnología de copia de seguridad basada en Zstandard y deduplicación de datos, lo que permite reducir significativamente el tamaño de las copias de seguridad y, por lo tanto, el espacio de almacenamiento requerido. También es compatible con varios tipos de almacenamiento de respaldo, como discos duros, almacenamiento de red (NAS) y sistemas de almacenamiento en la nube.  Por si no lo conocéis Zstandard es un algoritmo de compresión muy rápido que se distribuye de forma gratuita con licencia BSD. Es un algoritmo desarrollado en Facebook, un lugar donde se hacen cosas muy interesantes. Y la deduplicación lo que hace es ir buscando trozos de 4KB y le asigna un hash a cada uno. Al final si se ve un bloque duplicado no se guarda y sólo se almacenan bloques únicos, por eso el ahorro de espacio es tan salvaje. La deduplicación no es sólo no guardar dos veces el mismo fichero, sino que va mucho más allá, es algo mucho más sesudo y complicado de implementar, pero PBS nos lo ofrece gratis.  PBS es una solución maravillosa, pero como os contaba en el audio anterior si tenemos el PBS en nuestras oficinas tenemos que tener en cuenta que sólo en electricidad nos va a costar unos 70 euros al mes, además de la amortización de hardware, control de discos, el que la sala no sea lo más adecuado, etc… Así que una opción estupenda es tener el PBS en un Centro de Datos externo o incluso si tenéis el Proxmox VE en un Centro de Datos tener las copias en otro Centro de Datos. La opción tradicional consiste en levantar un servidor nuevo en otro Centro de Datos, o bien usar un servicio de PBS remoto como el que ofrecemos nosotros en Tecnocrática, es cuestión de echar números y mirar qué es lo que más nos interesa. También se puede usar nuestro PBS para replicar el PBS que tengas Pensar que la cantidad de datos que necesitáis de PBS es muy baja gracias a la deduplicación, así que quizás os interese hacer los backups en un PBS externo como el nuestro. Nosotros en Tecnocrática, por cierto cobramos 50 euros al mes el Tera usado y neto en el PBS que es mucho menso de lo que realmente se hace backup por lo que os he contado antes. Además en ese servicio nosotros nos encargamos de todo y tú sólo tienes que preocuparte de que las copias de seguridad se lancen.

Si eres una de esas personas que utiliza Proxmox para virtualizar tu plataforma enhorabuena, estás usando una plataforma magnífica e insuperable en precio, puedes tenerla si quieres gratis, realmente no es necesario pagar nada, aunque si quieres los repositorios enterprise puedes pagar la suscripción de proxmox que va desde los 105 euros al año por socket. Pero hoy no quiero hablar de proxmox, sino de proxmox backup server, que es el servicio de backup de proxmox. La instalación es muy similar a la de proxmox VE, el hipervisor, y para entrar en vez de utilizar el puerto 8006 se utilizará el puerto 8007, lo cual, no se lo digáis a nadie, pero permite instalar el PBS en el mismo servidor que el Proxmox VE. Instalar ambos softwares en el mismo hipervisor está bien si lo que queremos es un laboratorio o si tenemos dos servidores y hacemos copias cruzadas. De todos modos, que se pueda no significa que sea buena idea. Recordad que no todo lo que se puede hacer es buena idea, se puede beber lejía, pero yo no lo haría. PBS tiene cuatro cosas muy graciosas que le hacen ser un software maravilloso: <ol> <li>La deduplicación en las copias de seguridad, es decir, el backup va a ocupar muy poquito espacio.En el caso de KVM que las copias son muy rápidas y ligeras. En LXC el backup no es tan eficiente, pues hace copia de la máquina completa.</li> <li>Retención y rotación de backups. Puedes tener las copias de seguridad y retenerlas con la antigüedad que quieras, por ejemplo backups cada hora, día, semana, mes, año. Una maravilla vamos.</li> <li>Por supuesto la integración con Proxmox VE es total y absoluta.</li> <li>PBS hace replicación entre PBS, con lo cual puedes tener siempre un backup externo en otro lado porque siempre va a estar sincronizado con tu PBS principal</li> </ol> PBS es un componente integral de la plataforma de virtualización Proxmox VE, y se integra perfectamente con el hipervisor Proxmox VE para proporcionar una solución de copia de seguridad completa. PBS ofrece una amplia gama de características, como la capacidad de realizar copias de seguridad de forma incremental, comprimir y cifrar los datos de respaldo, y programar copias de seguridad de manera automática. PBS utiliza la tecnología de copia de seguridad basada en <a href="https://facebook.github.io/zstd/" rel="noopener nofollow" target="_blank">Zstandard</a> y deduplicación de datos, lo que permite reducir significativamente el tamaño de las copias de seguridad y, por lo tanto, el espacio de almacenamiento requerido. También es compatible con varios tipos de almacenamiento de respaldo, como discos duros, almacenamiento de red (NAS) y sistemas de almacenamiento en la nube. <ul> <li>Por si no lo conocéis Zstandard es un algoritmo de compresión muy rápido que se distribuye de forma gratuita con licencia BSD. Es un algoritmo desarrollado en Facebook, un lugar donde se hacen cosas muy interesantes.</li> <li>Y la deduplicación lo que hace es ir buscando trozos de 4KB y le asigna un hash a cada uno. Al final si se ve un bloque duplicado no se guarda y sólo se almacenan bloques únicos, por eso el ahorro de espacio es tan salvaje. La deduplicación no es sólo no guardar dos veces el mismo fichero, sino que va mucho más allá, es algo mucho más sesudo y complicado de implementar, pero PBS nos lo ofrece gratis.</li> </ul> PBS es una solución maravillosa, pero como os contaba en el audio anterior si tenemos el PBS en nuestras oficinas tenemos que tener en cuenta que sólo en electricidad nos va a costar unos 70 euros al mes, además de la amortización de hardware, control de discos, el que la sala no sea lo más adecuado, etc… Así que una opción estupenda es tener el PBS en un Centro de Datos externo o incluso si tenéis el Proxmox VE en un Centro de Datos tener las copias en otro Centro de Datos. La opción tradicional consiste en levantar un servidor nuevo en otro Centro de Datos, o bien usar un servicio de PBS remoto como el que ofrecemos nosotros en Tecnocrática, es cuestión de echar números y mirar qué es lo que más nos interesa. También se puede usar nuestro PBS para replicar el PBS que tengas Pensar que la cantidad de datos que necesitáis de PBS es muy baja gracias a la deduplicación, así que quizás os interese hacer los backups en un PBS externo como el nuestro. Nosotros en Tecnocrática, por cierto cobramos 50 euros al mes el Tera usado y neto en el PBS que es mucho menso de lo que realmente se hace backup por lo que os he contado antes. Además en ese servicio nosotros nos encargamos de todo y tú sólo tienes que preocuparte de que las copias de seguridad se lancen.

Backup de Proxmox con PBS

Hoy un poco de BGP porque si alguna vez habéis tomado un café y os ha empezado a doler la cabeza a lo mejor es porque tenéis una confusión entre Atributos y Communities de BGP. Atributos: Piezas de información que utiliza BGP para tomar su decisión de routing. Communities: Agrupación de prefijos por algún motivo y que se utilizan para poder filtrar, anunciar o manipular. Si queréis profundizar recordad que hay otro capítulo sobre BGP que cuenta todo esto, y si queréis profundizar más, pues hay muchos más:  Secuestro de prefijos BGP o BGP hijacking BGP Anycast Tránsitos y filtros en BGP Gestión de filtros en BGP Montar dos routers frontera BGP Communities de BGP BGP con Mikrotik BGP Personal con Javi-h Qué es BGP FlowSpec

Hoy un poco de BGP porque si alguna vez habéis tomado un café y os ha empezado a doler la cabeza a lo mejor es porque tenéis una confusión entre Atributos y Communities de BGP. Atributos: Piezas de información que utiliza BGP para tomar su decisión de routing. Communities: Agrupación de prefijos por algún motivo y que se utilizan para poder filtrar, anunciar o manipular. Si queréis profundizar recordad que hay otro capítulo sobre <a href="https://www.eduardocollado.com/2017/10/08/podcast-53-bgp/" rel="nofollow" target="_blank">BGP</a> que cuenta todo esto, y si queréis profundizar más, pues hay muchos más: <ul> <li><a href="https://www.eduardocollado.com/2018/09/02/podcast-173-secuestro-de-prefijos-bgp-o-bgp-hijacking/" rel="nofollow" target="_blank">Secuestro de prefijos BGP o BGP hijacking</a></li> <li><a href="https://www.eduardocollado.com/2022/02/22/bgp-anycast/" rel="nofollow" target="_blank">BGP Anycast</a></li> <li><a href="https://www.eduardocollado.com/2022/10/03/transitos-y-filtros-en-bgp/" rel="nofollow" target="_blank">Tránsitos y filtros en BGP</a></li> <li><a href="https://www.eduardocollado.com/2022/11/30/gestion-de-filtros-en-bgp/" rel="nofollow" target="_blank">Gestión de filtros en BGP</a></li> <li><a href="https://www.eduardocollado.com/2017/06/18/podcast-35-montar-dos-routers-frontera-bgp/" rel="nofollow" target="_blank">Montar dos routers frontera BGP</a></li> <li><a href="https://www.eduardocollado.com/2018/01/24/podcast-100-communities-de-bgp/" rel="nofollow" target="_blank">Communities de BGP</a></li> <li><a href="https://www.eduardocollado.com/2021/05/19/bgp-con-mikrotik/" rel="nofollow" target="_blank">BGP con Mikrotik</a></li> <li><a href="https://www.eduardocollado.com/2021/10/17/bgp-personal-con-javi-h/" rel="nofollow" target="_blank">BGP Personal con Javi-h</a></li> <li><a href="https://www.eduardocollado.com/2021/09/02/que-es-bgp-flowspec/" rel="nofollow" target="_blank">Qué es BGP FlowSpec</a></li></ul>

BGP, Atributos y Communities

Un punto neutro de internet es un lugar físico donde se conectan diferentes redes de proveedores de servicios de internet (ISP) para intercambiar tráfico de datos de manera eficiente y equitativa. En términos simples, un punto neutro es una especie de intersección de autopistas de internet, donde los diferentes proveedores de servicios de internet pueden intercambiar tráfico de datos entre sí. El punto neutro de Internet es un componente esencial de la arquitectura de Internet que permite el intercambio de tráfico entre los distintos proveedores de servicios de Internet (ISP, por sus siglas en inglés) de manera eficiente y equitativa. Es un lugar físico en el que los proveedores de servicios de Internet interconectan sus redes para intercambiar tráfico de Internet y proporcionar conectividad a sus clientes. En este texto, explicaremos en detalle qué es un punto neutro de Internet y cómo funciona. Los puntos neutros de internet son cruciales para el funcionamiento de internet, ya que permiten a los diferentes ISP interconectar sus redes y ofrecer a sus clientes acceso a todo el contenido de internet. Sin los puntos neutros, los ISP tendrían que conectarse directamente entre sí para intercambiar tráfico de datos, lo que sería muy costoso y poco eficiente. Los puntos neutros de internet no son propiedad de ningún ISP, empresa u organización en particular. En cambio, son operados por entidades sin fines de lucro, conocidas como «intercambios de Internet», que proporcionan el espacio físico y la infraestructura necesarios para que los ISP intercambien tráfico de datos de manera neutral y equitativa. El funcionamiento de un punto neutro de internet se basa en el principio de la neutralidad de la red, que establece que todo el tráfico de internet debe ser tratado de manera equitativa, independientemente de su origen, destino o contenido. En un punto neutro, todos los ISP son iguales y no hay preferencia por parte del intercambio de Internet hacia ningún ISP en particular. Cuando un ISP se conecta a un punto neutro de internet, puede intercambiar tráfico de datos con otros ISP que también estén conectados al punto neutro. El intercambio de datos se realiza a través de una serie de conexiones de red de alta velocidad, conocidas como «enlaces de peering», que conectan los routers de los diferentes ISP en el punto neutro. Los enlaces de peering son bidireccionales, lo que significa que el tráfico puede fluir en ambas direcciones. Cuando un cliente de un ISP solicita acceso a un sitio web alojado en otro ISP, la solicitud se envía a través de la red del ISP del cliente hasta el punto neutro de internet, donde se enruta al ISP que aloja el sitio web. El ISP que aloja el sitio web luego envía la respuesta de vuelta a través del enlace de peering al ISP del cliente. El tráfico que fluye a través de un punto neutro de internet puede ser de diferentes tipos y tamaños. Puede ser tráfico web, correo electrónico, mensajería instantánea, video en línea, juegos en línea, transferencias de archivos, etc. El punto neutro no tiene control sobre el contenido del tráfico, solo se encarga de enrutarlo de manera eficiente y equitativa. Los puntos neutros de internet son especialmente importantes para el tráfico de datos de alta velocidad y gran volumen, como el streaming de video en línea y los juegos en línea. Cuando se utiliza un punto neutro de internet, el tráfico de datos no tiene que pasar por múltiples redes intermedias, lo que puede ralentizar la velocidad de conexión y aumentar la latencia. En cambio, el tráfico se enruta directamente entre los ISP conectados al punto neutro, lo que mejora enormemente las posibilidades existentes.

Un punto neutro de internet es un lugar físico donde se conectan diferentes redes de proveedores de servicios de internet (ISP) para intercambiar tráfico de datos de manera eficiente y equitativa. En términos simples, un punto neutro es una especie de intersección de autopistas de internet, donde los diferentes proveedores de servicios de internet pueden intercambiar tráfico de datos entre sí. El punto neutro de Internet es un componente esencial de la arquitectura de Internet que permite el intercambio de tráfico entre los distintos proveedores de servicios de Internet (ISP, por sus siglas en inglés) de manera eficiente y equitativa. Es un lugar físico en el que los proveedores de servicios de Internet interconectan sus redes para intercambiar tráfico de Internet y proporcionar conectividad a sus clientes. En este texto, explicaremos en detalle qué es un punto neutro de Internet y cómo funciona. Los puntos neutros de internet son cruciales para el funcionamiento de internet, ya que permiten a los diferentes ISP interconectar sus redes y ofrecer a sus clientes acceso a todo el contenido de internet. Sin los puntos neutros, los ISP tendrían que conectarse directamente entre sí para intercambiar tráfico de datos, lo que sería muy costoso y poco eficiente. Los puntos neutros de internet no son propiedad de ningún ISP, empresa u organización en particular. En cambio, son operados por entidades sin fines de lucro, conocidas como «intercambios de Internet», que proporcionan el espacio físico y la infraestructura necesarios para que los ISP intercambien tráfico de datos de manera neutral y equitativa. El funcionamiento de un punto neutro de internet se basa en el principio de la neutralidad de la red, que establece que todo el tráfico de internet debe ser tratado de manera equitativa, independientemente de su origen, destino o contenido. En un punto neutro, todos los ISP son iguales y no hay preferencia por parte del intercambio de Internet hacia ningún ISP en particular. Cuando un ISP se conecta a un punto neutro de internet, puede intercambiar tráfico de datos con otros ISP que también estén conectados al punto neutro. El intercambio de datos se realiza a través de una serie de conexiones de red de alta velocidad, conocidas como «enlaces de peering», que conectan los routers de los diferentes ISP en el punto neutro. Los enlaces de peering son bidireccionales, lo que significa que el tráfico puede fluir en ambas direcciones. Cuando un cliente de un ISP solicita acceso a un sitio web alojado en otro ISP, la solicitud se envía a través de la red del ISP del cliente hasta el punto neutro de internet, donde se enruta al ISP que aloja el sitio web. El ISP que aloja el sitio web luego envía la respuesta de vuelta a través del enlace de peering al ISP del cliente. El tráfico que fluye a través de un punto neutro de internet puede ser de diferentes tipos y tamaños. Puede ser tráfico web, correo electrónico, mensajería instantánea, video en línea, juegos en línea, transferencias de archivos, etc. El punto neutro no tiene control sobre el contenido del tráfico, solo se encarga de enrutarlo de manera eficiente y equitativa. Los puntos neutros de internet son especialmente importantes para el tráfico de datos de alta velocidad y gran volumen, como el streaming de video en línea y los juegos en línea. Cuando se utiliza un punto neutro de internet, el tráfico de datos no tiene que pasar por múltiples redes intermedias, lo que puede ralentizar la velocidad de conexión y aumentar la latencia. En cambio, el tráfico se enruta directamente entre los ISP conectados al punto neutro, lo que mejora enormemente las posibilidades existentes.

Qué es un punto neutro

A día de hoy levantar una VPN está chupado, levantar un wireguard es una tarea sencilla que podemos hacer en un momento. Si tenemos que acceder a una red remota podemos hacerlo con un wireguard, claro que sí, sin problema, pero muchas veces necesitamos una solución rápida y directa, algo más rápido que levantar una VPN, o incluso puede que levantar una VPN sea un poco complicado porque se pisen direccionamientos o cualuier otro motivo. Para acceder a servicios remotos a veces lo más fácil es levantar un túnel SSH desde tu propio equipo y a funcionar. La forma más común de levantar un túnel SSH quizás seá con e en Windows, porque sí, los usuarios de Windows también hacen cosas interesantes. Los túneles SSH los podemos hacer de dos formas:  De nuestra máquina hacia afuera (ssh -L) Del destino a nuestra máquina (ssh -R)  Elegiremos el túnel SSH normal o el túnel SSH inverso dependiendo de cómo tengamos la conexión. Por ejemplo si nosotros queremos ver en un puerto de localhost algo que está en una máquina a la que se llega por nuestra máquina de salto será un SSH normal. Si nosotros queremos abrir un puerto a una conexión externa entonces usaremos un SSH inverso. Donde se ve -&gt; nosotros -&gt; Destino nosotros -&gt; máquina de salto -&gt; destino ¿Cuando se usa esto? Cuando tienes acceso a una red mediante una única máquina de salto por ssh, cuando quieres abrir una aplicación interna a una máquina externa sin exponerla a internet. La última vez que lo he usado ha sido por ejemplo hoy que he tenido que acceder a un entorno web de unos equipos de red tunelizando la web a través de una conexión ssh. A mi me pasa muchas veces que tengo que acceder a una máquina a la que no tengo acceso directo, por ejemplo una máquina de salto ssh -L 7001:10.10.10.10:80 user@pub001.host ssh -R 8081:10.10.10.10:80 user@mipc Actualizaciones y mejoras del artículo (se agradece muchísimo :D): Por Dathpatatas: Vengo a “quejarme” del podcast  he echado en falta los otros 2 tuneles ssh Proxy socks directo similar al -L, pero creando un proxy socks en local que sale por la maquina a la que nos conectamos, super util ssh user@host -D 8000 Proxy socks reverso muy util para dar internet a la maquina remota a traves de un proxy socks remoto que sale por la maquina que ejecuta el comando ssh user@host -R 8000 Para el -L iplocal:puertolocal:ipremota:puertoremoto Si no pones iplocal por defecto es 127.0.0.1 La ipremota puede ser 127.0.0.1 (un puerto local de la maquina remota) o cualquier ip

A día de hoy levantar una VPN está chupado, levantar un wireguard es una tarea sencilla que podemos hacer en un momento. Si tenemos que acceder a una red remota podemos hacerlo con un wireguard, claro que sí, sin problema, pero muchas veces necesitamos una solución rápida y directa, algo más rápido que levantar una VPN, o incluso puede que levantar una VPN sea un poco complicado porque se pisen direccionamientos o cualuier otro motivo. Para acceder a servicios remotos a veces lo más fácil es levantar un túnel SSH desde tu propio equipo y a funcionar. La forma más común de levantar un túnel SSH quizás seá con e en Windows, porque sí, los usuarios de Windows también hacen cosas interesantes. Los túneles SSH los podemos hacer de dos formas: <ol> <li>De nuestra máquina hacia afuera (ssh -L)</li> <li>Del destino a nuestra máquina (ssh -R)</li> </ol> Elegiremos el túnel SSH normal o el túnel SSH inverso dependiendo de cómo tengamos la conexión. Por ejemplo si nosotros queremos ver en un puerto de localhost algo que está en una máquina a la que se llega por nuestra máquina de salto será un SSH normal. Si nosotros queremos abrir un puerto a una conexión externa entonces usaremos un SSH inverso. Donde se ve -&gt; nosotros -&gt; Destino nosotros -&gt; máquina de salto -&gt; destino ¿Cuando se usa esto? Cuando tienes acceso a una red mediante una única máquina de salto por ssh, cuando quieres abrir una aplicación interna a una máquina externa sin exponerla a internet. La última vez que lo he usado ha sido por ejemplo hoy que he tenido que acceder a un entorno web de unos equipos de red tunelizando la web a través de una conexión ssh. A mi me pasa muchas veces que tengo que acceder a una máquina a la que no tengo acceso directo, por ejemplo una máquina de salto ssh -L 7001:10.10.10.10:80 user@pub001.host ssh -R 8081:10.10.10.10:80 user@mipc Actualizaciones y mejoras del artículo (se agradece muchísimo :D): Por Dathpatatas: <blockquote>Vengo a “quejarme” del podcast he echado en falta los otros 2 tuneles ssh Proxy socks directo similar al -L, pero creando un proxy socks en local que sale por la maquina a la que nos conectamos, super util ssh user@host -D 8000 Proxy socks reverso muy util para dar internet a la maquina remota a traves de un proxy socks remoto que sale por la maquina que ejecuta el comando ssh user@host -R 8000 Para el -L iplocal:puertolocal:ipremota:puertoremoto Si no pones iplocal por defecto es 127.0.0.1 La ipremota puede ser 127.0.0.1 (un puerto local de la maquina remota) o cualquier ip</blockquote>

Túneles SSH

Hoy vamos a hablar de Multiple Spanning Tree Protocol (802.1s) o también conocido como MST. En el mundo Cisco la mayoría de las empresas levantan VLANs, esas VLANs tienen asociada una instancia de Spanning Tree y hay mucha gente que no se pregunta mucho más sobre eso, simplemente si quieres ver los puertos bloqueados puesshow spanning tree vlan 55Y poco más, como mucho se define el root de alguna instancia de spanning tree para que el root de la instancia de la vlan 55 esté en un switch determinado y poco más. El protocolo que se utiliza por defecto en Cisco para el Spanning Tree es PVST+ y es el protocolo ideal para la gran mayoría de las redes empresariales, pero tiene un límite, el límite es que PVST+ sólo permite 128 instancias, que son muchas, pero claro, hay gente que necesita más de 128 VLANs en su red, en ese caso, la 129 no correrá spanning tree. Al configurar la vlan 129ª saldrá un mensaje diciendo que se ha quedado sin instancias de PVST y que esa vlan nueva no va a tener spanning tree y claro, la primera vez que ves ese mensaje se entra en crisis, ¿cómo que no voy a tener spanning tree en las vlans nuevas. Este es un tema que no he tratado anteriormente porque no creía que fuera una necesidad pero sin ir más lejos el otro día estaba mirando una red y saltó esta necesidad, en esa red había necesidad de bastantes más vlans que 128 y claro, por defecto hay PVST+ y no nos sirve para el Spanning Tree de esta red. Como opciones tendríamos CST o MST y claro, CST no vamos ni a considerarla. La elección del tipo de Spanning Tree depende de dos factores:  Ubicación del root Utilización de los enlaces  Ubicación del root Si tenemos una vlan de almacenamiento donde siempre va a ser necesario que todo el tráfico llegue a una cabina está claro que el root del STP tendría que estar en la cabina porque queremos que todos los enlaces de ese switch estén disponibles y no cortados. Utilización de los enlaces Con Spanning Tree podemos hacer que unas instancias vayan por un enlace y otras por otro, de forma que, si tenemos dos enlaces, tengamos utilizados ambos enlaces, obviamente la suma no debería ser mayor al ancho de banda de uno de los enlaces, teniendo en cuenta que son iguales. El objetivo de este capítulo no es explicar como funciona spanning tree, de eso ya hablé en Enero de 2018 en este mismo podcast en el capítulo Spanning Tree, el objetivo es que sepáis qué hacer cuando os quedéis sin instancias disponibles en PVST+. MST La solución será MST, que sólo nos ofrece 64 instancias, pero con la gracia de que podemos agregar vlans a una instancia, dividiendo de forma idéntica podríamos tener, por ejemplo, 64 instancias con 64 vlans cada instancia. Seguro que muchas vlans comparten la misma estructura, son vlans en las que tenemos servidores o PCs que tienen que comunicarse con un router, pues en este caso el root lo ponemos en el switch donde esté el router y todas esas vlans en una misma instancia, así que compartirán topología de nivel 2. Por desgracia nadie empieza una red utilizando MST, sino utilizando PVST+, por comodidad o por no pensar en el futuro Yo mismo nunca he iniciado una red desde 0 con MST, y siempre me arrepiento muchísimo, porque el cambio a MST es inevitable ya que el llegar a 128 instancias es sólo cuestión de tiempo. ¿Cómo levantaríamos el MST desde el principio?switch# conf t Enter configuration commands, one per line. End with CNTL/Z. switch(config)# spanning-tree mode mst switch(config)# spanning-tree mst configuration switch(config-mst)# instance 1 vlan 1 switch(config-mst)# instance 2 vlan 2-5 switch(config-mst)# instance 3 vlan 6,7,8 switch(config-mst)# exit switch(config)# spanning-tree mst 0-3 root primaryComo se ve la configuración es muy sencilla y se entiende perfectamente spanning tree tradicional, si asignáramos una vlan a una instancia al final tendríamos el mismo comportamiento que PVST+. Migración de PVST+ a MST En un Mundo ideal podríamos convertir la configuración de todos los switches a la vez y ya estaría, pero ya sabéis que eso no va a suceder nunca, así que vamos a tener que ir paso a paso para hacer la conversión en la red.  Identificar los puertos de acceso de la red y configurarlos como spanning-tree portfast, como spanning-tree port type edge o como sea en el switch donde estemos. Asignar vlans a instancias de MST y decidir donde va a  estar el root primario y el secundario para cada instancia. Ojo, la instancia 0 no hay que usarla. Aprovechando que MST puede interactuar con PVST+ a nivel de puerto se pueden mantener ambas topologías a la vez. Ojo aquí porque hay que asegurarse que los trunks lleven todas las vlans. Asegurarse que los switches PVST+ tienen menor root bridge (numeración superior) que el CST, el root del MST instancia 0. Y lo más importante, no es que puedas tener un corte en la red, es que seguro que lo vas a tener, así que no hagas esto en hora de máximo tráfico.  Una vez que se haya terminado hay que hacer dos cosas, tunear el MST con el port-priorityswitch(config-if)#spanning-tree mst 2 port-priority 64Y limpiando la configuración que quede de PVST+switch(config)#no spanning-tree backbonefastswitch(config)#no spanning-tree backbonefastswitch(config)#interface FastEthernet1/0/24switch(config-if)#no spanning-tree vlan 20,40,200 port-priority 64Una vez limpia la configuración procederemos a configurar MST en el siguiente y así iremos bajando niveles.

Hoy vamos a hablar de Multiple Spanning Tree Protocol (802.1s) o también conocido como MST. En el mundo Cisco la mayoría de las empresas levantan VLANs, esas VLANs tienen asociada una instancia de Spanning Tree y hay mucha gente que no se pregunta mucho más sobre eso, simplemente si quieres ver los puertos bloqueados puesshow spanning tree vlan 55 Y poco más, como mucho se define el root de alguna instancia de spanning tree para que el root de la instancia de la vlan 55 esté en un switch determinado y poco más. El protocolo que se utiliza por defecto en Cisco para el Spanning Tree es PVST+ y es el protocolo ideal para la gran mayoría de las redes empresariales, pero tiene un límite, el límite es que PVST+ sólo permite 128 instancias, que son muchas, pero claro, hay gente que necesita más de 128 VLANs en su red, en ese caso, la 129 no correrá spanning tree. Al configurar la vlan 129ª saldrá un mensaje diciendo que se ha quedado sin instancias de PVST y que esa vlan nueva no va a tener spanning tree y claro, la primera vez que ves ese mensaje se entra en crisis, ¿cómo que no voy a tener spanning tree en las vlans nuevas. Este es un tema que no he tratado anteriormente porque no creía que fuera una necesidad pero sin ir más lejos el otro día estaba mirando una red y saltó esta necesidad, en esa red había necesidad de bastantes más vlans que 128 y claro, por defecto hay PVST+ y no nos sirve para el Spanning Tree de esta red. Como opciones tendríamos CST o MST y claro, CST no vamos ni a considerarla. La elección del tipo de Spanning Tree depende de dos factores: <ul> <li>Ubicación del root</li> <li>Utilización de los enlaces</li> </ul> Ubicación del root Si tenemos una vlan de almacenamiento donde siempre va a ser necesario que todo el tráfico llegue a una cabina está claro que el root del STP tendría que estar en la cabina porque queremos que todos los enlaces de ese switch estén disponibles y no cortados. Utilización de los enlaces Con Spanning Tree podemos hacer que unas instancias vayan por un enlace y otras por otro, de forma que, si tenemos dos enlaces, tengamos utilizados ambos enlaces, obviamente la suma no debería ser mayor al ancho de banda de uno de los enlaces, teniendo en cuenta que son iguales. El objetivo de este capítulo no es explicar como funciona spanning tree, de eso ya hablé en Enero de 2018 en este mismo podcast en el capítulo <a href="https://www.eduardocollado.com/2018/01/22/podcast-98-spanning-tree/" rel="noopener nofollow" target="_blank">Spanning Tree</a>, el objetivo es que sepáis qué hacer cuando os quedéis sin instancias disponibles en PVST+. MST La solución será MST, que sólo nos ofrece 64 instancias, pero con la gracia de que podemos agregar vlans a una instancia, dividiendo de forma idéntica podríamos tener, por ejemplo, 64 instancias con 64 vlans cada instancia. Seguro que muchas vlans comparten la misma estructura, son vlans en las que tenemos servidores o PCs que tienen que comunicarse con un router, pues en este caso el root lo ponemos en el switch donde esté el router y todas esas vlans en una misma instancia, así que compartirán topología de nivel 2. Por desgracia nadie empieza una red utilizando MST, sino utilizando PVST+, por comodidad o por no pensar en el futuro Yo mismo nunca he iniciado una red desde 0 con MST, y siempre me arrepiento muchísimo, porque el cambio a MST es inevitable ya que el llegar a 128 instancias es sólo cuestión de tiempo. ¿Cómo levantaríamos el MST desde el principio?switch# conf t Enter configuration commands, one per line. End with CNTL/Z. switch(config)# spanning-tree mode mst switch(config)# spanning-tree mst configuration switch(config-mst)# instance 1 vlan 1 switch(config-mst)# instance 2 vlan 2-5 switch(config-mst)# instance 3 vlan 6,7,8 switch(config-mst)# exit switch(config)# spanning-tree mst 0-3 root primary Como se ve la configuración es muy sencilla y se entiende perfectamente spanning tree tradicional, si asignáramos una vlan a una instancia al final tendríamos el mismo comportamiento que PVST+. Migración de PVST+ a MST En un Mundo ideal podríamos convertir la configuración de todos los switches a la vez y ya estaría, pero ya sabéis que eso no va a suceder nunca, así que vamos a tener que ir paso a paso para hacer la conversión en la red. <ol> <li>Identificar los puertos de acceso de la red y configurarlos como spanning-tree portfast, como spanning-tree port type edge o como sea en el switch donde estemos.</li> <li>Asignar vlans a instancias de MST y decidir donde va a  estar el root primario y el secundario para cada instancia. Ojo, la instancia 0 no hay que usarla.</li> <li>Aprovechando que MST puede interactuar con PVST+ a nivel de puerto se pueden mantener ambas topologías a la vez. Ojo aquí porque hay que asegurarse que los trunks lleven todas las vlans.</li> <li>Asegurarse que los switches PVST+ tienen menor root bridge (numeración superior) que el CST, el root del MST instancia 0.</li> <li>Y lo más importante, no es que puedas tener un corte en la red, es que seguro que lo vas a tener, así que no hagas esto en hora de máximo tráfico.</li> </ol> Una vez que se haya terminado hay que hacer dos cosas, tunear el MST con el port-priorityswitch(config-if)#spanning-tree mst 2 port-priority 64 Y limpiando la configuración que quede de PVST+switch(config)#no spanning-tree backbonefast switch(config)#no spanning-tree backbonefast switch(config)#interface FastEthernet1/0/24 switch(config-if)#no spanning-tree vlan 20,40,200 port-priority 64 Una vez limpia la configuración procederemos a configurar MST en el siguiente y así iremos bajando niveles.

Multiple Spanning Tree Protocol – MST

Hoy por la tarde ha pasado lo típico, nos hemos juntado 5 amigos a charlar, a charlar sobre como afecta el pensar en IPv4 cuando tienes que poner en funcionamiento IPv6, lo típico de cualquier charla entre amigos. Nos hemos juntado Adrián Almenar, DMNTR, Carlos Fraga, Andreu Adrover y un servidor alrededor de una sala de Zencastr y hemos grabado algo más de una hora de charla informal sobre el tema de moda en estos momentos ;-), el IPv6. Espero que os guste.

Hoy por la tarde ha pasado lo típico, nos hemos juntado 5 amigos a charlar, a charlar sobre como afecta el pensar en IPv4 cuando tienes que poner en funcionamiento IPv6, lo típico de cualquier charla entre amigos. Nos hemos juntado <a href="https://adrian.almenar.com/" rel="noopener nofollow" target="_blank">Adrián Almenar</a>, <a href="https://www.zree.es/" rel="noopener nofollow" target="_blank">DMNTR</a>, Carlos Fraga, <a href="https://securizando.com/" rel="noopener nofollow" target="_blank">Andreu Adrover</a> y un servidor alrededor de una sala de Zencastr y hemos grabado algo más de una hora de charla informal sobre el tema de moda en estos momentos ;-), el IPv6. Espero que os guste.

Pensar en IPv4 cuando deberíamos de hacerlo en IPv6

Hoy os traemos Adrián y yo una conversación sobre la gestión de filtros en BGP. A veces cuando contratáis un tránsito os piden que les digáis los rangos que se van a anunciar, pues mal, eso no es lo más adecuado desde que tenemos los objetos de RIPE AS y AS-SET. En el capítulo de hoy os contamos la diferencia entre access-list, prefix-list y route-map. También os hablamos de bgpq4 que podéis descargar desde https://github.com/bgp/bgpq4. Otra cosa que os comentamos es la direfencia entre AS y AS-SET y luego hablamos de RPKI y cómo automatizar los filtros. Ejemplos: Lista de prefijos: bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 AS-TECNOCRATICA bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -6 AS-TECNOCRATICA Lista de prefijos de sólo un AS: bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 as15954 bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -6 as15954 Configuración Cisco: bgpq4 -Al tecnocratica AS-TECNOCRATICA bgpq4 -Al tecnocratica -6 AS-TECNOCRATICA El ejemplo de un comando de cada sería: $ bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 AS-TECNOCRATICA 2.56.165.0/24 5.56.160.0/21 5.181.44.0/22 23.139.41.0/24 23.188.240.0/24 31.24.120.0/21 31.47.72.0/21 31.170.100.0/22 37.247.120.0/21 38.103.194.0/24 38.143.153.0/24 44.9.16.0/21 44.31.43.0/24 44.31.80.0/24 44.31.92.0/22 44.31.182.0/24 44.161.204.0/23 44.161.219.0/24 44.161.220.0/22 44.161.230.0/24 44.161.237.0/24 […] edu@andromeda:~$ bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 as15954 31.24.120.0/21 31.47.72.0/21 37.247.120.0/21 91.199.120.0/24 91.216.219.0/24 185.49.184.0/22 185.57.196.0/22 185.66.73.0/24 185.66.74.0/24 185.203.224.0/22 194.176.119.0/24 217.18.32.0/20 edu@andromeda:~$ bgpq4 -Al tecnocratica AS-TECNOCRATICA no ip prefix-list tecnocratica ip prefix-list tecnocratica permit 2.56.165.0/24 ip prefix-list tecnocratica permit 5.56.160.0/21 le 22 ip prefix-list tecnocratica permit 5.181.44.0/22 ip prefix-list tecnocratica permit 8.23.229.0/24 ip prefix-list tecnocratica permit 23.132.185.0/24 ip prefix-list tecnocratica permit 23.136.232.0/24 ip prefix-list tecnocratica permit 23.138.216.0/24 ip prefix-list tecnocratica permit 23.139.41.0/24 ip prefix-list tecnocratica permit 23.140.248.0/23 ge 24 le 24 ip prefix-list tecnocratica permit 23.141.88.0/24 ip prefix-list tecnocratica permit 23.188.240.0/24 ip prefix-list tecnocratica permit 31.24.120.0/21 ip prefix-list tecnocratica permit 31.47.72.0/21 ip prefix-list tecnocratica permit 31.170.100.0/22 ip prefix-list tecnocratica permit 37.247.120.0/21 ip prefix-list tecnocratica permit 38.103.194.0/24 ip prefix-list tecnocratica permit 38.134.111.0/24 ip prefix-list tecnocratica permit 38.143.153.0/24 ip prefix-list tecnocratica permit 41.216.177.0/24 ip prefix-list tecnocratica permit 41.216.178.0/24 ip prefix-list tecnocratica permit 41.216.186.0/24 ip prefix-list tecnocratica permit 44.9.16.0/21 ip prefix-list tecnocratica permit 44.31.43.0/24 ip prefix-list tecnocratica permit 44.31.80.0/24 ip prefix-list tecnocratica permit 44.31.92.0/22 ip prefix-list tecnocratica permit 44.31.182.0/24 ip prefix-list tecnocratica permit 44.159.68.0/24 ip prefix-list tecnocratica permit 44.161.204.0/23 ip prefix-list tecnocratica permit 44.161.219.0/24 ip prefix-list tecnocratica permit 44.161.220.0/22 ip prefix-list tecnocratica permit 44.161.230.0/24 ip prefix-list tecnocratica permit 44.161.237.0/24 ip prefix-list tecnocratica permit 44.161.238.0/23 ip prefix-list tecnocratica permit 44.161.240.0/21 ip prefix-list tecnocratica permit 44.161.248.0/22 ip prefix-list tecnocratica permit 45.13.185.0/24 ip prefix-list tecnocratica permit 45.61.161.0/24 ip prefix-list tecnocratica permit 45.61.162.0/24 ip prefix-list tecnocratica permit 45.81.152.0/22 ip prefix-list tecnocratica permit 45.89.255.0/24 ip prefix-list tecnocratica permit 45.90.16.0/22 ip prefix-list tecnocratica permit 45.90.145.0/24 ip prefix-list tecnocratica permit 45.95.113.0/24 ip prefix-list tecnocratica permit 45.130.16.0/22 ip prefix-list tecnocratica permit 45.131.132.0/22 ip prefix-list tecnocratica permit 45.137.160.0/22 […] Y en IPv6 pondríamos simplemente -6, esto lo podéis hacer en cualquier ordenador que tenga bgpq4 instalado.

Hoy os traemos Adrián y yo una conversación sobre la gestión de filtros en BGP. A veces cuando contratáis un tránsito os piden que les digáis los rangos que se van a anunciar, pues mal, eso no es lo más adecuado desde que tenemos los objetos de RIPE AS y AS-SET. En el capítulo de hoy os contamos la diferencia entre access-list, prefix-list y route-map. También os hablamos de bgpq4 que podéis descargar desde <a href="https://github.com/bgp/bgpq4" rel="noopener nofollow" target="_blank">https://github.com/bgp/bgpq4</a>. Otra cosa que os comentamos es la direfencia entre AS y AS-SET y luego hablamos de RPKI y cómo automatizar los filtros. Ejemplos: Lista de prefijos: <blockquote>bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 AS-TECNOCRATICA bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -6 AS-TECNOCRATICA</blockquote> Lista de prefijos de sólo un AS: <blockquote>bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 as15954 bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -6 as15954</blockquote> Configuración Cisco: <blockquote>bgpq4 -Al tecnocratica AS-TECNOCRATICA bgpq4 -Al tecnocratica -6 AS-TECNOCRATICA</blockquote> El ejemplo de un comando de cada sería: <blockquote>$ bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 AS-TECNOCRATICA 2.56.165.0/24 5.56.160.0/21 5.181.44.0/22 23.139.41.0/24 23.188.240.0/24 31.24.120.0/21 31.47.72.0/21 31.170.100.0/22 37.247.120.0/21 38.103.194.0/24 38.143.153.0/24 44.9.16.0/21 44.31.43.0/24 44.31.80.0/24 44.31.92.0/22 44.31.182.0/24 44.161.204.0/23 44.161.219.0/24 44.161.220.0/22 44.161.230.0/24 44.161.237.0/24 […]</blockquote> <blockquote>edu@andromeda:~$ bgpq4 -A -SRADB,RIPE -F ‘%n/%l\n’ -4 as15954 31.24.120.0/21 31.47.72.0/21 37.247.120.0/21 91.199.120.0/24 91.216.219.0/24 185.49.184.0/22 185.57.196.0/22 185.66.73.0/24 185.66.74.0/24 185.203.224.0/22 194.176.119.0/24 217.18.32.0/20</blockquote> <blockquote>edu@andromeda:~$ bgpq4 -Al tecnocratica AS-TECNOCRATICA no ip prefix-list tecnocratica ip prefix-list tecnocratica permit 2.56.165.0/24 ip prefix-list tecnocratica permit 5.56.160.0/21 le 22 ip prefix-list tecnocratica permit 5.181.44.0/22 ip prefix-list tecnocratica permit 8.23.229.0/24 ip prefix-list tecnocratica permit 23.132.185.0/24 ip prefix-list tecnocratica permit 23.136.232.0/24 ip prefix-list tecnocratica permit 23.138.216.0/24 ip prefix-list tecnocratica permit 23.139.41.0/24 ip prefix-list tecnocratica permit 23.140.248.0/23 ge 24 le 24 ip prefix-list tecnocratica permit 23.141.88.0/24 ip prefix-list tecnocratica permit 23.188.240.0/24 ip prefix-list tecnocratica permit 31.24.120.0/21 ip prefix-list tecnocratica permit 31.47.72.0/21 ip prefix-list tecnocratica permit 31.170.100.0/22 ip prefix-list tecnocratica permit 37.247.120.0/21 ip prefix-list tecnocratica permit 38.103.194.0/24 ip prefix-list tecnocratica permit 38.134.111.0/24 ip prefix-list tecnocratica permit 38.143.153.0/24 ip prefix-list tecnocratica permit 41.216.177.0/24 ip prefix-list tecnocratica permit 41.216.178.0/24 ip prefix-list tecnocratica permit 41.216.186.0/24 ip prefix-list tecnocratica permit 44.9.16.0/21 ip prefix-list tecnocratica permit 44.31.43.0/24 ip prefix-list tecnocratica permit 44.31.80.0/24 ip prefix-list tecnocratica permit 44.31.92.0/22 ip prefix-list tecnocratica permit 44.31.182.0/24 ip prefix-list tecnocratica permit 44.159.68.0/24 ip prefix-list tecnocratica permit 44.161.204.0/23 ip prefix-list tecnocratica permit 44.161.219.0/24 ip prefix-list tecnocratica permit 44.161.220.0/22 ip prefix-list tecnocratica permit 44.161.230.0/24 ip prefix-list tecnocratica permit 44.161.237.0/24 ip prefix-list tecnocratica permit 44.161.238.0/23 ip prefix-list tecnocratica permit 44.161.240.0/21 ip prefix-list tecnocratica permit 44.161.248.0/22 ip prefix-list tecnocratica permit 45.13.185.0/24 ip prefix-list tecnocratica permit 45.61.161.0/24 ip prefix-list tecnocratica permit 45.61.162.0/24 ip prefix-list tecnocratica permit 45.81.152.0/22 ip prefix-list tecnocratica permit 45.89.255.0/24 ip prefix-list tecnocratica permit 45.90.16.0/22 ip prefix-list tecnocratica permit 45.90.145.0/24 ip prefix-list tecnocratica permit 45.95.113.0/24 ip prefix-list tecnocratica permit 45.130.16.0/22 ip prefix-list tecnocratica permit 45.131.132.0/22 ip prefix-list tecnocratica permit 45.137.160.0/22 […]</blockquote> Y en IPv6 pondríamos simplemente -6, esto lo podéis hacer en cualquier ordenador que tenga bgpq4 instalado.

Gestión de filtros en BGP

Eres una empresa que has ido creciendo y necesitas contratar un rack en un centro de datos para poder ahí los servidores de tu empresa y dar servicio. ¿Qué posibilidades tienes para darle conectividad a ese rack? porque es obvio que vas a necesitar algún tipo de conectividad, si contratas un rack, unas Us o incluso una sala vas a querer conectarte a ella de alguna manera. Este tema quería tratarlo en un hilo de Twitter, pero claro, según iba pensando se me disparaban las posibilidades, así que este capítulo de hoy es un hilo de Twitter que bien ha merecido su propio audio en el podcast. De hecho el hilo en cuestión se me escapó a medio escribir y me lo tuve que cargar. Lo primero es decidir si la conectividad va a ser pública o no, porque no todos los racks están conectados al Internet público, algunos racks son simplemente cabinas de replicación, es decir, la replicación de una cabina que está en la oficina del cliente, para evitar desastres y cosas así. En este caso es posible que sólo queramos que la cabina sea accesible únicamente desde la oficina principal donde está la otra cabina, en este caso lo normal es contratar capacidad portadora, es decir, una conexión de 1 o 10G a un operador y que sea la únión del CPD con la oficina de la empresa. Si los requisitos son mayores siempre se puede poner una fibra oscura e iluminarla con SFPs de 40G o incluso meter CWDM o ¿por qué no? DWDM. Y si los requisitos son más sencillos a lo mejor con un túnel sobre internet puede servir, evidentemente depende muchísimo de los requisitos de cada cliente. También puede ser el caso que queramos tener la grabación de las cámaras de seguridad de una casa, aquí a lo mejor una VPN será suficiente. Depende en cada caso. Ahora, si queremos que los servicios se conecten a Internet tenemos dos opciones, tener direccionamiento propio con BGP o requerir direccionamiento del hoster. Sí, obviamente existe la posibilidad de tener direccionamiento propio pero no BGP, pero eso hablamos otro día porque no es lo normal. Si tienes direccionamiento público y AS lo ideal es levantar un par de sesiones BGP (al menos) con un par de routers y adelante. Si quieres direccionamiento del hoster pues tendrás que ponerte un gateway, que será un firewall, un router o similar y enrutar por ahí, obviamente el hoster también tiene que enrutar por ese equipo tu direccionamiento. Todo está está muy bien, pero seguro que no hay nada nuevo, la gracia de esto es ¿cómo pongo los cables? pues ahí es donde está la chicha de todo esto. Hay varias posibilidades, desde la más simple, en la cual le doy al cliente un único cable cable que une la plataforma del hoster con el firewall del cliente, el hoster configura una ruta al rango asignado al cliente hacia el firewall y el cliente una ruta por defecto a través de su firewall. Esta solución no es la mejor obviamente, para un servidor vale, pero para una infraestructura no es lo óptimo. A partir de aquí podemos complicar esto hasta el infinito dando más seguridad y más redundancia. Por ejemplo, si el cliente tiene un único firewall pero la posibilidad de tener dos uplinks podemos darle un LACP conectado a dos switches Nexus con VPC, de forma que si cayese un switch o uno de los cables el cliente seguiría funcionando por el otro cable, sin convergencias ni nada de nada porque el LACP seguiría funcionando, pero sólo por un puerto, cuando levantara de nuevo el enlace caído el LACP se volvería a formar con dos puertos. Esta solución es muy limpia y a mi personalmente me gusta, ¿cómo se configura? En el lado del hoster hay que configurar un LACP y una VLAN, y será esa VLAN la que pasemos por el LACP y el gateway para el cliente estará configurado en un interfaz VLAN que puede estar en ese mismo VPC, la pareja de switches, o en otro lado donde llegue la VLAN en cuestión. En el lado del cliente simplemente hay que configurar un LACP para el interfaz externo. Si el cliente quiere poner un switch será igual que si pone un servidor o un firewall, pero ¿qué pasa si quiere poner dos switches?, aquí hay que ir con cuidado y tenemos que ver si el cliente nos ofrece confianza suficiente porque sus equipos van a enviar BPDUs y van a ser capaces de bloquear puertos de Spanning Tree, así que ahí con cariño. Pero el problema importante surge en el momento en el que el hoster poner un par de Nexus en VPC y el cliente se pone otro par de Nexus, también en VPC y tiramos un par de cables, ahí la redundancia es total, pero claro, en este tipo de escenarios puedes encontrarte que ambas parejas de VPC se ponen como root de STP en las vlans que pasan por esos cables y las vlans entre las dos parejas de switches quedan bloqueadas por spanning tree, así que es interesante definir el root de spanning tree preferiblemente en el lado del hoster. De todos modos yo no soy nada partidario de que el cliente se conecte directamente con unos switches a nivel 2, siempre que se pueda que el cliente ponga un dispositivo de capa 3, un router o un firewall, eso es lo ideal para todas las partes. También se puede hacer el balanceo con ECMP en BGP, simplemente poniendo varios interfaces y creando una sesión BGP de loopback a loopback usando esos enlaces, y ahí nos quitamos todo el problema de los spanning tree y de los balanceos por LACP.

Eres una empresa que has ido creciendo y necesitas contratar un rack en un centro de datos para poder ahí los servidores de tu empresa y dar servicio. ¿Qué posibilidades tienes para darle conectividad a ese rack? porque es obvio que vas a necesitar algún tipo de conectividad, si contratas un rack, unas Us o incluso una sala vas a querer conectarte a ella de alguna manera. Este tema quería tratarlo en un hilo de Twitter, pero claro, según iba pensando se me disparaban las posibilidades, así que este capítulo de hoy es un hilo de Twitter que bien ha merecido su propio audio en el podcast. De hecho el hilo en cuestión se me escapó a medio escribir y me lo tuve que cargar. Lo primero es decidir si la conectividad va a ser pública o no, porque no todos los racks están conectados al Internet público, algunos racks son simplemente cabinas de replicación, es decir, la replicación de una cabina que está en la oficina del cliente, para evitar desastres y cosas así. En este caso es posible que sólo queramos que la cabina sea accesible únicamente desde la oficina principal donde está la otra cabina, en este caso lo normal es contratar capacidad portadora, es decir, una conexión de 1 o 10G a un operador y que sea la únión del CPD con la oficina de la empresa. Si los requisitos son mayores siempre se puede poner una fibra oscura e iluminarla con SFPs de 40G o incluso meter CWDM o ¿por qué no? DWDM. Y si los requisitos son más sencillos a lo mejor con un túnel sobre internet puede servir, evidentemente depende muchísimo de los requisitos de cada cliente. También puede ser el caso que queramos tener la grabación de las cámaras de seguridad de una casa, aquí a lo mejor una VPN será suficiente. Depende en cada caso. Ahora, si queremos que los servicios se conecten a Internet tenemos dos opciones, tener direccionamiento propio con BGP o requerir direccionamiento del hoster. Sí, obviamente existe la posibilidad de tener direccionamiento propio pero no BGP, pero eso hablamos otro día porque no es lo normal. Si tienes direccionamiento público y AS lo ideal es levantar un par de sesiones BGP (al menos) con un par de routers y adelante. Si quieres direccionamiento del hoster pues tendrás que ponerte un gateway, que será un firewall, un router o similar y enrutar por ahí, obviamente el hoster también tiene que enrutar por ese equipo tu direccionamiento. Todo está está muy bien, pero seguro que no hay nada nuevo, la gracia de esto es ¿cómo pongo los cables? pues ahí es donde está la chicha de todo esto. Hay varias posibilidades, desde la más simple, en la cual le doy al cliente un único cable cable que une la plataforma del hoster con el firewall del cliente, el hoster configura una ruta al rango asignado al cliente hacia el firewall y el cliente una ruta por defecto a través de su firewall. Esta solución no es la mejor obviamente, para un servidor vale, pero para una infraestructura no es lo óptimo. A partir de aquí podemos complicar esto hasta el infinito dando más seguridad y más redundancia. Por ejemplo, si el cliente tiene un único firewall pero la posibilidad de tener dos uplinks podemos darle un LACP conectado a dos switches Nexus con VPC, de forma que si cayese un switch o uno de los cables el cliente seguiría funcionando por el otro cable, sin convergencias ni nada de nada porque el LACP seguiría funcionando, pero sólo por un puerto, cuando levantara de nuevo el enlace caído el LACP se volvería a formar con dos puertos. Esta solución es muy limpia y a mi personalmente me gusta, ¿cómo se configura? En el lado del hoster hay que configurar un LACP y una VLAN, y será esa VLAN la que pasemos por el LACP y el gateway para el cliente estará configurado en un interfaz VLAN que puede estar en ese mismo VPC, la pareja de switches, o en otro lado donde llegue la VLAN en cuestión. En el lado del cliente simplemente hay que configurar un LACP para el interfaz externo. Si el cliente quiere poner un switch será igual que si pone un servidor o un firewall, pero ¿qué pasa si quiere poner dos switches?, aquí hay que ir con cuidado y tenemos que ver si el cliente nos ofrece confianza suficiente porque sus equipos van a enviar BPDUs y van a ser capaces de bloquear puertos de Spanning Tree, así que ahí con cariño. Pero el problema importante surge en el momento en el que el hoster poner un par de Nexus en VPC y el cliente se pone otro par de Nexus, también en VPC y tiramos un par de cables, ahí la redundancia es total, pero claro, en este tipo de escenarios puedes encontrarte que ambas parejas de VPC se ponen como root de STP en las vlans que pasan por esos cables y las vlans entre las dos parejas de switches quedan bloqueadas por spanning tree, así que es interesante definir el root de spanning tree preferiblemente en el lado del hoster. De todos modos yo no soy nada partidario de que el cliente se conecte directamente con unos switches a nivel 2, siempre que se pueda que el cliente ponga un dispositivo de capa 3, un router o un firewall, eso es lo ideal para todas las partes. También se puede hacer el balanceo con ECMP en BGP, simplemente poniendo varios interfaces y creando una sesión BGP de loopback a loopback usando esos enlaces, y ahí nos quitamos todo el problema de los spanning tree y de los balanceos por LACP.

He contratado un rack y ¿ahora cómo me conecto?

Redes, hosting y sistemas. Networking, Linux y más en español.

Podcast de Redes de Eduardo Collado

«LXC (Linux Containers) es una tecnología de virtualización en el nivel de sistema operativo (SO) para Linux. LXC permite que un servidor físico ejecute múltiples instancias de sistemas operativos aislados, conocidos como Servidores Privados Virtuales (SPV o VPS en inglés) o Entornos Virtuales (EV). LXC no provee de una máquina virtual, más bien provee un entorno virtual que tiene su propio espacio de procesos y redes.» Como definición introductoria está muy bien, pero como muchas de las definiciones que podemos encontrar la Wikipedia precisarían ampliarse si queremos profundizar un poco. Como LXC provee de un entorno virtual no necesitamos emular hardware, esto es muy importante porque no vamos a tener una penalización por emulación de hardware, es decir, nuestro sistema va a ser muy rápido, por ejemplo no tendremos penalización en escritura en disco. Por desgracia también tenemos desventajas. Como LXC provee de un entorno virtual el kernel es fijo, no podemos ni modificarlo ni tocarlo de ninguna manera, principalmente porque el kernel está corriendo en el sistema anfitrión. Otra de las desventajas es que sólo y exclusivamente podemos instalar máquinas Linux, esto no funciona con otros sistemas operativos como Windows, BSD o Solaris. KVM sin embargo virutaliza todo, hasta el hardware, realiza una virtualización a nivel de Kernel. Al instalar una máquina virtual sobre KVM el resultado será el mismo que si se hubiera instalado en un hardware físico, y no tendremos las limitaciones que tenemos en una virtualización más ligera como es la de LXC. El hipervisor KVM será el encargado de proporcionar a las máquinas virtuales las extensiones KVM del kernel, de emular el hardware de la máquina y de asignar los recursos para cada máquina virtual. Esto es memoria, CPU, disco, IOPs, en fin, todo lo que se os pueda ocurrir. Obviamente en KVM no tenemos ninguna atadura con el sistema operativo anfitrión, con lo que sería posible instalar máquinas virtuales Windows o BSD sin problemas. Sin embargo instalar máquinas virtuales MacosX no se puede, pero no es un problema técnico, es porque en la licencia de uso de Apple especifíca claramente que no se puede hacer, así que donde hay patrón no manda marinero. En máquinas virtualizadas sobre KVM podríamos levantar interfaces TUN o TAP sin problemas, cosa que en LXC por ejemplo no se podría hacer. Hay una diferencia que es fundamental en cuanto a la reserva de recursos, en KVM la reserva de recursos se hace en el momento en el que arranca la máquina virtual mientras que en LXC la reserva se va haciendo según va siendo necesaria. Esto significa que en un hipervisor siempre vamos a poder meter más máquinas LXC que KVM, y esto es muy importante. Ya os he comentado que la virtualización es completa con KVM, esto significa que el acceso a disco, a memoria o a cualquier otro hardware precisará de una emulación de hardware, lo que hará un poco más pesado a nuestro sistema, pero es un peaje justo por tener una virtualización completa. Ahora lo que tenemos que decidir es qué tecnología es para nosotros, cual nos interesa más KVM o LXC. Primero de todo asumo que estamos en el lado que necesita una máquina virtual, y no en el lado que tiene los hipervisores. Si queremos un VPS para funcionar con webs y no tenemos requisitos especiales un LXC será más que suficiente y como se pueden provisionar más servidores con LXC por hipervisor siempre va a repercutir en el precio un poco porque lo normal es que sean un poco más baratos, eso sí, es posbile que en un hipervisor se haya aprovisionado más memoria de lo existente, realmente esto es lo normal y es algo que deberiáis de preguntar siempre, qué política de asignación de memoria hay. Si queréis asegurar recursos lo ideal será una máquina virtual sobre KVM, pero también os recomiendo que os informéis sobre esto porque si contratáis una máquina KVM en un hipervisor con 128G de RAM y hay 64 máquinas de 2G de RAM cada una en cuanto alguna empiece a paginar se puede liar parda, es importante tener claras estas cosas, hay que tener un cálculo sobre este tipo de cosas, pero por desgracia en muchos sitios esto no se tiene en cuenta y pasa lo que pasa. Si necesitáis una máquina virtual con características especiales, como por ejemplo terminar conexiones OpenVPN necesitaréis una máquina KVM por lo que hemos comentado anteriormente de los interfaces TUN y TAP.

«<a href="https://es.wikipedia.org/wiki/LXC" rel="noopener noreferrer nofollow" target="_blank">LXC (Linux Containers) es una tecnología de virtualización en el nivel de sistema operativo (SO) para Linux. LXC permite que un servidor físico ejecute múltiples instancias de sistemas operativos aislados, conocidos como Servidores Privados Virtuales (SPV o VPS en inglés) o Entornos Virtuales (EV). LXC no provee de una máquina virtual, más bien provee un entorno virtual que tiene su propio espacio de procesos y redes.</a>» Como definición introductoria está muy bien, pero como muchas de las definiciones que podemos encontrar la Wikipedia precisarían ampliarse si queremos profundizar un poco. Como LXC provee de un entorno virtual no necesitamos emular hardware, esto es muy importante porque no vamos a tener una penalización por emulación de hardware, es decir, nuestro sistema va a ser muy rápido, por ejemplo no tendremos penalización en escritura en disco. Por desgracia también tenemos desventajas. Como LXC provee de un entorno virtual el kernel es fijo, no podemos ni modificarlo ni tocarlo de ninguna manera, principalmente porque el kernel está corriendo en el sistema anfitrión. Otra de las desventajas es que sólo y exclusivamente podemos instalar máquinas Linux, esto no funciona con otros sistemas operativos como Windows, BSD o Solaris. KVM sin embargo virutaliza todo, hasta el hardware, realiza una virtualización a nivel de Kernel. Al instalar una máquina virtual sobre KVM el resultado será el mismo que si se hubiera instalado en un hardware físico, y no tendremos las limitaciones que tenemos en una virtualización más ligera como es la de LXC. El hipervisor KVM será el encargado de proporcionar a las máquinas virtuales las extensiones KVM del kernel, de emular el hardware de la máquina y de asignar los recursos para cada máquina virtual. Esto es memoria, CPU, disco, IOPs, en fin, todo lo que se os pueda ocurrir. Obviamente en KVM no tenemos ninguna atadura con el sistema operativo anfitrión, con lo que sería posible instalar máquinas virtuales Windows o BSD sin problemas. Sin embargo instalar máquinas virtuales MacosX no se puede, pero no es un problema técnico, es porque en la licencia de uso de Apple especifíca claramente que no se puede hacer, así que donde hay patrón no manda marinero. En máquinas virtualizadas sobre KVM podríamos levantar interfaces TUN o TAP sin problemas, cosa que en LXC por ejemplo no se podría hacer. Hay una diferencia que es fundamental en cuanto a la reserva de recursos, en KVM la reserva de recursos se hace en el momento en el que arranca la máquina virtual mientras que en LXC la reserva se va haciendo según va siendo necesaria. Esto significa que en un hipervisor siempre vamos a poder meter más máquinas LXC que KVM, y esto es muy importante. Ya os he comentado que la virtualización es completa con KVM, esto significa que el acceso a disco, a memoria o a cualquier otro hardware precisará de una emulación de hardware, lo que hará un poco más pesado a nuestro sistema, pero es un peaje justo por tener una virtualización completa. Ahora lo que tenemos que decidir es qué tecnología es para nosotros, cual nos interesa más KVM o LXC. Primero de todo asumo que estamos en el lado que necesita una máquina virtual, y no en el lado que tiene los hipervisores. Si queremos un VPS para funcionar con webs y no tenemos requisitos especiales un LXC será más que suficiente y como se pueden provisionar más servidores con LXC por hipervisor siempre va a repercutir en el precio un poco porque lo normal es que sean un poco más baratos, eso sí, es posbile que en un hipervisor se haya aprovisionado más memoria de lo existente, realmente esto es lo normal y es algo que deberiáis de preguntar siempre, qué política de asignación de memoria hay. Si queréis asegurar recursos lo ideal será una máquina virtual sobre KVM, pero también os recomiendo que os informéis sobre esto porque si contratáis una máquina KVM en un hipervisor con 128G de RAM y hay 64 máquinas de 2G de RAM cada una en cuanto alguna empiece a paginar se puede liar parda, es importante tener claras estas cosas, hay que tener un cálculo sobre este tipo de cosas, pero por desgracia en muchos sitios esto no se tiene en cuenta y pasa lo que pasa. Si necesitáis una máquina virtual con características especiales, como por ejemplo terminar conexiones OpenVPN necesitaréis una máquina KVM por lo que hemos comentado anteriormente de los interfaces TUN y TAP.

Diferencias entre KVM y LXC

Hola a todos, yo soy Eduardo, esto es eduardocollado.com y hoy me he puesto a repasar un poco lo que llevamos hecho en el podcast hasta hoy, el objetivo del audio de hoy es contaros un poco cómo veo yo la situación y que vamos a hacer para intentar mejorar un poco el podcast, sí, hoy un programa un poco rarete, pero de vez en cuando hay que hacer estas cosas si queremos empujar para arriba. Con este capítulo llevamos juntos ya casi casi dos años. 180 audios entre capítulos regulares y especiales, en total algo más de 4,5 gigas de audio en mp3 de 128 kbps, o lo que es lo mismo, algo más de 75 horas de audio, que ahí se dice pronto, ¿verdad? En estas 75 horas de audio hemos hablado de muchísimas cosas, desde protocolos de routing, pasando por buenas prácticas hasta cosas más extrañas como ceph o cableado de racks. Realmente, y lo digo en serio, estoy asustado de haber sido capaz de hablar a un micrófono durante más de 75 horas de todas estas cosas, está claro que hablo mucho. Pero esas 75 horas de audio viendolas desde este momento creo que se pueden mejorar y tratar de otra manera. Las herramientas que dispongo ahora no son las que tenía en el 2016, la experiencia tampoco, y creo que se podría reencaminar todo para hacer el podcast más amable, porque hay capítulos … no me digáis que no, pero alguno es infumable y eso hay que evitarlo. Llevo un tiempo pensando en como darle un aire nuevo al podcast, cómo refrescarlo un poco y creo que es el momento. Este fin de semana fueron las JPod, las jornadas de podcasting en Madrid, y he tenido bastantes charlas con bastante gente del podcasting,y eso me ha permitido aprender basntate, bueno, al menos he intentado escuchar al máximo para aprender todo lo que he podido con el objetivo de mejorar el podcast, así que voy a ver si soy capaz. Veréis tengo una suerte enorme, puedo hacer el podcast como me de la gana, no tengo ningún jefe que me indique el camino a seguir ni cómo seguirlo, así que la libertar es plena, la libertad es total para mi y para los que estáis en el otro lado y encima tenemos un grupo de Telegram que nos debería de ayudar a comunicarnos, aunque hay otras formas como twitter o el correo electrónico, esa herramienta tan maravillosa que nos ha permitido comunicarnos durante tanto tiempo de una forma tan estupenda, por cierto, yo soy edu [-arroba-] eduardocollado.com. Así que una de las cosas que voy a intentar es apoyarme más en la gente que escucha el podcast, pero necesito que os mostréis, que digáis ese «estoy aquí», de verdad, no como niños por las noches ni hago cosas extrañas, soy una persona muy normal con sus defectos y sus virtudes, como cualquier otro No se si os acordáis que al principio decía donde se podía suscribir uno y todo eso, bueno, pues eso hacía que según las estadísticas de Apple los últimos segundos cayeran las escuchas un montón, y claro, si alguien está suscrito y le recuerdas como suscribirse .,.. pues mucho sentido no tiene, así que todo ese rollo lo suprimí hace tiempo y creo que fue todo un acierto, bueno, pues esa información la pude obtener estudiando un poco los datos que tenía de las escuchas De momento os voy a contar donde ha habido más interés en estos dos años teniendo en cuenta las descargas tanto en el blog como en las plataformas donde se distribuye: En cuanto a las descargas de audios las categorías 1.- audios grabados con más gente, EN GRUPO (directo con top y zordor) el 10G con top o el de charlando de sreguridad de la web con Javi y Fer o oddoo y transofrmación digital con Luis Jaime o el de la KSK de los raíces de DNS con Joao Damas 2.- el audio de en casa del herrero, el del cableado de mi casa (EXPERIENCIAS PERSONALES) 3.- Distribuir en un rack, por que no redes grandes, etc… cosas aprendidas por experiencias, pero sin ser salseo, podría meterlo econ lo de arriba 3.- DNS (en este tema he insistido mucho) podría meterlo con lo de abajo 4.- ZeroTier, pihole, openvpn … ese tipo de cosas 4.- Protocolos der routing 4.- IPv6 Así que como aprendizaje saco de aquí que tengo que rodearme de gente y contar si es posible cosas que no estén en libros, es decir, cosas aprendidas por la experiencia, aunque sean chorradas como el saber por qué tubo hay que pasar un cable en casa. Las diferencias de unas temáticas a otras en descargas son enormes, lo cual me sorprende y no termino de entender muy bien como funciona el tema, pero bueno, es lo que hay y esos son los datos. Esos datos harían más referencia a lo que sería el contenido de los audios, pero claro, hay más cosas a tener en cuenta como por ejemplo cómo se ha grabado. En mi caso hasta ahora la grabación del podcast es muy sencilla, un papelito con lo que voy a decir, un micro, música de fondo y tira millas, más sencillo imposible, la única innovación que he tenido en los últimos meses ha sido una pizarra de velleda y rotuladores de colores. No estoy hablando de la calidad del micrófono ni nada parecido, la verdad es que creo que la calidad del audio ya es bastante aceptable, es mejorable, claro, pero tampoco hay que volverse loco, ahora creo que el problema y lo que hay que mejorar está en otro sitio. El podcast ni tiene secciones, ni separadores, ni nada de nada y eso hace un poco más compleja su escucha, así que vamos a mejorar eso un poco, realmente lo que hay que hacer es empezar a dividir el contenido y crear todas esas cosas, secciones, separadores y demás. Con esto parece ser que se libera la atención del oyente y se vuelve a capturar más fácil, en este audio he empezado a hacerlo ya me contaréis si lo estoy consiguiendo o no, aunque quizás se empiece a notar en otro tipo de audios, bueno, poco a poco. No hace falta crear un podcast con secciones fijas, que va, pero sí organizar un poco más los contenidos e intentar evitar el estar durante 20 minutos seguidos hablando sobre algo concreto, creo que es muy difícil mantener la atención. La razón es simplemente hacer que los contenidos sean más fáciles de consumir, al menos es mi intención. Por supuesto, si esto que digo os parece una chorrada o pensáis que está bien, pero que es mejorable comentario, twitter, telegram, un email, lo que queráis. Ya sabéis ecollado en twitter y telegram y edu [-arroba-] eduardocollado.com si queréis mandarme un email o si preferís tenéis un formulario de contacto en la web, lo que queráis de verdad, creo que no puedo dejar más fácil el que os podáis comunicar conmigo. El objetivo es dejar un contenido fácil de consumir, pero sin dejar de un un podcast técnico, no voy a empezar a tratar otros temas no os preocupéis, la idea es tratar los mismos temas, pero intentar ser más organizado. Los oyentes de podcasts me dicen los gurús que quieren historias, sí sí, así me lo dicen, eso significa que hay que intentar enlazar los contenidos creando unos ambientes propicios para cada contenido. Sí, lo se, suena de coña, pero parece que no digo nada. La idea es hacer audios en la mesa, como ahora, en la calle, con más gente, introducir audios de otros, etc… es decir, intentar que la forma de generar el contenido sea lo más variada posible. Esto ya os digo que sobre el papel es maravilloso, pero que en la práctica va a ser bastante más complicado de lo que parece. Pero habrá que intentarlo. Bueno amigos, estoy totalmente abierto a vuestros comentarios, sugerencias, quejas, etc… el capítulo de hoy es una declaración de intenciones y una pequeña muestra de hacia donde hay que ir yendo. Vuestros comentarios son y serán siempre bienvenidos así que daros las gracias y agradeceros el tiempo.

Hola a todos, yo soy Eduardo, esto es <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> y hoy me he puesto a repasar un poco lo que llevamos hecho en el podcast hasta hoy, el objetivo del audio de hoy es contaros un poco cómo veo yo la situación y que vamos a hacer para intentar mejorar un poco el podcast, sí, hoy un programa un poco rarete, pero de vez en cuando hay que hacer estas cosas si queremos empujar para arriba. Con este capítulo llevamos juntos ya casi casi dos años. 180 audios entre capítulos regulares y especiales, en total algo más de 4,5 gigas de audio en mp3 de 128 kbps, o lo que es lo mismo, algo más de 75 horas de audio, que ahí se dice pronto, ¿verdad? En estas 75 horas de audio hemos hablado de muchísimas cosas, desde protocolos de routing, pasando por buenas prácticas hasta cosas más extrañas como ceph o cableado de racks. Realmente, y lo digo en serio, estoy asustado de haber sido capaz de hablar a un micrófono durante más de 75 horas de todas estas cosas, está claro que hablo mucho. Pero esas 75 horas de audio viendolas desde este momento creo que se pueden mejorar y tratar de otra manera. Las herramientas que dispongo ahora no son las que tenía en el 2016, la experiencia tampoco, y creo que se podría reencaminar todo para hacer el podcast más amable, porque hay capítulos … no me digáis que no, pero alguno es infumable y eso hay que evitarlo. Llevo un tiempo pensando en como darle un aire nuevo al podcast, cómo refrescarlo un poco y creo que es el momento. Este fin de semana fueron las JPod, las jornadas de podcasting en Madrid, y he tenido bastantes charlas con bastante gente del podcasting,y eso me ha permitido aprender basntate, bueno, al menos he intentado escuchar al máximo para aprender todo lo que he podido con el objetivo de mejorar el podcast, así que voy a ver si soy capaz. Veréis tengo una suerte enorme, puedo hacer el podcast como me de la gana, no tengo ningún jefe que me indique el camino a seguir ni cómo seguirlo, así que la libertar es plena, la libertad es total para mi y para los que estáis en el otro lado y encima tenemos un grupo de Telegram que nos debería de ayudar a comunicarnos, aunque hay otras formas como twitter o el correo electrónico, esa herramienta tan maravillosa que nos ha permitido comunicarnos durante tanto tiempo de una forma tan estupenda, por cierto, yo soy edu [-arroba-] <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>. Así que una de las cosas que voy a intentar es apoyarme más en la gente que escucha el podcast, pero necesito que os mostréis, que digáis ese «estoy aquí», de verdad, no como niños por las noches ni hago cosas extrañas, soy una persona muy normal con sus defectos y sus virtudes, como cualquier otro No se si os acordáis que al principio decía donde se podía suscribir uno y todo eso, bueno, pues eso hacía que según las estadísticas de Apple los últimos segundos cayeran las escuchas un montón, y claro, si alguien está suscrito y le recuerdas como suscribirse .,.. pues mucho sentido no tiene, así que todo ese rollo lo suprimí hace tiempo y creo que fue todo un acierto, bueno, pues esa información la pude obtener estudiando un poco los datos que tenía de las escuchas De momento os voy a contar donde ha habido más interés en estos dos años teniendo en cuenta las descargas tanto en el blog como en las plataformas donde se distribuye: En cuanto a las descargas de audios las categorías 1.- audios grabados con más gente, EN GRUPO (directo con top y zordor) el 10G con top o el de charlando de sreguridad de la web con Javi y Fer o oddoo y transofrmación digital con Luis Jaime o el de la KSK de los raíces de DNS con Joao Damas 2.- el audio de en casa del herrero, el del cableado de mi casa (EXPERIENCIAS PERSONALES) 3.- Distribuir en un rack, por que no redes grandes, etc… cosas aprendidas por experiencias, pero sin ser salseo, podría meterlo econ lo de arriba 3.- DNS (en este tema he insistido mucho) podría meterlo con lo de abajo 4.- ZeroTier, pihole, openvpn … ese tipo de cosas 4.- Protocolos der routing 4.- IPv6 Así que como aprendizaje saco de aquí que tengo que rodearme de gente y contar si es posible cosas que no estén en libros, es decir, cosas aprendidas por la experiencia, aunque sean chorradas como el saber por qué tubo hay que pasar un cable en casa. Las diferencias de unas temáticas a otras en descargas son enormes, lo cual me sorprende y no termino de entender muy bien como funciona el tema, pero bueno, es lo que hay y esos son los datos. Esos datos harían más referencia a lo que sería el contenido de los audios, pero claro, hay más cosas a tener en cuenta como por ejemplo cómo se ha grabado. En mi caso hasta ahora la grabación del podcast es muy sencilla, un papelito con lo que voy a decir, un micro, música de fondo y tira millas, más sencillo imposible, la única innovación que he tenido en los últimos meses ha sido una pizarra de velleda y rotuladores de colores. No estoy hablando de la calidad del micrófono ni nada parecido, la verdad es que creo que la calidad del audio ya es bastante aceptable, es mejorable, claro, pero tampoco hay que volverse loco, ahora creo que el problema y lo que hay que mejorar está en otro sitio. El podcast ni tiene secciones, ni separadores, ni nada de nada y eso hace un poco más compleja su escucha, así que vamos a mejorar eso un poco, realmente lo que hay que hacer es empezar a dividir el contenido y crear todas esas cosas, secciones, separadores y demás. Con esto parece ser que se libera la atención del oyente y se vuelve a capturar más fácil, en este audio he empezado a hacerlo ya me contaréis si lo estoy consiguiendo o no, aunque quizás se empiece a notar en otro tipo de audios, bueno, poco a poco. No hace falta crear un podcast con secciones fijas, que va, pero sí organizar un poco más los contenidos e intentar evitar el estar durante 20 minutos seguidos hablando sobre algo concreto, creo que es muy difícil mantener la atención. La razón es simplemente hacer que los contenidos sean más fáciles de consumir, al menos es mi intención. Por supuesto, si esto que digo os parece una chorrada o pensáis que está bien, pero que es mejorable comentario, twitter, telegram, un email, lo que queráis. Ya sabéis ecollado en twitter y telegram y edu [-arroba-] <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> si queréis mandarme un email o si preferís tenéis un formulario de contacto en la web, lo que queráis de verdad, creo que no puedo dejar más fácil el que os podáis comunicar conmigo. El objetivo es dejar un contenido fácil de consumir, pero sin dejar de un un podcast técnico, no voy a empezar a tratar otros temas no os preocupéis, la idea es tratar los mismos temas, pero intentar ser más organizado. Los oyentes de podcasts me dicen los gurús que quieren historias, sí sí, así me lo dicen, eso significa que hay que intentar enlazar los contenidos creando unos ambientes propicios para cada contenido. Sí, lo se, suena de coña, pero parece que no digo nada. La idea es hacer audios en la mesa, como ahora, en la calle, con más gente, introducir audios de otros, etc… es decir, intentar que la forma de generar el contenido sea lo más variada posible. Esto ya os digo que sobre el papel es maravilloso, pero que en la práctica va a ser bastante más complicado de lo que parece. Pero habrá que intentarlo. Bueno amigos, estoy totalmente abierto a vuestros comentarios, sugerencias, quejas, etc… el capítulo de hoy es una declaración de intenciones y una pequeña muestra de hacia donde hay que ir yendo. Vuestros comentarios son y serán siempre bienvenidos así que daros las gracias y agradeceros el tiempo.

Vista atrás y mejoras en el podcast

Enlaces: El amanecer de la red (vídeo) – https://www.youtube.com/watch?v=0YK3_gg_ZD8  Hola a todos, yo soy Eduardo, esto es eduardocollado.com y hoy en el capítulo número 178 vamos a hablar de un tema del que no hemos todavía, aunque parezca increíble, al menos no lo hemos dedicado un capítulo como debe de ser Efectivamente el modelo OSI, algo que llevamos oyendo muchísimos años y que siempre está ahí como algo que se sabe y como algo muy obvio, pero que no lo es tanto, y es hasta posible que lo hayamos olvidado, así que el capítulo de hoy se lo vamos a dedicar al modelo OSI. El modelo viene de lejos, desde principios de los años 80 y se definió un modelo para la interconexión de sistemas abiertos, de hecho ese es su nombre OSI viene del inglés Open Systems Interconnection. El modelo divide la comunicación en un total de 7 capas o niveles superpuestos definiendo unos interfaces o uniones entre capas y unos protocolos, que no son más que las uniones lógicas entre dos niveles iguales de diferentes hosts. Por ejemplo, hablamos de IP como protocolo porque establece la comunicación entre dos niveles 3 OSI de dos nodos diferentes. Así pues vamosa tener protocolos por cada una de las capas, hay toneladas de protocolos, muchísimos y estos protocolos pueden residir en cualquiera de las 7 capas de modelo OSI. Las capas se organizan desde la más cercana al nivel físico hasta la más cercana a la aplicación. En el nivel superior tendríamos protocolos como FTP, TFTP, SMTP, POP3, HTTP, DNS, BOOTP, etc…, en el nivel inferior nos encontremos protcolos como DSL o el RS-232 (de Recommended Standard 232). Los niveles para nombrarlos de abajo a arriba son:  Físico Enlace de Datos Red Transporte Sesión Presentación Aplicación  Vamos a ir viendo uno a uno si os parece Nivel físico El nivel físico, o nivel 1 de OSI, se encarga de definir las especificaciones físicas de los dispositivos. Se define la relación entre el medio de transmisión y el medio, ya sea un cable electrico, óptico, comunicación inalambrica o lo que sea. En esta capa hay que asegurar que la señal que se envía se reciba en el destino, es decir, hay que definir qué es un 1 y qué es un 0, voltajes, potencia lumínica, en fin, ese tipo de cosas. En este nivel tenemos los cables, conectores, transceptores, tarjetas de red, hubs y en definitiva todo aquello que esté relacionado con lo que acabamos de decir. Este nivel es el que define la parte más física de la comunicación, haciendo la analogía con la comunicación humana este nivel sería el papel para la comunicación escrita o el aire para la comunicación verbal. En la vida real de este nivel necestiamos saber en que potencias se mueven nuestros transceptores, qué tipos de transceptores tenemos que usar, qué tipos de fibra, cuanta potencia llega a nuestras antenas y por qué hay que utilizar cableado categoría 3 o categoría 5e por ejemplo y también es el nivel en el que vamos a tener las limitaciones de distancia de cableados o la regla del 5-4-3 La regla del 5-4-3 nos dice que entre dos equipos no puede haber más de 5 segmentos de cable, 4 repetidores y que de esos sementmos sólo 3 pueden estar poblados. Nivel de enlace de datos El nivel de enlace de datos o nivel 2 OSI y es aquí donde podemos encontrar dos subniveles más, el LLC (Control de enlace lógico) y MAC (Control de acceso al medio) que se describen en profundidad en el IEEE 802.2 Este nivel para todo aquel que se dedique a esto de las redes es de los más importantes. En este nivel es donde vamos a encontrar protocolos como por ejemplo todos aquellos que empiezan por IEEE 802., wimax, ppp, hdlc, en fin, todo. Tened en cuenta que en el modelo TCP/IP el nivel 1 y el 2 se colapsan en un nivel llamado «interfaz de red», así que si no veis claro el por qué ethernet no es nivel físico es por eso. EThernet por poner un ejemplo se encarga del acceso al medio, del control de errores, de la delimitación de la trama, etc… esa es la razón. Volviendo al nivel de enlace deciros que aquí las unidades de información se llaman tramas o frames en inglés, aunque pueden ser celdas también, la diferencia estriba en el tamaño fijo de las celdas, que son las usadas en ATM, serguramente os suene que una celda ATM tiene 53 bytes de longitud contando cabeceras y siempre tienen ese tamaño, sin embargo una trama ethernet, HDLC o Frame Relay no tiene un tamaño prefijado. La tarea principal de esta capa es la detección y corrección de errores. Además, en esta capa el emisor trocea la información en tramas y las envía de forma secuencial teniendo la facultad de poder confirmar que han ido llegando al otro extremo, pueden no llegar por una interferencia o una colisión. En esta capa también hay un control de flujo para evitar la saturación del receptor y es aquí donde tenemos los switches o bridges. En este nivel también tenemos el direccionamiento MAC, las direcciones MAC de los dispositivos. Nivel de red Esta es nuestro nivel o capa favorito, el nivel 3, capa de red, aquí es donde vive nuestros queridos protocolos IP o IPv6, de los que hemos hablado hasta la saciedad. Aquí la unidad de información se llama paquete, seguro que estáis ya cansados de decir paquete IP y trama ethernet, ¿verdad que sí? Aquí es donde se toman las decisiones sobre encaminamiento, es decir, el routing. En el nivel de red es donde tenemos el direccionamiento lógico. Y cuando hablamos de direccionamiento lógico no os quedéis solo en IP o IPv6, tenemos IPX, o incluso OSI tienen su propio esquema de direccionamiento, el cual es utilizaod por ejemplo en IS-IS, un protocolo de routing de estado del enlace al que deberíamos de dedicartle un capítulo entero. Sólo por hacer una breve anotación comentaros que una dirección OSI se divide en dos partes, la IDP (Initial Domain Part) y la DSP (Domain Specific Part). Esto lo normal es que no volváis a escucharlo nunca más en la vida, pero es interesante que sepáis que las direcciones IP o IPv6 no son las únicas direcciones que existen en el Mundo. Hay un concepto muy extendido que puede parecer confuso porque os acabo de comentar que en el nivel 3 es donde tomamos las decisiones de encaminamiento, pero los protocolos de routing no funcionan en nivel 3, sino en niveles superiores, pero una cosa es el intercambio de información y la creación de las tablas de routing y otra muy diferente tomar la decisión de routing. Esto es muy importante porque hay gente que piensa que BGP funciona en nivel 3 y obviamente eso no es así, sobre todo sabiendo que utiliza el puerto 179 de tcp para comunicarse con sus vecinos. Hasta aquí, estos tres niveles: físico, enlace y red son los llamados niveles de medio, los media layers en inglés y esto es porque siempre se va a pasar por estos tres niveles, siempre, en todos los nodos intermedios, porque siempre será necesario tomar una decisión de encaminamiento. A los niveles superiores sólo se llegará si estamos en el destinatario de la comunicación. Nivel de transporte El nivel de transporte, o nivel 4, es la primera capa extremo a extremo. Tengo que reconocer que la primera vez que escuché eso de primera capa extremo a extremo no tenía ni idea de qué me estaban contando ni de lo que estaba pasando, pero se me quedó grabada la frase, realmente eso del extremo a extremo es sensacional. El tema es que el nivel 4 sólo es accesible en los extremos de la comunicación, por ejemplo, si estamos navegando por internet, sólo vamos a pasar por el nivel 4 de nuestro PC y por el nivel 4 del servidor web, no de los hosts intermedios, por eso es el primer nivel extremo a extremo. Este es el nivel de protocolos tan conocidos como TCP o UDP, recordad que TCP es orientado a la conexión y UDP no. En este nivel la unidad de información se llama segmento si es orientado a conexión y datagrama si no lo es, así pues diremos segmento TCP o datagramna UDP La función principal de este nivel es la multiplexación de las conversaciones y aquí son sumamente importantes los interfaces, es decir, las comunicaciones con los protocolos de la capa superior porque en la parte superior, los 3 últimos niveles es donde residen las aplicaciones y este nivel es el encargado de conectar los niveles de media con los de hosts. Los puertos son un concepto que están en este nivel y que identifican los interfaces con las capas superiores, algo muy utilizado por firewalls. Si queréis ampliar información sobre este punto os recomiendo un vídeo que podéis encontrar en You Tube titulado el Amanecer de la red, si tenbéis los 13 minutos que dura os lo recomiendo, son unos dibujos animados y est muy interesante y visual, os dejo en las notas del programa el enlace al vídeo para que podáis verlo. Las tres últimas capas realmente no son super críticas desde el punto de vista de la red, pero sí que es muy importante conocerlas porque el trabajo en la red cada vez se expande más y para comprender la parte de seguridad es crítico dominar la comunicación completa. Nivel de sesión En este nivel se establecen las sesiones entre máquinas remotas. Por ejemplo transferencias de ficheros. Es en este nivel donde se ubica el software y ya no la parte de red que se deja para capas inferiores. Nivel de presentación En el nivel 6 la sintaxis y la semántica de la información es lo que realmente importa y no el movimiento de la información. Aquí la codificación de los datos es algo que hay que controlar. Un ejemplo de protocolo de este nivel sería VT100 Nivel de aplicación Aquí es donde se definiría un interfaz para que cualquier software pudiera trabajar con la red sin tener ni idea de que la red existe, tal cual

Enlaces: El amanecer de la red (vídeo) – <a href="https://www.youtube.com/watch?v=0YK3_gg_ZD8" rel="noopener noreferrer nofollow" target="_blank">https://www.youtube.com/watch?v=0YK3_gg_ZD8</a> Hola a todos, yo soy Eduardo, esto es <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> y hoy en el capítulo número 178 vamos a hablar de un tema del que no hemos todavía, aunque parezca increíble, al menos no lo hemos dedicado un capítulo como debe de ser Efectivamente el modelo OSI, algo que llevamos oyendo muchísimos años y que siempre está ahí como algo que se sabe y como algo muy obvio, pero que no lo es tanto, y es hasta posible que lo hayamos olvidado, así que el capítulo de hoy se lo vamos a dedicar al modelo OSI. El modelo viene de lejos, desde principios de los años 80 y se definió un modelo para la interconexión de sistemas abiertos, de hecho ese es su nombre OSI viene del inglés Open Systems Interconnection. El modelo divide la comunicación en un total de 7 capas o niveles superpuestos definiendo unos interfaces o uniones entre capas y unos protocolos, que no son más que las uniones lógicas entre dos niveles iguales de diferentes hosts. Por ejemplo, hablamos de IP como protocolo porque establece la comunicación entre dos niveles 3 OSI de dos nodos diferentes. Así pues vamosa tener protocolos por cada una de las capas, hay toneladas de protocolos, muchísimos y estos protocolos pueden residir en cualquiera de las 7 capas de modelo OSI. Las capas se organizan desde la más cercana al nivel físico hasta la más cercana a la aplicación. En el nivel superior tendríamos protocolos como FTP, TFTP, SMTP, POP3, HTTP, DNS, BOOTP, etc…, en el nivel inferior nos encontremos protcolos como DSL o el RS-232 (de Recommended Standard 232). Los niveles para nombrarlos de abajo a arriba son: <ul> <li>Físico</li> <li>Enlace de Datos</li> <li>Red</li> <li>Transporte</li> <li>Sesión</li> <li>Presentación</li> <li>Aplicación</li> </ul> Vamos a ir viendo uno a uno si os parece <h3>Nivel físico</h3> El nivel físico, o nivel 1 de OSI, se encarga de definir las especificaciones físicas de los dispositivos. Se define la relación entre el medio de transmisión y el medio, ya sea un cable electrico, óptico, comunicación inalambrica o lo que sea. En esta capa hay que asegurar que la señal que se envía se reciba en el destino, es decir, hay que definir qué es un 1 y qué es un 0, voltajes, potencia lumínica, en fin, ese tipo de cosas. En este nivel tenemos los cables, conectores, transceptores, tarjetas de red, hubs y en definitiva todo aquello que esté relacionado con lo que acabamos de decir. Este nivel es el que define la parte más física de la comunicación, haciendo la analogía con la comunicación humana este nivel sería el papel para la comunicación escrita o el aire para la comunicación verbal. En la vida real de este nivel necestiamos saber en que potencias se mueven nuestros transceptores, qué tipos de transceptores tenemos que usar, qué tipos de fibra, cuanta potencia llega a nuestras antenas y por qué hay que utilizar cableado categoría 3 o categoría 5e por ejemplo y también es el nivel en el que vamos a tener las limitaciones de distancia de cableados o la regla del 5-4-3 La regla del 5-4-3 nos dice que entre dos equipos no puede haber más de 5 segmentos de cable, 4 repetidores y que de esos sementmos sólo 3 pueden estar poblados. <h3>Nivel de enlace de datos</h3> El nivel de enlace de datos o nivel 2 OSI y es aquí donde podemos encontrar dos subniveles más, el LLC (Control de enlace lógico) y MAC (Control de acceso al medio) que se describen en profundidad en el IEEE 802.2 Este nivel para todo aquel que se dedique a esto de las redes es de los más importantes. En este nivel es donde vamos a encontrar protocolos como por ejemplo todos aquellos que empiezan por IEEE 802., wimax, ppp, hdlc, en fin, todo. Tened en cuenta que en el modelo TCP/IP el nivel 1 y el 2 se colapsan en un nivel llamado «interfaz de red», así que si no veis claro el por qué ethernet no es nivel físico es por eso. EThernet por poner un ejemplo se encarga del acceso al medio, del control de errores, de la delimitación de la trama, etc… esa es la razón. Volviendo al nivel de enlace deciros que aquí las unidades de información se llaman tramas o frames en inglés, aunque pueden ser celdas también, la diferencia estriba en el tamaño fijo de las celdas, que son las usadas en ATM, serguramente os suene que una celda ATM tiene 53 bytes de longitud contando cabeceras y siempre tienen ese tamaño, sin embargo una trama ethernet, HDLC o Frame Relay no tiene un tamaño prefijado. La tarea principal de esta capa es la detección y corrección de errores. Además, en esta capa el emisor trocea la información en tramas y las envía de forma secuencial teniendo la facultad de poder confirmar que han ido llegando al otro extremo, pueden no llegar por una interferencia o una colisión. En esta capa también hay un control de flujo para evitar la saturación del receptor y es aquí donde tenemos los switches o bridges. <h3>En este nivel también tenemos el direccionamiento MAC, las direcciones MAC de los dispositivos.</h3> <h3>Nivel de red</h3> Esta es nuestro nivel o capa favorito, el nivel 3, capa de red, aquí es donde vive nuestros queridos protocolos IP o IPv6, de los que hemos hablado hasta la saciedad. Aquí la unidad de información se llama paquete, seguro que estáis ya cansados de decir paquete IP y trama ethernet, ¿verdad que sí? Aquí es donde se toman las decisiones sobre encaminamiento, es decir, el routing. En el nivel de red es donde tenemos el direccionamiento lógico. Y cuando hablamos de direccionamiento lógico no os quedéis solo en IP o IPv6, tenemos IPX, o incluso OSI tienen su propio esquema de direccionamiento, el cual es utilizaod por ejemplo en IS-IS, un protocolo de routing de estado del enlace al que deberíamos de dedicartle un capítulo entero. Sólo por hacer una breve anotación comentaros que una dirección OSI se divide en dos partes, la IDP (Initial Domain Part) y la DSP (Domain Specific Part). Esto lo normal es que no volváis a escucharlo nunca más en la vida, pero es interesante que sepáis que las direcciones IP o IPv6 no son las únicas direcciones que existen en el Mundo. Hay un concepto muy extendido que puede parecer confuso porque os acabo de comentar que en el nivel 3 es donde tomamos las decisiones de encaminamiento, pero los protocolos de routing no funcionan en nivel 3, sino en niveles superiores, pero una cosa es el intercambio de información y la creación de las tablas de routing y otra muy diferente tomar la decisión de routing. Esto es muy importante porque hay gente que piensa que BGP funciona en nivel 3 y obviamente eso no es así, sobre todo sabiendo que utiliza el puerto 179 de tcp para comunicarse con sus vecinos. Hasta aquí, estos tres niveles: físico, enlace y red son los llamados niveles de medio, los media layers en inglés y esto es porque siempre se va a pasar por estos tres niveles, siempre, en todos los nodos intermedios, porque siempre será necesario tomar una decisión de encaminamiento. A los niveles superiores sólo se llegará si estamos en el destinatario de la comunicación. <h3>Nivel de transporte</h3> El nivel de transporte, o nivel 4, es la primera capa extremo a extremo. Tengo que reconocer que la primera vez que escuché eso de primera capa extremo a extremo no tenía ni idea de qué me estaban contando ni de lo que estaba pasando, pero se me quedó grabada la frase, realmente eso del extremo a extremo es sensacional. El tema es que el nivel 4 sólo es accesible en los extremos de la comunicación, por ejemplo, si estamos navegando por internet, sólo vamos a pasar por el nivel 4 de nuestro PC y por el nivel 4 del servidor web, no de los hosts intermedios, por eso es el primer nivel extremo a extremo. Este es el nivel de protocolos tan conocidos como TCP o UDP, recordad que TCP es orientado a la conexión y UDP no. En este nivel la unidad de información se llama segmento si es orientado a conexión y datagrama si no lo es, así pues diremos segmento TCP o datagramna UDP La función principal de este nivel es la multiplexación de las conversaciones y aquí son sumamente importantes los interfaces, es decir, las comunicaciones con los protocolos de la capa superior porque en la parte superior, los 3 últimos niveles es donde residen las aplicaciones y este nivel es el encargado de conectar los niveles de media con los de hosts. Los puertos son un concepto que están en este nivel y que identifican los interfaces con las capas superiores, algo muy utilizado por firewalls. Si queréis ampliar información sobre este punto os recomiendo un vídeo que podéis encontrar en You Tube titulado el Amanecer de la red, si tenbéis los 13 minutos que dura os lo recomiendo, son unos dibujos animados y est muy interesante y visual, os dejo en las notas del programa el enlace al vídeo para que podáis verlo. Las tres últimas capas realmente no son super críticas desde el punto de vista de la red, pero sí que es muy importante conocerlas porque el trabajo en la red cada vez se expande más y para comprender la parte de seguridad es crítico dominar la comunicación completa. <h3>Nivel de sesión</h3> En este nivel se establecen las sesiones entre máquinas remotas. Por ejemplo transferencias de ficheros. Es en este nivel donde se ubica el software y ya no la parte de red que se deja para capas inferiores. <h3>Nivel de presentación</h3> En el nivel 6 la sintaxis y la semántica de la información es lo que realmente importa y no el movimiento de la información. Aquí la codificación de los datos es algo que hay que controlar. Un ejemplo de protocolo de este nivel sería VT100 <h3>Nivel de aplicación</h3> Aquí es donde se definiría un interfaz para que cualquier software pudiera trabajar con la red sin tener ni idea de que la red existe, tal cual

Modelo OSI

HSRP – Host Standby Routing Protocol Lo primero que hay que decir de HSRP es que es un protocolo propietario de Cisco, así que si vuestros routers o switches no son Cisco, os podéis saltar este protocolo porque sólo funcionará en Cisco. HSRP que viene definido en la RFC 2281 (https://www.ietf.org/rfc/rfc2281.txt) funciona asignando los routers a un grupo de redundancia, un grupo HSRP, y seleccionando un router como primario o activo, otro como secundario o standby y todos los demás quedarán en estado listen. Es decir, podemos tener un grupo con 10 equipos, pero sólo habrá cada vez uno activo y otro en standby, el resto se quedarán escuando, no participarán en la redundancia. El router activo será el que tenga una IP flotante o virtual que será el gateway, esa IP la definiremos en todos los routers del grupo, pero solo estará activa en el router activo. Los routers elegirán el activo y el standby basandose en prioridades y se comunicarán entre sí utilizando el puerto 1985 sobre UDP en la dirección de Multicast 224.0.0.2. Tened en cuenta que el número de grupos de HSRP que se permiten dependen del equipo, hay equipos que soportan los 255 que permiten los 8 bits de identificación de grupo HSRP y otros equipos solo permiten 16 grupos, esto tendréis que mirarlo en la documentación de cada equipo concreto. ¿Cómo se eligen los routers principales en cada grupo de HSRP? Se eligen gracias a la prioridad que definimos con el comandostandby  priorityEn este comando hemso definido la prioridad y claro, como es una prioridad el que tenga la prioridad más alta será el elegido como primario y el siguiente como standby, si no definimos la prioridad esta se tomará en función de la IP del interfaz. El router activo será el gateway HSRP tiene unos estados por los que van pasando los routers para cada grupo, son unos estados que recuerdan de alguna manera a los de STP:  Disabled – Desactivado Init – Se inicia Listen – Escuchamos Speak – HablamosStandby – Identifica que el interfaz es el del router standby Active – Identifica que el interfaz es el del router activo  Además los routers tienen que saber si en algún momento se ha caído el activo y por tanto la IP debe de pasar al router de standby y hay que volver a seleccionar el activo y el standby de nuevo. Para saber si el router activo ha caído utizaremos mensajes de hello que por defecto se envían cada 3 segundos y en el momento de pasar el temporizador de holdtime, que por defecto son 3 hellos, se produce el cambio de standby por activo. Por supuesto estos temporizadores son modificables y se pueden ajustar a nuestras necesidades, pero es muy importante tener en cuenta que los temporizadores deben ser los mismos en todos los routers del mismo grupo, muy importante. Hay que tener en cuenta que si tenemos un router con más prioridad porque queremos que sea el activo, si esta cae el activo será el router de standby, pero una vez que se recupere el router principal no volverá a ser router activo, es decir, puede haber routers con mayor prioridad en la red que no sean el router activo, para solucionar esto existe el preemtion, es decir, tenemos que añadir a la configuración la palabra preemptstandby  preemptAdemás HSRP tiene una característica que es muy chula, es el tracking. El tracking lo que hace es mirar el estado de otros interfaces para conmutar, esto permite que podamos bajar la prioridad de un router en el momento el que caiga otro interfaz, y nos va a permitir mejorar muchísimo la red. Por ejemplo, si tenemos dos routers con dos salidas a internet y un grupo HSRP en la LAN, si se cae un interfaz WAN en algún router podríamos con tracking hacer que la prioridad del HSRP de ese router en la LAN bajara de forma que el tráfico empezaría a salir por el router que tiene la conexión WAN activa. Por supuesto podemos habilitar autenticación entre los miembros del grupo HSRP con una contraseña, clave, hash, etc. por seguridad. Y ¿cómo ofrecemos el balanceo? Realmente para ofrecer un balanceo con HSRP lo que hacemos es definir dos grupos y ofrecer a la mitad de la red un gateway y otro a la otra mitad de la red, de forma que si fallara algún grupo todo el tráfico iría por el mismo router, pero mientras la mitad de la red iría por un router y la otra mitad por el otro router. Esto obviamente no es una característica de HSRP, sino una de las posibilidades que tenemos. VRRP – Virtual Router Redundancy Protocol VRRP a diferencia de HSRP es un protocolo abierto que puede utilizar cualquier fabricante de equipos, de hecho, es el protocolo estándar en todos los equipos no cisco. VRRP viene definido en la RFC 2338 (https://www.ietf.org/rfc/rfc2338.txt) y al y como os contaré en un momento es un protocolo extremadamente similar a HSRP, de hecho es perfectamente sustituible en la inmensa mayoría de los casos. VRRP nos ofrece una IP flotante virtual como gateway que va a estar siempre en el router master, lo que en HSRP se conoce como activo, el resto de routers serán backup, todos ellos, recordad que en HSRP sólo tenemos un router standby y aquí lo son todos excepto el master que es el que tiene la mayor prioridad. Una diferencia está en los mensajes hello, que en HSRP se enviaban por defecto cada 3 segundos y en VRRP cada segundo. Pero la diferencia fundamental de VRRP con HSRP estriba en que VRRP por defecto hay preemption, con lo que nos asegurammos que nunca va a haber otro router con mayor prioridad en el grupo que no sea master. Obviamente se puede deshabilitar esta característica conno vrrp  preemptY por último comentar que VRRP no dispone de tracking, esa característica tan útil de HSRP y aquí tenemos que apoyarnos en otras posibildiades. Pero lo más importante es que VRRP es un protocolo abierto, así que podemos utilizarlo en cualquier equipo, sea Cisco o no, por ejemplo en Mikrotik podemos crear interfaces VRRP y configurar a partir de ahí. GLBP – Gateway Load Balancing Protocol Este es un protocolo propietario de Cisco, como HSRP, pero tiene algo que le hace único del todo y por eso lo comento aquí, aunque su uso esté limitado únicamente a equipos Cisco. GLBP permite añadir balanceo sin tener que crear varios grupos, algo que en HSRP o en VRRP solucionamos creando varios grupos, que está bien, pero no deja de ser una maniobra un poco extraña. GLBP soluciona el balanceo respondiendo a los clientes con MACs diferentes, de forma que cuando los equipos instalan en su tabla de ARP la IP del gateway, pero la MAC que le toque, así cuando envíen el tráfico lo van a hacer a la MAC que GLBP le haya asignado.

<h3>HSRP – Host Standby Routing Protocol</h3> Lo primero que hay que decir de HSRP es que es un protocolo propietario de Cisco, así que si vuestros routers o switches no son Cisco, os podéis saltar este protocolo porque sólo funcionará en Cisco. HSRP que viene definido en la RFC 2281 (<a href="https://www.ietf.org/rfc/rfc2281.txt" rel="noopener noreferrer nofollow" target="_blank">https://www.ietf.org/rfc/rfc2281.txt</a>) funciona asignando los routers a un grupo de redundancia, un grupo HSRP, y seleccionando un router como primario o activo, otro como secundario o standby y todos los demás quedarán en estado listen. Es decir, podemos tener un grupo con 10 equipos, pero sólo habrá cada vez uno activo y otro en standby, el resto se quedarán escuando, no participarán en la redundancia. El router activo será el que tenga una IP flotante o virtual que será el gateway, esa IP la definiremos en todos los routers del grupo, pero solo estará activa en el router activo. Los routers elegirán el activo y el standby basandose en prioridades y se comunicarán entre sí utilizando el puerto 1985 sobre UDP en la dirección de Multicast 224.0.0.2. Tened en cuenta que el número de grupos de HSRP que se permiten dependen del equipo, hay equipos que soportan los 255 que permiten los 8 bits de identificación de grupo HSRP y otros equipos solo permiten 16 grupos, esto tendréis que mirarlo en la documentación de cada equipo concreto. ¿Cómo se eligen los routers principales en cada grupo de HSRP? Se eligen gracias a la prioridad que definimos con el comandostandby priority En este comando hemso definido la prioridad y claro, como es una prioridad el que tenga la prioridad más alta será el elegido como primario y el siguiente como standby, si no definimos la prioridad esta se tomará en función de la IP del interfaz. El router activo será el gateway HSRP tiene unos estados por los que van pasando los routers para cada grupo, son unos estados que recuerdan de alguna manera a los de STP: <ul> <li>Disabled – Desactivado</li> <li>Init – Se inicia</li> <li>Listen – Escuchamos</li> <li>Speak – HablamosStandby – Identifica que el interfaz es el del router standby</li> <li>Active – Identifica que el interfaz es el del router activo</li> </ul> Además los routers tienen que saber si en algún momento se ha caído el activo y por tanto la IP debe de pasar al router de standby y hay que volver a seleccionar el activo y el standby de nuevo. Para saber si el router activo ha caído utizaremos mensajes de hello que por defecto se envían cada 3 segundos y en el momento de pasar el temporizador de holdtime, que por defecto son 3 hellos, se produce el cambio de standby por activo. Por supuesto estos temporizadores son modificables y se pueden ajustar a nuestras necesidades, pero es muy importante tener en cuenta que los temporizadores deben ser los mismos en todos los routers del mismo grupo, muy importante. Hay que tener en cuenta que si tenemos un router con más prioridad porque queremos que sea el activo, si esta cae el activo será el router de standby, pero una vez que se recupere el router principal no volverá a ser router activo, es decir, puede haber routers con mayor prioridad en la red que no sean el router activo, para solucionar esto existe el preemtion, es decir, tenemos que añadir a la configuración la palabra preemptstandby preempt Además HSRP tiene una característica que es muy chula, es el tracking. El tracking lo que hace es mirar el estado de otros interfaces para conmutar, esto permite que podamos bajar la prioridad de un router en el momento el que caiga otro interfaz, y nos va a permitir mejorar muchísimo la red. Por ejemplo, si tenemos dos routers con dos salidas a internet y un grupo HSRP en la LAN, si se cae un interfaz WAN en algún router podríamos con tracking hacer que la prioridad del HSRP de ese router en la LAN bajara de forma que el tráfico empezaría a salir por el router que tiene la conexión WAN activa. Por supuesto podemos habilitar autenticación entre los miembros del grupo HSRP con una contraseña, clave, hash, etc. por seguridad. Y ¿cómo ofrecemos el balanceo? Realmente para ofrecer un balanceo con HSRP lo que hacemos es definir dos grupos y ofrecer a la mitad de la red un gateway y otro a la otra mitad de la red, de forma que si fallara algún grupo todo el tráfico iría por el mismo router, pero mientras la mitad de la red iría por un router y la otra mitad por el otro router. Esto obviamente no es una característica de HSRP, sino una de las posibilidades que tenemos. <h3>VRRP – Virtual Router Redundancy Protocol</h3> VRRP a diferencia de HSRP es un protocolo abierto que puede utilizar cualquier fabricante de equipos, de hecho, es el protocolo estándar en todos los equipos no cisco. VRRP viene definido en la RFC 2338 (<a href="https://www.ietf.org/rfc/rfc2338.txt" rel="noopener noreferrer nofollow" target="_blank">https://www.ietf.org/rfc/rfc2338.txt</a>) y al y como os contaré en un momento es un protocolo extremadamente similar a HSRP, de hecho es perfectamente sustituible en la inmensa mayoría de los casos. VRRP nos ofrece una IP flotante virtual como gateway que va a estar siempre en el router master, lo que en HSRP se conoce como activo, el resto de routers serán backup, todos ellos, recordad que en HSRP sólo tenemos un router standby y aquí lo son todos excepto el master que es el que tiene la mayor prioridad. Una diferencia está en los mensajes hello, que en HSRP se enviaban por defecto cada 3 segundos y en VRRP cada segundo. Pero la diferencia fundamental de VRRP con HSRP estriba en que VRRP por defecto hay preemption, con lo que nos asegurammos que nunca va a haber otro router con mayor prioridad en el grupo que no sea master. Obviamente se puede deshabilitar esta característica conno vrrp preempt Y por último comentar que VRRP no dispone de tracking, esa característica tan útil de HSRP y aquí tenemos que apoyarnos en otras posibildiades. Pero lo más importante es que VRRP es un protocolo abierto, así que podemos utilizarlo en cualquier equipo, sea Cisco o no, por ejemplo en Mikrotik podemos crear interfaces VRRP y configurar a partir de ahí. <h3>GLBP – Gateway Load Balancing Protocol</h3> Este es un protocolo propietario de Cisco, como HSRP, pero tiene algo que le hace único del todo y por eso lo comento aquí, aunque su uso esté limitado únicamente a equipos Cisco. GLBP permite añadir balanceo sin tener que crear varios grupos, algo que en HSRP o en VRRP solucionamos creando varios grupos, que está bien, pero no deja de ser una maniobra un poco extraña. GLBP soluciona el balanceo respondiendo a los clientes con MACs diferentes, de forma que cuando los equipos instalan en su tabla de ARP la IP del gateway, pero la MAC que le toque, así cuando envíen el tráfico lo van a hacer a la MAC que GLBP le haya asignado.

HSRP, VRRP y GLBP

Lo primero es instalar Open VSwitch $ sudo apt-get install openvswitch-switch Ahora procedemos a crear el bridge llamado mibridge ovs-vsctl add-br mibridge Ahora añadirmos el puerto eth0 al bridge recien creado ovs-vsctl add-port mibridge eth0 Con el siguiente4 comando podemos ver los bridges definidos y los interfaces root@Andromeda:~# ovs-vsctl show 474995f2-4f81-4e85-8aad-7b2312dbf2d2 Bridge «bridge1» Port «bridge1» Interface «bridge1» type: internal Port «vport1» Interface «vport1» Port «vport2» Interface «vport2» Port «enp0s25» Interface «enp0s25» ovs_version: «2.9.0» Pero además de añadir interfaces físicos es interesante poder crear interfaces virtuales, ethernet virtuales, que son las llamadas tap. Después es muy importante acordarse de levantar el interfaz y de agregar al bridge si es que hace falta. ip tuntap add mode tap vport1 ifconfig vport1 up ovs-vsctl add-port mibridge vport1 Es muy interesante poder ver la tabla de ARP de un switch para poder ver en qué puerto está pinchada una máquina y cosas así, como en un switch normal. root@Andromeda:~# ovs-appctl fdb/show mibridge port VLAN MAC Age 3 0 48:2c:a0:6e:31:a4 192 3 0 b0:fc:0d:80:1f:a5 105 3 0 50:dc:e7:c9:62:8e 104 3 0 84:d6:d0:52:6f:9a 93 3 0 6c:ad:f8:95:65:ea 27 3 0 c8:02:10:b3:4c:a1 16 3 0 bc:ee:7b:a4:10:c5 8 3 0 00:90:a9:35:69:b0 7 3 0 d4:ca:6d:29:7d:8b 5 3 0 18:f0:e4:10:9b:f4 2 LOCAL 0 00:21:9b:29:27:89 1 1 0 08:00:27:b5:2d:19 1 3 0 94:6a:b0:9e:51:6b 1 Ahora, si queréis tener estadísticas de vuestro bridge podéis hacerlo con este comando root@Andromeda:~# ovs-ofctl show mibridge OFPT_FEATURES_REPLY (xid=0x2): dpid:000000219b292789 n_tables:254, n_buffers:0 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst 1(vport1): addr:6e:43:46:0e:a1:29 config: 0 state: 0 current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max 2(vport2): addr:4e:71:3b:6a:4f:f8 config: 0 state: LINK_DOWN current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max 3(enp0s25): addr:00:21:9b:29:27:89 config: 0 state: 0 current: 1GB-FD COPPER AUTO_NEG advertised: 1GB-FD COPPER AUTO_NEG supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG speed: 1000 Mbps now, 1000 Mbps max LOCAL(bridge1): addr:00:21:9b:29:27:89 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0 Si lo que queréis son los contadores de paquetes root@Andromeda:~# ovs-ofctl dump-flows bridge1 cookie=0x0, duration=3210.761s, table=0, n_packets=102142, n_bytes=169953833, priority=0 actions=NORMAL Y otras opciones, ya mucho más completas por interfaces o por puertos ovs-vsctl: unknown table «Interfaces» root@Andromeda:~# ovs-vsctl list Interface _uuid : 243ce6dc-6b25-4b40-aa27-61659344b9ad admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : full error : [] external_ids : {} ifindex : 9 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 0 link_speed : 10000000 link_state : down lldp : {} mac : [] mac_in_use : «4e:71:3b:6a:4f:f8» mtu : 1500 mtu_request : [] name : «vport2″ ofport : 2 ofport_request : [] options : {} other_config : {} statistics : {collisions=0, rx_bytes=0, rx_crc_err=0, rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0, tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0} status : {driver_name=tun, driver_version=»1.6″, firmware_version=»»} type : «» _uuid : bd68148c-2596-4e00-8f20-4f7f76bdb56f admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : [] error : [] external_ids : {} ifindex : 7 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 1 link_speed : [] link_state : up lldp : {} mac : [] mac_in_use : «00:21:9b:29:27:89» mtu : 1500 mtu_request : [] name : «bridge1» ofport : 65534 ofport_request : [] options : {} other_config : {} statistics : {collisions=0, rx_bytes=163684665, rx_crc_err=0, rx_dropped=1000, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=65116, tx_bytes=5036937, tx_dropped=0, tx_errors=0, tx_packets=34408} status : {driver_name=openvswitch} type : internal _uuid : 955db9a1-4e58-4f32-af10-341e36759659 admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : full error : [] external_ids : {} ifindex : 2 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 4 link_speed : 1000000000 link_state : up lldp : {} mac : [] mac_in_use : «00:21:9b:29:27:89» mtu : 1500 mtu_request : [] name : «enp0s25″ ofport : 3 ofport_request : [] options : {} other_config : {} statistics : {collisions=0, rx_bytes=228252521, rx_crc_err=0, rx_dropped=30, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=202028, tx_bytes=7966009, tx_dropped=0, tx_errors=0, tx_packets=54941} status : {driver_name=»e1000e», driver_version=»3.2.6-k», firmware_version=»1.8-5″} type : «» _uuid : c218f106-7568-43f9-94f9-afa2966be51d admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : full error : [] external_ids : {} ifindex : 8 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 1 link_speed : 10000000 link_state : up lldp : {} mac : [] mac_in_use : «6e:43:46:0e:a1:29» mtu : 1500 mtu_request : [] name : «vport1″ ofport : 1 ofport_request : [] options : {} other_config : {} statistics : {collisions=0, rx_bytes=0, rx_crc_err=0, rx_dropped=998, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0, tx_bytes=0, tx_dropped=8504, tx_errors=0, tx_packets=0} status : {driver_name=tun, driver_version=»1.6″, firmware_version=»»} type : «»   root@Andromeda:~# ovs-vsctl list Ports ovs-vsctl: unknown table «Ports» root@Andromeda:~# ovs-vsctl list Port _uuid : 684948f8-b3f0-42c7-87a5-47c3db0d6e85 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [243ce6dc-6b25-4b40-aa27-61659344b9ad] lacp : [] mac : [] name : «vport2» other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : 6d612854-c1cd-4626-8f6c-ce21ebc06b50 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [955db9a1-4e58-4f32-af10-341e36759659] lacp : [] mac : [] name : «enp0s25» other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : 3260eede-11cd-465b-b584-6526b36fa230 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [c218f106-7568-43f9-94f9-afa2966be51d] lacp : [] mac : [] name : «vport1» other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : 1ba138e3-3b7f-4cff-be0e-37bdd7ccbd89 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [bd68148c-2596-4e00-8f20-4f7f76bdb56f] lacp : [] mac : [] name : «bridge1» other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : []    

Lo primero es instalar Open VSwitch <blockquote>$ sudo apt-get install openvswitch-switch</blockquote> Ahora procedemos a crear el bridge llamado mibridge <blockquote>ovs-vsctl add-br mibridge</blockquote> Ahora añadirmos el puerto eth0 al bridge recien creado <blockquote>ovs-vsctl add-port mibridge eth0</blockquote> Con el siguiente4 comando podemos ver los bridges definidos y los interfaces <blockquote>root@Andromeda:~# ovs-vsctl show 474995f2-4f81-4e85-8aad-7b2312dbf2d2 Bridge «bridge1» Port «bridge1» Interface «bridge1» type: internal Port «vport1» Interface «vport1» Port «vport2» Interface «vport2» Port «enp0s25» Interface «enp0s25» ovs_version: «2.9.0»</blockquote> Pero además de añadir interfaces físicos es interesante poder crear interfaces virtuales, ethernet virtuales, que son las llamadas tap. Después es muy importante acordarse de levantar el interfaz y de agregar al bridge si es que hace falta. <blockquote>ip tuntap add mode tap vport1 ifconfig vport1 up ovs-vsctl add-port mibridge vport1</blockquote> Es muy interesante poder ver la tabla de ARP de un switch para poder ver en qué puerto está pinchada una máquina y cosas así, como en un switch normal. <blockquote>root@Andromeda:~# ovs-appctl fdb/show mibridge port VLAN MAC Age 3 0 48:2c:a0:6e:31:a4 192 3 0 b0:fc:0d:80:1f:a5 105 3 0 50:dc:e7:c9:62:8e 104 3 0 84:d6:d0:52:6f:9a 93 3 0 6c:ad:f8:95:65:ea 27 3 0 c8:02:10:b3:4c:a1 16 3 0 bc:ee:7b:a4:10:c5 8 3 0 00:90:a9:35:69:b0 7 3 0 d4:ca:6d:29:7d:8b 5 3 0 18:f0:e4:10:9b:f4 2 LOCAL 0 00:21:9b:29:27:89 1 1 0 08:00:27:b5:2d:19 1 3 0 94:6a:b0:9e:51:6b 1</blockquote> Ahora, si queréis tener estadísticas de vuestro bridge podéis hacerlo con este comando <blockquote>root@Andromeda:~# ovs-ofctl show mibridge OFPT_FEATURES_REPLY (xid=0x2): dpid:000000219b292789 n_tables:254, n_buffers:0 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst 1(vport1): addr:6e:43:46:0e:a1:29 config: 0 state: 0 current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max 2(vport2): addr:4e:71:3b:6a:4f:f8 config: 0 state: LINK_DOWN current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max 3(enp0s25): addr:00:21:9b:29:27:89 config: 0 state: 0 current: 1GB-FD COPPER AUTO_NEG advertised: 1GB-FD COPPER AUTO_NEG supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG speed: 1000 Mbps now, 1000 Mbps max LOCAL(bridge1): addr:00:21:9b:29:27:89 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0</blockquote> Si lo que queréis son los contadores de paquetes <blockquote>root@Andromeda:~# ovs-ofctl dump-flows bridge1 cookie=0x0, duration=3210.761s, table=0, n_packets=102142, n_bytes=169953833, priority=0 actions=NORMAL</blockquote> Y otras opciones, ya mucho más completas por interfaces o por puertos <blockquote>ovs-vsctl: unknown table «Interfaces» root@Andromeda:~# ovs-vsctl list Interface _uuid : 243ce6dc-6b25-4b40-aa27-61659344b9ad admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : full error : [] external_ids : {} ifindex : 9 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 0 link_speed : 10000000 link_state : down lldp : {} mac : [] mac_in_use : «4e:71:3b:6a:4f:f8» mtu : 1500 mtu_request : [] name : «vport2″ ofport : 2 ofport_request : [] options : {} other_config : {} statistics : {collisions=0, rx_bytes=0, rx_crc_err=0, rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0, tx_bytes=0, tx_dropped=0, tx_errors=0, tx_packets=0} status : {driver_name=tun, driver_version=»1.6″, firmware_version=»»} type : «» _uuid : bd68148c-2596-4e00-8f20-4f7f76bdb56f admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : [] error : [] external_ids : {} ifindex : 7 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 1 link_speed : [] link_state : up lldp : {} mac : [] mac_in_use : «00:21:9b:29:27:89» mtu : 1500 mtu_request : [] name : «bridge1» ofport : 65534 ofport_request : [] options : {} other_config : {} statistics : {collisions=0, rx_bytes=163684665, rx_crc_err=0, rx_dropped=1000, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=65116, tx_bytes=5036937, tx_dropped=0, tx_errors=0, tx_packets=34408} status : {driver_name=openvswitch} type : internal _uuid : 955db9a1-4e58-4f32-af10-341e36759659 admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : full error : [] external_ids : {} ifindex : 2 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 4 link_speed : 1000000000 link_state : up lldp : {} mac : [] mac_in_use : «00:21:9b:29:27:89» mtu : 1500 mtu_request : [] name : «enp0s25″ ofport : 3 ofport_request : [] options : {} other_config : {} statistics : {collisions=0, rx_bytes=228252521, rx_crc_err=0, rx_dropped=30, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=202028, tx_bytes=7966009, tx_dropped=0, tx_errors=0, tx_packets=54941} status : {driver_name=»e1000e», driver_version=»3.2.6-k», firmware_version=»1.8-5″} type : «» _uuid : c218f106-7568-43f9-94f9-afa2966be51d admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : full error : [] external_ids : {} ifindex : 8 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 1 link_speed : 10000000 link_state : up lldp : {} mac : [] mac_in_use : «6e:43:46:0e:a1:29» mtu : 1500 mtu_request : [] name : «vport1″ ofport : 1 ofport_request : [] options : {} other_config : {} statistics : {collisions=0, rx_bytes=0, rx_crc_err=0, rx_dropped=998, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0, tx_bytes=0, tx_dropped=8504, tx_errors=0, tx_packets=0} status : {driver_name=tun, driver_version=»1.6″, firmware_version=»»} type : «» root@Andromeda:~# ovs-vsctl list Ports ovs-vsctl: unknown table «Ports» root@Andromeda:~# ovs-vsctl list Port _uuid : 684948f8-b3f0-42c7-87a5-47c3db0d6e85 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [243ce6dc-6b25-4b40-aa27-61659344b9ad] lacp : [] mac : [] name : «vport2» other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : 6d612854-c1cd-4626-8f6c-ce21ebc06b50 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [955db9a1-4e58-4f32-af10-341e36759659] lacp : [] mac : [] name : «enp0s25» other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : 3260eede-11cd-465b-b584-6526b36fa230 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [c218f106-7568-43f9-94f9-afa2966be51d] lacp : [] mac : [] name : «vport1» other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : [] _uuid : 1ba138e3-3b7f-4cff-be0e-37bdd7ccbd89 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [bd68148c-2596-4e00-8f20-4f7f76bdb56f] lacp : [] mac : [] name : «bridge1» other_config : {} protected : false qos : [] rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : [] trunks : [] vlan_mode : []  </blockquote>

Primeros pasos con Open vSwitch

En el blog de Tecnocrática he publicado una entrada en la que comentaba este tema: https://blog.tecnocratica.net/2020/03/05/alojar-mas-webs-con-wordpress-en-un-servidor-sin-aumentar-recursos/ En el capítulo de hoy os cuento cómo podemos reducir el uso de cpu de un servidor con muchos sitios hechos con WordPress. Para ello podemos ver aquellas webs en las que no sea necesario tener funcionando el wp-cron.php. Recordemos que el cron en WordPress se encarga entre otras cosas de: Actualizar WordPressActualizar PluginsActualizar TraduccionesActualizar TemasTareas Programadas (backups …)Publicaciones programadasetc Si tenemos webs en las que no es necesario tener constantemente un cron funcionando podemos pasar la funcionalidad al crontab del sistema operativo y en vez de estar comprobando constantemente podemos ejecutarlo una vez al día, para eso podemos usar el crontab de linux. Y el crontab de linux si usáis Neodigit recordad que lo podéis modificar desde el panel, desde el alojamiento en Opciones -&gt; Tareas de Cron En el vídeo podréis ver las imágenes que están incluidas en el audio 

En el blog de Tecnocrática he publicado una entrada en la que comentaba este tema: <a href="https://blog.tecnocratica.net/2020/03/05/alojar-mas-webs-con-wordpress-en-un-servidor-sin-aumentar-recursos/" rel="nofollow" target="_blank">https://blog.tecnocratica.net/2020/03/05/alojar-mas-webs-con-wordpress-en-un-servidor-sin-aumentar-recursos/</a> En el capítulo de hoy os cuento cómo podemos reducir el uso de cpu de un servidor con muchos sitios hechos con WordPress. Para ello podemos ver aquellas webs en las que no sea necesario tener funcionando el wp-cron.php. Recordemos que el cron en WordPress se encarga entre otras cosas de: <ul><li>Actualizar WordPress</li><li>Actualizar Plugins</li><li>Actualizar Traducciones</li><li>Actualizar Temas</li><li>Tareas Programadas (backups …)</li><li>Publicaciones programadas</li><li>etc</li></ul> Si tenemos webs en las que no es necesario tener constantemente un cron funcionando podemos pasar la funcionalidad al crontab del sistema operativo y en vez de estar comprobando constantemente podemos ejecutarlo una vez al día, para eso podemos usar el crontab de linux. Y el crontab de linux si usáis Neodigit recordad que lo podéis modificar desde el panel, desde el alojamiento en Opciones -&gt; Tareas de Cron En el vídeo podréis ver las imágenes que están incluidas en el audio

Maximizar el uso de WordPress en un servidor

En estos últimos capítulos hemos dedicado algún tiempo a algún software sobre la distribución de Linux Debian, primero hablamos de Wireguard, el fantástico servicio de VPN y luego de Nebula, un software para poder disponer de nuestra propia SDN. No se si os acordaréis pero en la instalación de Nebula teníamos que arrancar a mano tanto en el servidor como en el cliente el propio Nebula, lo cual es terrible. Seguro que os gustaría muchísimo más que al arrancar ya estuviera Nebula corriendo solito, sin tener que hacer absolutamente nada. Mi forma preferida de tener un software corriendo siempre es definirlo como servicio utilizando systemd en Debian que es la distribución que utilizo. Así que el capítulo de hoy va a ir justo de eso, de definir servicios en systemd y vamos a definir el servicio de Nebula para poder hacerlo con algo concreto. Pero antes de empezar quiero comentaros un pequeño cambio que he hecho en el podcast y que creo que puede ser muy interesante a nivel de usabilidad del contenido. A partir de este capítulo vais a poder encontrar capítulos que os van a permitir saltar a la parte del contenido que más os interese o saltaros aquello que no os interese en lo más mínimo.  Entiendo que vuestro tiempo vale mucho y no quiero obligar a nadie a navegar por el audio hasta que encuentre justo aquello que le interesa. Los marcadores no están disponibles para todos aquellos que utilicéis iVoox tanto como podcatcher o a aquellos que estén suscritos al feed de iVoox, simplemente por una limitación de la propia plataforma, así que si queréis poder utilizar los marcadores os tendréis que suscribir directamente al feed de https://www.eduardocollado.com/podcast/feed, de todos modos tenéis un enlace en la parte derecha de la web donde poner «Suscríbete al podcast«. Los podcatchers o clientes de podcast que lo soportan son muchos como Podcast Addict, Pocket Casts, Antennapod para Android u Overcast y el propio Pocket Casts para iOS, y muchos otros que no he podido ni probar o que ni se de su existencia, así que lo mejor es que miréis en vuestro podcatcher si disponéis de esta opción.  Donde seguro que no está la opción es en la app de iVoox y en cualquier app que utilice el feed de iVoox que aunque lo tengo oculto hay algo menos de 500 personas que lo usan según lo que me dice Podcast Addict. Además, el feed de iVoox sirve los audios a 64kbps mientras que en eduardocollado.com los sirvo a 128kbps y con capítulos. Ahora, el contenido es el mismo, así que si estáis contentos con iVoox seguid con la app, lo único que no podréis ir a la parte del audio que más os interese gracias a los capítulos ni podréis disfrutar de los 128kbps, aunque mi voz tampoco es que mejore enormemente al subir el bit rate. Ahora no quiero entreteneros más o vamos a charlar sobre cómo crear servicios en Debian utilizando systemd, para ello crearemos el servicio nebula. Si os interesa el tema y os queréis quedar conmigo un ratito recordad que esto es eduardocollado.com y que este es el capítulo 202, por cierto, hoy es 15 de Diciembre de 2019. El otro día realizamos una instalación de Nebula que consistía básicamente en copiar un ejecutable en Debian y a crear un pequeño fichero de configuración. El problema es que para ejecutarlo teníamos que poner en cada uno de los ordenadores que componían nuestra SDN:./nebula -config /path/to/config.yamlY dejar el terminal abierto, algo terrorífico, lo ideal sería que pudiéramos poner algo del estiloservice nebula startEso sería lo idea, que funcionase como si fuera por ejemplo un servidor Apache, e incluso mejor, nos gustaría que arrancase solo, sin tener que hacer nada, pues eso se consigue gracias a los servicios. Crear servicios en Debian no es tan complicado como mucha gente pueda pensar. Lo que tendremos que hacer es crear un fichero llamado nebula.service, ahora si me estáis escuchando mirad el móvil, crearemos el fichero en el directorio /etc/systemd/system con el siguiente contenido:[Unit]Description=nebulaWants=basic.targetAfter=basic.target network.target[Service]SyslogIdentifier=nebulaStandardOutput=syslogStandardError=syslogExecReload=/bin/kill -HUP $MAINPIDExecStart=/usr/local/bin/nebula -config /etc/nebula/config.yamlRestart=always[Install]WantedBy=multi-user.targetSi estáis utilizando un podcatcher con capítulos ahora mismo estaréis viendo en vuestra pantalla el fichero en cuestión, si es un móvil en el móvil el fichero del que os hablo. La verdad es que esto de los capítulos es una pasada y nos permite hacer cosas como esta. Los que no estéis con un podcatcher, la app de escuchar podcasts, compatible ahora estaréis viendo seguramente la portada del podcast y tendréis que ir a las notas del programa en eduardocollado.com o en el propio podcatcher para poder ver el fichero que os digo. Hay una cosa que he hecho para que quede más bonito y elegante, y es ejecutar Nebula desde /usr/local/bin, aunque el software realmente lo tenga en /etc/nebula, para ello simplemente un enlace simbólico:ln -s /etc/nebula/nebula /usr/local/bin/nebulaEs importante crear el enlace simbólico y no copiar directamente el fichero nebula porque en el momento en el que se actualice nebula, que ese día llegará, es probable que no os acordéis de actualizar la copia de /usr/local/bin. Y ahora simplemente nos quedará habilitar el servicio para que arranque a partir de ahora solo que lo haremos con:systemctl enable nebulaY arrancar el servicio por primera vezservice nebula startObviamente entiendo que antes de hacer esto habéis repasado que la configuración de nebula esté bien y lo habéis probado de la forma tradicional. Sólo comentaros que hay un error que a mi me trajo de cabeza durante un rato largo y fue que me salía el error: FATA[0000] no pki.ca path or PEM data provided Esto no era un error de nebula, como dice mi amigo Adrián no es la flecha sino el indio y este error era porque estaba tratando de ejecutar:/usr/local/bin/nebula -config /etc/nebula/config.ymlY claro estaba ejecutándolo mal porque el fichero config.yml no existe es config.yaml, así que a veces pequeños errores de typo como estos pueden hacernos perder la cabeza durante un buen rato. Hasta aquí el programa de hoy, espero que os haya servido este pequeño recordatorio de administración de Linux y que os funcione correctamente todo el tema de los capítulos en el mp3 porque creedme que es un trabajo, creo que está bien invertido y le sacamos entre todos partido. Sin más, despedirme de vosotros y nos volvemos a escuchar en el próximo capítulo. Foto de Cosmin Paduraru en Pexels

En estos últimos capítulos hemos dedicado algún tiempo a algún software sobre la distribución de Linux Debian, primero hablamos de <a href="https://www.eduardocollado.com/2019/09/28/configuracion-de-wireguard-en-debian-10/" rel="noreferrer noopener nofollow" target="_blank">Wireguard</a>, el fantástico servicio de VPN y luego de <a href="https://www.eduardocollado.com/2019/11/29/introduccion-a-nebula/" rel="noreferrer noopener nofollow" target="_blank">Nebula</a>, un software para poder disponer de nuestra propia SDN. No se si os acordaréis pero en la instalación de Nebula teníamos que arrancar a mano tanto en el servidor como en el cliente el propio Nebula, lo cual es terrible. Seguro que os gustaría muchísimo más que al arrancar ya estuviera Nebula corriendo solito, sin tener que hacer absolutamente nada. Mi forma preferida de tener un software corriendo siempre es definirlo como servicio utilizando systemd en Debian que es la distribución que utilizo. Así que el capítulo de hoy va a ir justo de eso, de definir servicios en systemd y vamos a definir el servicio de Nebula para poder hacerlo con algo concreto. Pero antes de empezar quiero comentaros un pequeño cambio que he hecho en el podcast y que creo que puede ser muy interesante a nivel de usabilidad del contenido. A partir de este capítulo vais a poder encontrar capítulos que os van a permitir saltar a la parte del contenido que más os interese o saltaros aquello que no os interese en lo más mínimo. Entiendo que vuestro tiempo vale mucho y no quiero obligar a nadie a navegar por el audio hasta que encuentre justo aquello que le interesa. Los marcadores no están disponibles para todos aquellos que utilicéis iVoox tanto como podcatcher o a aquellos que estén suscritos al feed de iVoox, simplemente por una limitación de la propia plataforma, así que si queréis poder utilizar los marcadores os tendréis que suscribir directamente al feed de <a href="https://www.eduardocollado.com/podcast/feed/" rel="noreferrer noopener nofollow" target="_blank">https://www.eduardocollado.com/podcast/feed</a>, de todos modos tenéis un enlace en la parte derecha de la web donde poner «Suscríbete al podcast«. Los podcatchers o clientes de podcast que lo soportan son muchos como Podcast Addict, Pocket Casts, Antennapod para Android u Overcast y el propio Pocket Casts para iOS, y muchos otros que no he podido ni probar o que ni se de su existencia, así que lo mejor es que miréis en vuestro podcatcher si disponéis de esta opción. Donde seguro que no está la opción es en la app de iVoox y en cualquier app que utilice el feed de iVoox que aunque lo tengo oculto hay algo menos de 500 personas que lo usan según lo que me dice Podcast Addict. Además, el feed de iVoox sirve los audios a 64kbps mientras que en <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> los sirvo a 128kbps y con capítulos. Ahora, el contenido es el mismo, así que si estáis contentos con iVoox seguid con la app, lo único que no podréis ir a la parte del audio que más os interese gracias a los capítulos ni podréis disfrutar de los 128kbps, aunque mi voz tampoco es que mejore enormemente al subir el bit rate. Ahora no quiero entreteneros más o vamos a charlar sobre cómo crear servicios en Debian utilizando systemd, para ello crearemos el servicio nebula. Si os interesa el tema y os queréis quedar conmigo un ratito recordad que esto es <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> y que este es el capítulo 202, por cierto, hoy es 15 de Diciembre de 2019. El otro día realizamos una instalación de Nebula que consistía básicamente en copiar un ejecutable en Debian y a crear un pequeño fichero de configuración. El problema es que para ejecutarlo teníamos que poner en cada uno de los ordenadores que componían nuestra SDN:./nebula -config /path/to/config.yaml Y dejar el terminal abierto, algo terrorífico, lo ideal sería que pudiéramos poner algo del estiloservice nebula start Eso sería lo idea, que funcionase como si fuera por ejemplo un servidor Apache, e incluso mejor, nos gustaría que arrancase solo, sin tener que hacer nada, pues eso se consigue gracias a los servicios. Crear servicios en Debian no es tan complicado como mucha gente pueda pensar. Lo que tendremos que hacer es crear un fichero llamado nebula.service, ahora si me estáis escuchando mirad el móvil, crearemos el fichero en el directorio /etc/systemd/system con el siguiente contenido:[Unit] Description=nebula Wants=basic.target After=basic.target network.target [Service] SyslogIdentifier=nebula StandardOutput=syslog StandardError=syslog ExecReload=/bin/kill -HUP $MAINPID ExecStart=/usr/local/bin/nebula -config /etc/nebula/config.yaml Restart=always [Install] WantedBy=multi-user.target Si estáis utilizando un podcatcher con capítulos ahora mismo estaréis viendo en vuestra pantalla el fichero en cuestión, si es un móvil en el móvil el fichero del que os hablo. La verdad es que esto de los capítulos es una pasada y nos permite hacer cosas como esta. Los que no estéis con un podcatcher, la app de escuchar podcasts, compatible ahora estaréis viendo seguramente la portada del podcast y tendréis que ir a las notas del programa en <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> o en el propio podcatcher para poder ver el fichero que os digo. Hay una cosa que he hecho para que quede más bonito y elegante, y es ejecutar Nebula desde /usr/local/bin, aunque el software realmente lo tenga en /etc/nebula, para ello simplemente un enlace simbólico:ln -s /etc/nebula/nebula /usr/local/bin/nebula Es importante crear el enlace simbólico y no copiar directamente el fichero nebula porque en el momento en el que se actualice nebula, que ese día llegará, es probable que no os acordéis de actualizar la copia de /usr/local/bin. Y ahora simplemente nos quedará habilitar el servicio para que arranque a partir de ahora solo que lo haremos con:systemctl enable nebula Y arrancar el servicio por primera vezservice nebula start Obviamente entiendo que antes de hacer esto habéis repasado que la configuración de nebula esté bien y lo habéis probado de la forma tradicional. Sólo comentaros que hay un error que a mi me trajo de cabeza durante un rato largo y fue que me salía el error: FATA[0000] no <a href="http://pki.ca" rel="nofollow" target="_blank">pki.ca</a> path or PEM data provided Esto no era un error de nebula, como dice mi amigo Adrián no es la flecha sino el indio y este error era porque estaba tratando de ejecutar:/usr/local/bin/nebula -config /etc/nebula/config.yml Y claro estaba ejecutándolo mal porque el fichero config.yml no existe es config.yaml, así que a veces pequeños errores de typo como estos pueden hacernos perder la cabeza durante un buen rato. Hasta aquí el programa de hoy, espero que os haya servido este pequeño recordatorio de administración de Linux y que os funcione correctamente todo el tema de los capítulos en el mp3 porque creedme que es un trabajo, creo que está bien invertido y le sacamos entre todos partido. Sin más, despedirme de vosotros y nos volvemos a escuchar en el próximo capítulo. Foto de <a href="https://www.pexels.com/es-es/@padurarul?utm_content=attributionCopyText&amp;utm_medium=referral&amp;utm_source=pexels" rel="noreferrer noopener nofollow" target="_blank">Cosmin Paduraru</a> en <a href="https://www.pexels.com/es-es/foto/abstracto-acero-adentro-antiguo-340981/?utm_content=attributionCopyText&amp;utm_medium=referral&amp;utm_source=pexels" rel="noreferrer noopener nofollow" target="_blank">Pexels</a>

Arrancar un software como servicio en Debian

Antes de meternos a explicar qué es DNSSec es necesario que os hable de alguna cosa antes. La zona raíz, aquí estamos hablando de los root servers de los que hablamos hace tan sólo unos días en el Podcast #187: Root Servers. También tenemos que saber que la zona raíz tenemos que firmarla, esto seguro que ya los sabéis también porque en el capítulo Podcast #175: Traspaso de la KSK en la Zona Raíz con João Damas estuvimos hablando justamente de eso, aunque hoy hablaremos un poquito más sobre el tema. Realmente si recordáis el podcast del traspaso de la KSK, la sigla KSK corresponde a clave de firma de clave y la sigla ZSK corresponde a clave de firma de zona. Otro concepto a tener en cuenta es que tenemos que generar un DS (Delegation signer) que lo que contiene es un hash de la clave pública con la que hay que verificar las respuestas de esa zona. Además en DNSSec tendremos unos registros extras que vendrán acompañando a cualquier consulta llamados RRSIG (Resource Record SIGnature) que contienen la firma digital del registro que se solicitó y que tienen que ser regenerados de vez en cuando. El registro RRSIG se valida con la clave pública del dominio en cuestión, que puede ser validada por ser un registro DS en la zona superior, el cual a su vez está firmado. Como nota es interesante saber que para ir regenerando los RRSIG es necesario disponer de una KSK Y una ZSK, la KSK se utilizará para firmar la ZSK y la ZSK se utilizará para firmar el resto. Ojo que en PowerDNS en vez de KSK y ZSK tenemos sólo CSK, eso sí, un CSK por dominio. Y por último tenemos que conocer que el registro DNSKEY (clave pública) necesario para poder validar las siguientes respuestas. De momento la cosa parece un poco críptica, así que vamos a tratar de explicar esto despacito. Lo primero es habilitar DNSSec en nuestros dominios, ya que si no lo hacemos esto esto carece de sentido. Para poder habilitar DNSSec en un dominio necesitamos dos cosas:  El registrador del dominio pueda poder aceptar los registros DS (Delegation Signature) y poder enviarlos a un dominio de nivel superior (TLD), como .com, .org o .net. El proveedor de hosting de DNS que opera los servidores DNS para el dominio sea compatible con DNSSEC y tiene que poder firmar sus archivos de zona DNS.  Configuración de DNSSec en Neodigit. Una vez tenemos habilitado el DNSSec vamos a ver cómo funciona:  Pedimos a los root servers la lista de servidores que sirven el dominio de primer nivel, en mi caso .com. Estamos pidiendo los registros NS. Esto vendrá acompañado de un RRSIG para validarlos y solicitaremos el DS del dominio de primer nivel, el cual vendrá con su RRSIG para validar. Nuestro servidor DNS valida que los registros NS y DS son correctos gracias a la clave que tenemos descargada que el RRSIG sea valido. Estamos validando el root. (/etc/bind/bind.keys en Bind) Ahora le pedimos al servidor DNS del siguiente nivel (.com) su clave pública (DNSKEY) que validamos con el DS generando el hash al DNSKEY. En este punto pedimos los DNS (NS) del dominio de segundo nivel, por ejemplo eduardocollado.com y nos va a enviar los NS, con su DS y los RRSIG correspondientes. Y hacemos lo mismo con los servidores DNSs del dominio.  Ahora tenemos el tema de la rotación de llaves, el rolling keys, algo que es complicado porque si generamos una nueva llave es necesario cambiar el DS del dominio en el nivel inferior y eso requiere una acción manual del usuario, así que es algo realmente complejo. Hay alternativas por lo que he podido entender de lo que mi compañero Adrian Almenar me ha estado explicando, voy a ver si soy capaz de contároslo. Tenemos dos opciones, utilizando un registro CDSNKEY y por otro lado utilizando registros DS o CDS. El CDSNKEY será el contenido de la llave para generar el DS, mientras que los registros DS o CDS serían directamente el DS, con la única diferencia que DS es sha-1 y CDS es sha-2, pero se trata de lo mismo. La idea es que el registrador superior reciba el DS sin una intervención directa, es interesante cuando hay que generar una nueva llave, porque automatizaría el proceso, pero claro, el problema que yo le veo es que eso sólo se podría hacer a partir de la segunda llave, y no veo que la primera vez se pudiera usar esta forma de trabajar. De momento parece ser que el .CZ sí que lo permite, pero ninguno más, así que esto es algo más a futuro que otras cosas. Aquí os dejo un ejemplo con el dominio eduardocollado.comedu@Andromeda ~ # dig +dnssec ns com @l.root-servers.net; &lt;&lt;&gt;&gt; DiG 9.13.7 &lt;&lt;&gt;&gt; +dnssec ns com @l.root-servers.net;; global options: +cmd;; Got answer:;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 22834;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 27;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:; EDNS: version: 0, flags: do; udp: 4096;; QUESTION SECTION:;com.				IN	NS;; AUTHORITY SECTION:com.			172800	IN	NS	a.gtld-servers.net.com.			172800	IN	NS	b.gtld-servers.net.com.			172800	IN	NS	c.gtld-servers.net.com.			172800	IN	NS	d.gtld-servers.net.com.			172800	IN	NS	e.gtld-servers.net.com.			172800	IN	NS	f.gtld-servers.net.com.			172800	IN	NS	g.gtld-servers.net.com.			172800	IN	NS	h.gtld-servers.net.com.			172800	IN	NS	i.gtld-servers.net.com.			172800	IN	NS	j.gtld-servers.net.com.			172800	IN	NS	k.gtld-servers.net.com.			172800	IN	NS	l.gtld-servers.netcom.			172800	IN	NS	m.gtld-servers.net.com.			86400	IN	DS	30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766com.			86400	IN	RRSIG	DS 8 1 86400 20190310170000 20190225160000 16749 . N9g+eeSjBKK+bOPW8IA/JGGQgTVrdZ12fIFS+8ggHLVW3LGQI6YTmpef +O+dbqeaFOnYcGBlRcc7HD9bVIy+ygImoMnKos98hx9YfPR+XK2HUBWM oZTT3yr27eL0hKxby4srlECX1B51gwuuYQQYpL8FI2Gl4v0eB0pMZWZ1 A0FUNWZA20lZ7HrBQ9OLnWCGkMgKkXqTvhcd0dhr0e3cVKmhC2m+de4X FlVm1zSjnmtEv6kT2n8YxnOsdNMs8VFa94MsjLr2OvT/HfbDmIiyEPEz 0U8K9oeFhVR2wczDydOiMpZ4l29aPMcZ7qQLaWGpOxHgTYiODlFD/qBY 00lq1w==;; ADDITIONAL SECTION:a.gtld-servers.net.	172800	IN	A	192.5.6.30b.gtld-servers.net.	172800	IN	A	192.33.14.30c.gtld-servers.net.	172800	IN	A	192.26.92.30d.gtld-servers.net.	172800	IN	A	192.31.80.30e.gtld-servers.net.	172800	IN	A	192.12.94.30f.gtld-servers.net.	172800	IN	A	192.35.51.30g.gtld-servers.net.	172800	IN	A	192.42.93.30h.gtld-servers.net.	172800	IN	A	192.54.112.30i.gtld-servers.net.	172800	IN	A	192.43.172.30j.gtld-servers.net.	172800	IN	A	192.48.79.30k.gtld-servers.net.	172800	IN	A	192.52.178.30l.gtld-servers.net.	172800	IN	A	192.41.162.30m.gtld-servers.net.	172800	IN	A	192.55.83.30a.gtld-servers.net.	172800	IN	AAAA	2001:503:a83e::2:30b.gtld-servers.net.	172800	IN	AAAA	2001:503:231d::2:30c.gtld-servers.net.	172800	IN	AAAA	2001:503:83eb::30d.gtld-servers.net.	172800	IN	AAAA	2001:500:856e::30e.gtld-servers.net.	172800	IN	AAAA	2001:502:1ca1::30f.gtld-servers.net.	172800	IN	AAAA	2001:503:d414::30g.gtld-servers.net.	172800	IN	AAAA	2001:503:eea3::30h.gtld-servers.net.	172800	IN	AAAA	2001:502:8cc::30i.gtld-servers.net.	172800	IN	AAAA	2001:503:39c1::30j.gtld-servers.net.	172800	IN	AAAA	2001:502:7094::30k.gtld-servers.net.	172800	IN	AAAA	2001:503:d2d::30l.gtld-servers.net.	172800	IN	AAAA	2001:500:d937::30m.gtld-servers.net.	172800	IN	AAAA	2001:501:b1f9::30;; Query time: 37 msec;; SERVER: 199.7.83.42#53(199.7.83.42);; WHEN: lun feb 25 19:26:28 CET 2019;; MSG SIZE  rcvd: 1163edu@Andromeda ~ # dig +dnssec ns eduardocollado.com @e.gtld-servers.net; &lt;&lt;&gt;&gt; DiG 9.13.7 &lt;&lt;&gt;&gt; +dnssec ns eduardocollado.com @e.gtld-servers.net;; global options: +cmd;; Got answer:;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 40192;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:; EDNS: version: 0, flags: do; udp: 4096;; QUESTION SECTION:;eduardocollado.com.		IN	NS;; AUTHORITY SECTION:eduardocollado.com.	172800	IN	NS	ns1.neodigit.net.eduardocollado.com.	172800	IN	NS	ns2.neodigit.net.eduardocollado.com.	86400	IN	DS	38890 13 1 38BF99A8BB8A4D3FA8D66A65964014099C2D34E9eduardocollado.com.	86400	IN	RRSIG	DS 8 2 86400 20190304054735 20190225043735 16883 com. tPJ2JQf9590P2yOZ3WroyEwqh1Aa+WsiYdV8BS/vqFKeqXsS2nPxPOl1 ijWLq90pUYyBUE7hBD3ZDsqPoguo4YeWKxqNbc87BbqhXudMpdjHC+Wl Gd9XbBHOtcu7qKff1gTsU/lxVg9cQ14Uzqbu/V56zOlPexua/66FUgmr G4g=;; Query time: 42 msec;; SERVER: 192.12.94.30#53(192.12.94.30);; WHEN: lun feb 25 19:26:52 CET 2019;; MSG SIZE  rcvd: 294edu@Andromeda ~ # dig +dnssec eduardocollado.com @ns1.neodigit.net; &lt;&lt;&gt;&gt; DiG 9.13.7 &lt;&lt;&gt;&gt; +dnssec eduardocollado.com @ns1.neodigit.net;; global options: +cmd;; Got answer:;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 51436;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:; EDNS: version: 0, flags: do; udp: 4096;; QUESTION SECTION:;eduardocollado.com.		IN	A;; ANSWER SECTION:eduardocollado.com.	7200	IN	RRSIG	A 13 2 7200 20190307000000 20190214000000 38890 eduardocollado.com. FHBRqGzga6FVCfNar88YM7xhh1cTZQd2YpM5ZIF9/BM49M96qrZ4D+wP nh1lxBpEhyG/ptHMqF2FwSE6OJ12Xg==eduardocollado.com.	7200	IN	A	31.47.74.50;; Query time: 7 msec;; SERVER: 31.47.72.140#53(31.47.72.140);; WHEN: lun feb 25 19:27:37 CET 2019;; MSG SIZE  rcvd: 177edu@Andromeda ~ #Como veis el sistema de DNSSec es una relación de confianza de zonas padres e hijas utilizando criptografía asimétrica, es decir, con el uso de claves privadas y claves públicas.  Obviamente DNSSec no soluciona todos los problemas de seguridad en Internet, pero ayuda mucho ya que hacemos que las respuestas de los DNSs unas sean dependientes de los niveles superiores, una especie de blockchain ahora que está tan de moda esa palabra.

Antes de meternos a explicar qué es DNSSec es necesario que os hable de alguna cosa antes. La zona raíz, aquí estamos hablando de los root servers de los que hablamos hace tan sólo unos días en el <a href="https://www.eduardocollado.com/2019/02/21/podcast-187-root-servers/" rel="noopener noreferrer nofollow" target="_blank">Podcast #187: Root Servers</a>. También tenemos que saber que la zona raíz tenemos que firmarla, esto seguro que ya los sabéis también porque en el capítulo <a href="https://www.eduardocollado.com/2018/09/19/podcast-175-traspaso-de-la-ksk-en-la-zona-raiz-con-joao-damas/" rel="noopener noreferrer nofollow" target="_blank">Podcast #175: Traspaso de la KSK en la Zona Raíz con João Damas</a> estuvimos hablando justamente de eso, aunque hoy hablaremos un poquito más sobre el tema. Realmente si recordáis el podcast del traspaso de la KSK, la sigla KSK corresponde a clave de firma de clave y la sigla ZSK corresponde a clave de firma de zona. Otro concepto a tener en cuenta es que tenemos que generar un DS (Delegation signer) que lo que contiene es un hash de la clave pública con la que hay que verificar las respuestas de esa zona. Además en DNSSec tendremos unos registros extras que vendrán acompañando a cualquier consulta llamados RRSIG (Resource Record SIGnature) que contienen la firma digital del registro que se solicitó y que tienen que ser regenerados de vez en cuando. El registro RRSIG se valida con la clave pública del dominio en cuestión, que puede ser validada por ser un registro DS en la zona superior, el cual a su vez está firmado. Como nota es interesante saber que para ir regenerando los RRSIG es necesario disponer de una KSK Y una ZSK, la KSK se utilizará para firmar la ZSK y la ZSK se utilizará para firmar el resto. Ojo que en PowerDNS en vez de KSK y ZSK tenemos sólo CSK, eso sí, un CSK por dominio. Y por último tenemos que conocer que el registro DNSKEY (clave pública) necesario para poder validar las siguientes respuestas. De momento la cosa parece un poco críptica, así que vamos a tratar de explicar esto despacito. Lo primero es habilitar DNSSec en nuestros dominios, ya que si no lo hacemos esto esto carece de sentido. Para poder habilitar DNSSec en un dominio necesitamos dos cosas: <ol> <li>El registrador del dominio pueda poder aceptar los registros DS (Delegation Signature) y poder enviarlos a un dominio de nivel superior (TLD), como .com, .org o .net.</li> <li>El proveedor de hosting de DNS que opera los servidores DNS para el dominio sea compatible con DNSSEC y tiene que poder firmar sus archivos de zona DNS.</li> </ol> Configuración de DNSSec en Neodigit. Una vez tenemos habilitado el DNSSec vamos a ver cómo funciona: <ol> <li>Pedimos a los root servers la lista de servidores que sirven el dominio de primer nivel, en mi caso .com. Estamos pidiendo los registros NS. Esto vendrá acompañado de un RRSIG para validarlos y solicitaremos el DS del dominio de primer nivel, el cual vendrá con su RRSIG para validar.</li> <li>Nuestro servidor DNS valida que los registros NS y DS son correctos gracias a la clave que tenemos descargada que el RRSIG sea valido. Estamos validando el root. (/etc/bind/bind.keys en Bind)</li> <li>Ahora le pedimos al servidor DNS del siguiente nivel (.com) su clave pública (DNSKEY) que validamos con el DS generando el hash al DNSKEY.</li> <li>En este punto pedimos los DNS (NS) del dominio de segundo nivel, por ejemplo <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> y nos va a enviar los NS, con su DS y los RRSIG correspondientes.</li> <li>Y hacemos lo mismo con los servidores DNSs del dominio.</li> </ol> Ahora tenemos el tema de la rotación de llaves, el rolling keys, algo que es complicado porque si generamos una nueva llave es necesario cambiar el DS del dominio en el nivel inferior y eso requiere una acción manual del usuario, así que es algo realmente complejo. Hay alternativas por lo que he podido entender de lo que mi compañero Adrian Almenar me ha estado explicando, voy a ver si soy capaz de contároslo. Tenemos dos opciones, utilizando un registro CDSNKEY y por otro lado utilizando registros DS o CDS. El CDSNKEY será el contenido de la llave para generar el DS, mientras que los registros DS o CDS serían directamente el DS, con la única diferencia que DS es sha-1 y CDS es sha-2, pero se trata de lo mismo. La idea es que el registrador superior reciba el DS sin una intervención directa, es interesante cuando hay que generar una nueva llave, porque automatizaría el proceso, pero claro, el problema que yo le veo es que eso sólo se podría hacer a partir de la segunda llave, y no veo que la primera vez se pudiera usar esta forma de trabajar. De momento parece ser que el .CZ sí que lo permite, pero ninguno más, así que esto es algo más a futuro que otras cosas. Aquí os dejo un ejemplo con el dominio <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>edu@Andromeda ~ # dig +dnssec ns com @l.root<a href="http://-servers.net" rel="nofollow" target="_blank">-servers.net</a> ; &lt;&lt;&gt;&gt; DiG 9.13.7 &lt;&lt;&gt;&gt; +dnssec ns com @l.root<a href="http://-servers.net" rel="nofollow" target="_blank">-servers.net</a> ;; global options: +cmd ;; Got answer: ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 22834 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;com.				IN	NS ;; AUTHORITY SECTION: com.			172800	IN	NS	<a href="http://a.gtld-servers.net" rel="nofollow" target="_blank">a.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://b.gtld-servers.net" rel="nofollow" target="_blank">b.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://c.gtld-servers.net" rel="nofollow" target="_blank">c.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://d.gtld-servers.net" rel="nofollow" target="_blank">d.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://e.gtld-servers.net" rel="nofollow" target="_blank">e.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://f.gtld-servers.net" rel="nofollow" target="_blank">f.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://g.gtld-servers.net" rel="nofollow" target="_blank">g.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://h.gtld-servers.net" rel="nofollow" target="_blank">h.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://i.gtld-servers.net" rel="nofollow" target="_blank">i.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://j.gtld-servers.net" rel="nofollow" target="_blank">j.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://k.gtld-servers.net" rel="nofollow" target="_blank">k.gtld-servers.net</a>. com.			172800	IN	NS	<a href="http://l.gtld-servers.net" rel="nofollow" target="_blank">l.gtld-servers.net</a> com.			172800	IN	NS	<a href="http://m.gtld-servers.net" rel="nofollow" target="_blank">m.gtld-servers.net</a>. com.			86400	IN	DS	30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com.			86400	IN	RRSIG	DS 8 1 86400 20190310170000 20190225160000 16749 . N9g+eeSjBKK+bOPW8IA/JGGQgTVrdZ12fIFS+8ggHLVW3LGQI6YTmpef +O+dbqeaFOnYcGBlRcc7HD9bVIy+ygImoMnKos98hx9YfPR+XK2HUBWM oZTT3yr27eL0hKxby4srlECX1B51gwuuYQQYpL8FI2Gl4v0eB0pMZWZ1 A0FUNWZA20lZ7HrBQ9OLnWCGkMgKkXqTvhcd0dhr0e3cVKmhC2m+de4X FlVm1zSjnmtEv6kT2n8YxnOsdNMs8VFa94MsjLr2OvT/HfbDmIiyEPEz 0U8K9oeFhVR2wczDydOiMpZ4l29aPMcZ7qQLaWGpOxHgTYiODlFD/qBY 00lq1w== ;; ADDITIONAL SECTION: <a href="http://a.gtld-servers.net" rel="nofollow" target="_blank">a.gtld-servers.net</a>.	172800	IN	A	192.5.6.30 <a href="http://b.gtld-servers.net" rel="nofollow" target="_blank">b.gtld-servers.net</a>.	172800	IN	A	192.33.14.30 <a href="http://c.gtld-servers.net" rel="nofollow" target="_blank">c.gtld-servers.net</a>.	172800	IN	A	192.26.92.30 <a href="http://d.gtld-servers.net" rel="nofollow" target="_blank">d.gtld-servers.net</a>.	172800	IN	A	192.31.80.30 <a href="http://e.gtld-servers.net" rel="nofollow" target="_blank">e.gtld-servers.net</a>.	172800	IN	A	192.12.94.30 <a href="http://f.gtld-servers.net" rel="nofollow" target="_blank">f.gtld-servers.net</a>.	172800	IN	A	192.35.51.30 <a href="http://g.gtld-servers.net" rel="nofollow" target="_blank">g.gtld-servers.net</a>.	172800	IN	A	192.42.93.30 <a href="http://h.gtld-servers.net" rel="nofollow" target="_blank">h.gtld-servers.net</a>.	172800	IN	A	192.54.112.30 <a href="http://i.gtld-servers.net" rel="nofollow" target="_blank">i.gtld-servers.net</a>.	172800	IN	A	192.43.172.30 <a href="http://j.gtld-servers.net" rel="nofollow" target="_blank">j.gtld-servers.net</a>.	172800	IN	A	192.48.79.30 <a href="http://k.gtld-servers.net" rel="nofollow" target="_blank">k.gtld-servers.net</a>.	172800	IN	A	192.52.178.30 <a href="http://l.gtld-servers.net" rel="nofollow" target="_blank">l.gtld-servers.net</a>.	172800	IN	A	192.41.162.30 <a href="http://m.gtld-servers.net" rel="nofollow" target="_blank">m.gtld-servers.net</a>.	172800	IN	A	192.55.83.30 <a href="http://a.gtld-servers.net" rel="nofollow" target="_blank">a.gtld-servers.net</a>.	172800	IN	AAAA	2001:503:a83e::2:30 <a href="http://b.gtld-servers.net" rel="nofollow" target="_blank">b.gtld-servers.net</a>.	172800	IN	AAAA	2001:503:231d::2:30 <a href="http://c.gtld-servers.net" rel="nofollow" target="_blank">c.gtld-servers.net</a>.	172800	IN	AAAA	2001:503:83eb::30 <a href="http://d.gtld-servers.net" rel="nofollow" target="_blank">d.gtld-servers.net</a>.	172800	IN	AAAA	2001:500:856e::30 <a href="http://e.gtld-servers.net" rel="nofollow" target="_blank">e.gtld-servers.net</a>.	172800	IN	AAAA	2001:502:1ca1::30 <a href="http://f.gtld-servers.net" rel="nofollow" target="_blank">f.gtld-servers.net</a>.	172800	IN	AAAA	2001:503:d414::30 <a href="http://g.gtld-servers.net" rel="nofollow" target="_blank">g.gtld-servers.net</a>.	172800	IN	AAAA	2001:503:eea3::30 <a href="http://h.gtld-servers.net" rel="nofollow" target="_blank">h.gtld-servers.net</a>.	172800	IN	AAAA	2001:502:8cc::30 <a href="http://i.gtld-servers.net" rel="nofollow" target="_blank">i.gtld-servers.net</a>.	172800	IN	AAAA	2001:503:39c1::30 <a href="http://j.gtld-servers.net" rel="nofollow" target="_blank">j.gtld-servers.net</a>.	172800	IN	AAAA	2001:502:7094::30 <a href="http://k.gtld-servers.net" rel="nofollow" target="_blank">k.gtld-servers.net</a>.	172800	IN	AAAA	2001:503:d2d::30 <a href="http://l.gtld-servers.net" rel="nofollow" target="_blank">l.gtld-servers.net</a>.	172800	IN	AAAA	2001:500:d937::30 <a href="http://m.gtld-servers.net" rel="nofollow" target="_blank">m.gtld-servers.net</a>.	172800	IN	AAAA	2001:501:b1f9::30 ;; Query time: 37 msec ;; SERVER: 199.7.83.42#53(199.7.83.42) ;; WHEN: lun feb 25 19:26:28 CET 2019 ;; MSG SIZE rcvd: 1163 edu@Andromeda ~ # dig +dnssec ns <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> @e.gtld<a href="http://-servers.net" rel="nofollow" target="_blank">-servers.net</a> ; &lt;&lt;&gt;&gt; DiG 9.13.7 &lt;&lt;&gt;&gt; +dnssec ns <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> @e.gtld<a href="http://-servers.net" rel="nofollow" target="_blank">-servers.net</a> ;; global options: +cmd ;; Got answer: ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 40192 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;<a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>.		IN	NS ;; AUTHORITY SECTION: <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>.	172800	IN	NS	<a href="http://ns1.neodigit.net" rel="nofollow" target="_blank">ns1.neodigit.net</a>. <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>.	172800	IN	NS	<a href="http://ns2.neodigit.net" rel="nofollow" target="_blank">ns2.neodigit.net</a>. <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>.	86400	IN	DS	38890 13 1 38BF99A8BB8A4D3FA8D66A65964014099C2D34E9 <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>.	86400	IN	RRSIG	DS 8 2 86400 20190304054735 20190225043735 16883 com. tPJ2JQf9590P2yOZ3WroyEwqh1Aa+WsiYdV8BS/vqFKeqXsS2nPxPOl1 ijWLq90pUYyBUE7hBD3ZDsqPoguo4YeWKxqNbc87BbqhXudMpdjHC+Wl Gd9XbBHOtcu7qKff1gTsU/lxVg9cQ14Uzqbu/V56zOlPexua/66FUgmr G4g= ;; Query time: 42 msec ;; SERVER: 192.12.94.30#53(192.12.94.30) ;; WHEN: lun feb 25 19:26:52 CET 2019 ;; MSG SIZE rcvd: 294 edu@Andromeda ~ # dig +dnssec <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> @ns1.neodigit.net ; &lt;&lt;&gt;&gt; DiG 9.13.7 &lt;&lt;&gt;&gt; +dnssec <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a> @ns1.neodigit.net ;; global options: +cmd ;; Got answer: ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 51436 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;<a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>.		IN	A ;; ANSWER SECTION: <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>.	7200	IN	RRSIG	A 13 2 7200 20190307000000 20190214000000 38890 <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>. FHBRqGzga6FVCfNar88YM7xhh1cTZQd2YpM5ZIF9/BM49M96qrZ4D+wP nh1lxBpEhyG/ptHMqF2FwSE6OJ12Xg== <a href="http://eduardocollado.com" rel="nofollow" target="_blank">eduardocollado.com</a>.	7200	IN	A	31.47.74.50 ;; Query time: 7 msec ;; SERVER: 31.47.72.140#53(31.47.72.140) ;; WHEN: lun feb 25 19:27:37 CET 2019 ;; MSG SIZE rcvd: 177 edu@Andromeda ~ # Como veis el sistema de DNSSec es una relación de confianza de zonas padres e hijas utilizando criptografía asimétrica, es decir, con el uso de claves privadas y claves públicas. Obviamente DNSSec no soluciona todos los problemas de seguridad en Internet, pero ayuda mucho ya que hacemos que las respuestas de los DNSs unas sean dependientes de los niveles superiores, una especie de blockchain ahora que está tan de moda esa palabra.

DNSSec

La utilización de la comunity de blackhole en BGP es una técnica que proporciona la capacidad de descartar el tráfico no deseado antes de que entre en la red protegida. Conceptualmente es algo maravilloso. La idea es proteger nuestra red haciendo que el tráfico que no queremos ni siquiera llegue a nuestra red. En el audio de hoy voy a contaros las aplicaciones de los blackholes, cómo desplegarlo y cómo puede ayudarnos para mitigar ataques de denegación de servicio DDoS. Lo primero indicar que cuando hablamos de Blackholes normalmente estamos simplificando muchísimo y realmente nos estamos refiriendo a «Remotely Triggered Black Hole Filtering» que vendría a ser un «filtrado de blackhole disparado a distancia», esta es una traducción muy libre, pero creo que la idea queda clara y no es otra más que crear un filtro en un dispositivo remoto. Esta técnica no es algo dependiente de ningún fabricante, sino una forma de proceder basándonos en las posibilidades que nos da BGP para transmitir información mediante Communities y en las capacidades de filtrado de cualquier router de hoy en día. Además el filtrar el tráfico antes de que entre en nuestra red es una necesidad porque los ataques distribuidos pueden llegar a tener un tamaño mayor que la capacidad de nuestros tránsitos. Es decir, podemos llenar todo el ancho de banda disponible con el tráfico del DDoS dejando toda la red fuera, así que es muy importante que ese tráfico no llegue a entrar. Pensad que si hubiera un DDoS que llenara el ancho de banda completo de la red podría incluso llegar a dejar fuera a las personas encargadas de trabajar con la red para mitigar el problema. El procedimiento para crear un blackhole sería el siguiente:  Generar un anuncio de iBGP con una community dada, podría ser la 666 por ejemplo y anunciar el prefijo a bloquear a los routers frontera. Estos routers frontera recibirían y al comprobar que la community es la de blackhole anunciaría ese mismo prefijo a sus tránsitos. Cada tránsito es posible que use diferentes communities de blackhole, con lo que habrá que hacer adaptaciones. Cuando llega al proveedor de tránsito este seguirá propagando el blackhole e incluirá una ruta a una IP/32 asignada a null0 para ese prefijo recibido. Al llegar trafico a nuestros tránsitos al prefijo que está en blackhole el tráfico no será enviado a nosotros sino enviado a esa IP/32 y descartado porque el rango de blackhole será normalmente más pequeño por lo tanto preferido.  Bueno, vamos a tratar de explicar esto un poco más despacio porque aquí hay cosas que pueden sonar un poco raras. La configuración tiene varias partes y queremos que haga lo siguiente  Match una etiqueta con valor 666. Cambiamos el next-hop a 192.0.2.1 Cambiamos la local-preference a 200. Cambiamos el origin a igp. Marcamos la community no-export.  Y para lanzar el blackhole haríamos lo siguiente:ip route 198.51.100.1 255.255.255.255 Null0 tag 666La configuración que haría esto es la siguiente:interface loopback0 ip address 192.168.1.1 255.255.255.255 interface Null0 no ip unreachables router bgp 64555 no synchronization no bgp client-to-client reflection bgp log-neighbor-changes redistribute static route-map black-hole-trigger neighbor black-hole peer-group neighbor black-hole remote-as 64555 neighbor black-hole update-source loopback0 neighbor black-hole route-reflector-client neighbor x.x.x.x peer-group black-hole route-map black-hole-trigger permit 10 match tag 666 set ip next-hop 192.0.2.1 set local-preference 200 set origin igp set community no-export route-map black-hole-trigger deny 20Tener en cuenta si buscáis por ahí ejemplos para copiar y pegar, como el que os pongo en las notas del programa, que los ejemplos se suelen hacer con los rangos 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), y 203.0.113.0/24 (TEST-NET-3) que son bloques reservados para documentación y no pueden ser usados en Internet. Con esto ya podemos anunciar a nuestros peers. Ya tenemos un sistema para meter en blackhole rutas que metamos a mano, pero el problema es que tenemos que ser muy rápidos. Como ya he dicho es importante que tengamos en cuenta que si tenemos un DDoS muy grande puede llegar a llenarse los tránsitos y eso ¿sabéis lo que significará? Que nuestras actualizaciones de BGP con los prefijos blackholeados no llegarán a nuestros tránsitos y el blackhole no será efectivo. Para solucionar eso hay algún operador de tránsito, Cogent para ser más concretos que te da una sesión multihop y podrías anunciar el blackhole aunque su sesión BGP esté caída. Es decir, tendremos una sesión BGP sólo para el blackhole. Para implementar blackhole podemos hacerlo a mano (y ser muy raṕidos) o bien automatizarlo, pero claro, eso requiere que tengamos cuidado cuando lanzar el blackhole, si lo hacemos demasiado pronto podremos dejar a clientes sin conectividad sólo por un pico de tráfico legitimo y si es demasiado tarde a lo mejor el blackhole ya no vale para nada, así que para ello lo mejor es que esto os lo monte alguien con la suficiente experiencia en este tipo de soluciones. En Tecnocrática damos este servicio a nuestros clientes de gestión de red, es decir, a los clientes que les gestionamos la red les montamos varias cosas y una de ellas es esto, la automatización de blackholes en función de su perfil de tráfico y necesitadas específicas, porque cada red es un Mundo. También deciros que aquí os he puesto un ejemplo en Cisco porque creo que es lo más extendido y común, pero obviamente esto se podrá hacer con cualquier otra fabricante, lo que pasa es que en algunos tendremos que innovar un poco porque por ejemplo con Mikrotik en BGP no podemos hacer un set next-hop, así que bueno, hay que ser más imaginativo. Al final lo que importa es encontrar una solución para este tipo de problemas y enviar una actualización de BGP a nuestros tránsitos, cada uno con su community de blackhole.

La utilización de la comunity de blackhole en BGP es una técnica que proporciona la capacidad de descartar el tráfico no deseado antes de que entre en la red protegida. Conceptualmente es algo maravilloso. La idea es proteger nuestra red haciendo que el tráfico que no queremos ni siquiera llegue a nuestra red. En el audio de hoy voy a contaros las aplicaciones de los blackholes, cómo desplegarlo y cómo puede ayudarnos para mitigar ataques de denegación de servicio DDoS. Lo primero indicar que cuando hablamos de Blackholes normalmente estamos simplificando muchísimo y realmente nos estamos refiriendo a «Remotely Triggered Black Hole Filtering» que vendría a ser un «filtrado de blackhole disparado a distancia», esta es una traducción muy libre, pero creo que la idea queda clara y no es otra más que crear un filtro en un dispositivo remoto. Esta técnica no es algo dependiente de ningún fabricante, sino una forma de proceder basándonos en las posibilidades que nos da BGP para transmitir información mediante Communities y en las capacidades de filtrado de cualquier router de hoy en día. Además el filtrar el tráfico antes de que entre en nuestra red es una necesidad porque los ataques distribuidos pueden llegar a tener un tamaño mayor que la capacidad de nuestros tránsitos. Es decir, podemos llenar todo el ancho de banda disponible con el tráfico del DDoS dejando toda la red fuera, así que es muy importante que ese tráfico no llegue a entrar. Pensad que si hubiera un DDoS que llenara el ancho de banda completo de la red podría incluso llegar a dejar fuera a las personas encargadas de trabajar con la red para mitigar el problema. El procedimiento para crear un blackhole sería el siguiente: <ol> <li>Generar un anuncio de iBGP con una community dada, podría ser la 666 por ejemplo y anunciar el prefijo a bloquear a los routers frontera.</li> <li>Estos routers frontera recibirían y al comprobar que la community es la de blackhole anunciaría ese mismo prefijo a sus tránsitos. Cada tránsito es posible que use diferentes communities de blackhole, con lo que habrá que hacer adaptaciones.</li> <li>Cuando llega al proveedor de tránsito este seguirá propagando el blackhole e incluirá una ruta a una IP/32 asignada a null0 para ese prefijo recibido.</li> <li>Al llegar trafico a nuestros tránsitos al prefijo que está en blackhole el tráfico no será enviado a nosotros sino enviado a esa IP/32 y descartado porque el rango de blackhole será normalmente más pequeño por lo tanto preferido.</li> </ol> Bueno, vamos a tratar de explicar esto un poco más despacio porque aquí hay cosas que pueden sonar un poco raras. La configuración tiene varias partes y queremos que haga lo siguiente <ol> <li>Match una etiqueta con valor 666.</li> <li>Cambiamos el next-hop a 192.0.2.1</li> <li>Cambiamos la local-preference a 200.</li> <li>Cambiamos el origin a igp.</li> <li>Marcamos la community no-export.</li> </ol> Y para lanzar el blackhole haríamos lo siguiente:ip route 198.51.100.1 255.255.255.255 Null0 tag 666 La configuración que haría esto es la siguiente:interface loopback0 ip address 192.168.1.1 255.255.255.255 interface Null0 no ip unreachables router bgp 64555 no synchronization no bgp client-to-client reflection bgp log-neighbor-changes redistribute static route-map black-hole-trigger neighbor black-hole peer-group neighbor black-hole remote-as 64555 neighbor black-hole update-source loopback0 neighbor black-hole route-reflector-client neighbor x.x.x.x peer-group black-hole route-map black-hole-trigger permit 10 match tag 666 set ip next-hop 192.0.2.1 set local-preference 200 set origin igp set community no-export route-map black-hole-trigger deny 20 Tener en cuenta si buscáis por ahí ejemplos para copiar y pegar, como el que os pongo en las notas del programa, que los ejemplos se suelen hacer con los rangos 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), y 203.0.113.0/24 (TEST-NET-3) que son bloques reservados para documentación y no pueden ser usados en Internet. Con esto ya podemos anunciar a nuestros peers. Ya tenemos un sistema para meter en blackhole rutas que metamos a mano, pero el problema es que tenemos que ser muy rápidos. Como ya he dicho es importante que tengamos en cuenta que si tenemos un DDoS muy grande puede llegar a llenarse los tránsitos y eso ¿sabéis lo que significará? Que nuestras actualizaciones de BGP con los prefijos blackholeados no llegarán a nuestros tránsitos y el blackhole no será efectivo. Para solucionar eso hay algún operador de tránsito, Cogent para ser más concretos que te da una sesión multihop y podrías anunciar el blackhole aunque su sesión BGP esté caída. Es decir, tendremos una sesión BGP sólo para el blackhole. Para implementar blackhole podemos hacerlo a mano (y ser muy raṕidos) o bien automatizarlo, pero claro, eso requiere que tengamos cuidado cuando lanzar el blackhole, si lo hacemos demasiado pronto podremos dejar a clientes sin conectividad sólo por un pico de tráfico legitimo y si es demasiado tarde a lo mejor el blackhole ya no vale para nada, así que para ello lo mejor es que esto os lo monte alguien con la suficiente experiencia en este tipo de soluciones. En Tecnocrática damos este servicio a nuestros clientes de gestión de red, es decir, a los clientes que les gestionamos la red les montamos varias cosas y una de ellas es esto, la automatización de blackholes en función de su perfil de tráfico y necesitadas específicas, porque cada red es un Mundo. También deciros que aquí os he puesto un ejemplo en Cisco porque creo que es lo más extendido y común, pero obviamente esto se podrá hacer con cualquier otra fabricante, lo que pasa es que en algunos tendremos que innovar un poco porque por ejemplo con Mikrotik en BGP no podemos hacer un set next-hop, así que bueno, hay que ser más imaginativo. Al final lo que importa es encontrar una solución para este tipo de problemas y enviar una actualización de BGP a nuestros tránsitos, cada uno con su community de blackhole.

Community de Blackhole

Ayer se instaló un servidor raíz L en Tecnocrática, así que en el audio de hoy os hablo de servidores raíz. El funcionamiento de DNS es jerárquico y al final se llega al origen del árbol, al servidor raiz, para verlo de forma sencilla es el servidor que no pregunta a nadie, es el servidor último. Cuando se busca un dominio el servidor raíz es el que proporciona la dirección y el nombre del servidor de DNS autorizado. Sin root servers no podríamos resolver dominios, no podríamos navegar e Internet no existiría. No se si os he conseguido trasladar la importancia de los root servers, realmente Internet depende de ellos y cuando Rusia por ejemplo dice que quiere una Internet paralela lo que quiere decir es que no se fía de los root servers que están fuera de Rusia. Obviamente en Rusia también hay root servers. A día de hoy los root servers se gestionan desde 12 entidades independientes, 9 norte americanas, una europea, una japonesa y otra NORDUnet que está integrada por Dinamarca (DeIC), Islandia (RHnet), Noruega (Uninett), Suecia (SUNET), y Finlandia (Funet). Esas entidades que gestionan los DNSs han ido ampliándose para proporcionar al sistema de DNS mayor independencia. Cada entidad tiene asignada una letra y cada letra representa un servidor de DNS, aunque realmente son muchos distribuidos por el Mundo y anunciando todos los mismos prefijos de BGP, es decir el mismo direccionamiento, utilizando Anycast. Las letras son las siguientes:  A y J gestionadas por Verisign B Information Sciences Institute C Cogent Communications D Universidad de Maryland E NASA Ames Research Center F ISC Internet System Consortium G U.S. DOD Network Information Center H U.S. Army Research Lab (estos no utilizan Anycast) I Netnod – Países nordicos K RIPE NCC L ICANN M Wide Project (japoneses)  El fichero de zona lo podéis descargar en: https://www.internic.net/domain/root.zone Por ejemplo si vemos la zona .es veremos la configuración qeu tiene y cuales son los NS autorizativos, realmente la configuración de .es son sólo 22 líneas, no hay más. es. 172800 IN NS a.nic.es. es. 172800 IN NS f.nic.es. es. 172800 IN NS g.nic.es. es. 172800 IN NS ns1.cesca.es. es. 172800 IN NS ns-es.nic.fr. es. 172800 IN NS ns-ext.nic.cl. es. 172800 IN NS sns-pb.isc.org. ES. 86400 IN DS 29450 8 1 417BEAFB46ABF3430B75C5C29AEF785D476B60E1 ES. 86400 IN DS 29450 8 2 8BEC32A2C9CFE42E393BAF81FFE71B521D3E940612A4590B4763ADC539E4B563 ES. 86400 IN RRSIG DS 8 1 86400 20190306050000 20190221040000 16749 . uefcVfS5p2CqISKzF6DsWmG3h+Bj+4I+PV7zbFxKITljffX9PXebrL15Npo82NpIL+keHGv7tkTp2mRqjbgfe44aFx1YMBbvafT0lF5L7qtbEnrRPbLUwYrWG2a0stLJwdSlAkTQ2alOhnnn+LScS4pEzjSd++Dju22eEJlbR+gWVC9+pAtaDok74CvMarAbsrWJZW5dSmdrzT1vliyz3OgQ9yupXVO8hVNTw5S2HmhQ8v0dG9HUFirAm3M6M90lUDdKYN1mjwXLJvQmR0aNW2XPrR4OZfVIpNdh7GK+Jk4O1nxEKMSCSQtc18Kq8YcqI5hPUNAm6rcogAdVtOkLAQ== es. 86400 IN NSEC esq. NS DS RRSIG NSEC es. 86400 IN RRSIG NSEC 8 1 86400 20190306050000 20190221040000 16749 . AO7DM96RTfgoIwx59jL8alzbK3RFefhXRFve9e4p2fCTjb6E2L77EBqkC0kpcHT1i0MHg5YT/g/hF6TgDzeCIyNAhps5jnLeHti3W/G6F9zrichYSTKcyvOBo2qWs9VFfnuuebZfdaakV3zEQuTUDaaQXwin2tMH7cVBNu4F6NMsolSqKLk4T+5AAOU5dqpuYSuGWfNNWzmWq+yKe8NHnDmwDCASzVdyLgCk9dcq+TrueXU9IwkIq78F5YgFcVB3ELDcsSvdU4q4h67ssAB1AU3WYcdBL6O3MB8McCOYzwik81PUFZMIFXWZwT/HwqFGPp8hSm74HMfarnEV7PfkfQ== ns1.cesca.es. 172800 IN A 84.88.0.3 ns1.cesca.es. 172800 IN AAAA 2001:40b0:1:1122:ce5c:a000:0:3 a.nic.es. 172800 IN A 194.69.254.1 a.nic.es. 172800 IN AAAA 2001:67c:21cc:2000:0:0:64:41 f.nic.es. 172800 IN A 130.206.1.7 f.nic.es. 172800 IN AAAA 2001:720:418:caf1:0:0:0:7 g.nic.es. 172800 IN A 204.61.217.1 g.nic.es. 172800 IN AAAA 2001:500:14:7001:ad:0:0:1 ad.ns.nic.es. 172800 IN A 194.69.254.15 ns1.nic.es. 172800 IN A 194.69.254.1 ns1.nic.es. 172800 IN AAAA 2001:67c:21cc:2000:0:0:64:41 Otros capítulos sobre DNS:  Podcast #10: Cómo funciona el DNS Podcast #175: Traspaso de la KSK en la Zona Raíz con João Damas Podcast #163: Seguridad en DNS Podcast #186: DNS Flag Day con Adrian Almenar Podcast #164: Charlando con Joaquín Gómez de Infoblox sobre DHCP, DNS y demás Podcast #119: La importancia del DNS en la carga de una web Podcast #72: El negocio del DNS 

Ayer se instaló un servidor raíz L en <a href="https://tecnocratica.net" rel="noopener noreferrer nofollow" target="_blank">Tecnocrática</a>, así que en el audio de hoy os hablo de servidores raíz. El funcionamiento de DNS es jerárquico y al final se llega al origen del árbol, al servidor raiz, para verlo de forma sencilla es el servidor que no pregunta a nadie, es el servidor último. Cuando se busca un dominio el servidor raíz es el que proporciona la dirección y el nombre del servidor de DNS autorizado. Sin root servers no podríamos resolver dominios, no podríamos navegar e Internet no existiría. No se si os he conseguido trasladar la importancia de los root servers, realmente Internet depende de ellos y cuando Rusia por ejemplo dice que quiere una Internet paralela lo que quiere decir es que no se fía de los root servers que están fuera de Rusia. Obviamente en Rusia también hay root servers. A día de hoy los root servers se gestionan desde 12 entidades independientes, 9 norte americanas, una europea, una japonesa y otra NORDUnet que está integrada por Dinamarca (DeIC), Islandia (RHnet), Noruega (Uninett), Suecia (SUNET), y Finlandia (Funet). Esas entidades que gestionan los DNSs han ido ampliándose para proporcionar al sistema de DNS mayor independencia. Cada entidad tiene asignada una letra y cada letra representa un servidor de DNS, aunque realmente son muchos distribuidos por el Mundo y anunciando todos los mismos prefijos de BGP, es decir el mismo direccionamiento, utilizando Anycast. Las letras son las siguientes: <ul> <li>A y J gestionadas por Verisign</li> <li>B Information Sciences Institute</li> <li>C Cogent Communications</li> <li>D Universidad de Maryland</li> <li>E NASA Ames Research Center</li> <li>F ISC Internet System Consortium</li> <li>G U.S. DOD Network Information Center</li> <li>H U.S. Army Research Lab (estos no utilizan Anycast)</li> <li>I Netnod – Países nordicos</li> <li>K RIPE NCC</li> <li>L ICANN</li> <li>M Wide Project (japoneses)</li> </ul> El fichero de zona lo podéis descargar en: <a href="https://www.internic.net/domain/root.zone" rel="noopener noreferrer nofollow" target="_blank">https://www.internic.net/domain/root.zone</a> Por ejemplo si vemos la zona .es veremos la configuración qeu tiene y cuales son los NS autorizativos, realmente la configuración de .es son sólo 22 líneas, no hay más. <code>es. 172800 IN NS <a href="http://a.nic.es" rel="nofollow" target="_blank">a.nic.es</a>.</code> <code>es. 172800 IN NS <a href="http://f.nic.es" rel="nofollow" target="_blank">f.nic.es</a>.</code> <code>es. 172800 IN NS <a href="http://g.nic.es" rel="nofollow" target="_blank">g.nic.es</a>.</code> <code>es. 172800 IN NS <a href="http://ns1.cesca.es" rel="nofollow" target="_blank">ns1.cesca.es</a>.</code> <code>es. 172800 IN NS <a href="http://ns-es.nic.fr" rel="nofollow" target="_blank">ns-es.nic.fr</a>.</code> <code>es. 172800 IN NS <a href="http://ns-ext.nic.cl" rel="nofollow" target="_blank">ns-ext.nic.cl</a>.</code> <code>es. 172800 IN NS <a href="http://sns-pb.isc.org" rel="nofollow" target="_blank">sns-pb.isc.org</a>.</code> <code>ES. 86400 IN DS 29450 8 1 417BEAFB46ABF3430B75C5C29AEF785D476B60E1</code> <code>ES. 86400 IN DS 29450 8 2 8BEC32A2C9CFE42E393BAF81FFE71B521D3E940612A4590B4763ADC539E4B563</code> <code>ES. 86400 IN RRSIG DS 8 1 86400 20190306050000 20190221040000 16749 . uefcVfS5p2CqISKzF6DsWmG3h+Bj+4I+PV7zbFxKITljffX9PXebrL15Npo82NpIL+keHGv7tkTp2mRqjbgfe44aFx1YMBbvafT0lF5L7qtbEnrRPbLUwYrWG2a0stLJwdSlAkTQ2alOhnnn+LScS4pEzjSd++Dju22eEJlbR+gWVC9+pAtaDok74CvMarAbsrWJZW5dSmdrzT1vliyz3OgQ9yupXVO8hVNTw5S2HmhQ8v0dG9HUFirAm3M6M90lUDdKYN1mjwXLJvQmR0aNW2XPrR4OZfVIpNdh7GK+Jk4O1nxEKMSCSQtc18Kq8YcqI5hPUNAm6rcogAdVtOkLAQ==</code> <code>es. 86400 IN NSEC esq. NS DS RRSIG NSEC</code> <code>es. 86400 IN RRSIG NSEC 8 1 86400 20190306050000 20190221040000 16749 . AO7DM96RTfgoIwx59jL8alzbK3RFefhXRFve9e4p2fCTjb6E2L77EBqkC0kpcHT1i0MHg5YT/g/hF6TgDzeCIyNAhps5jnLeHti3W/G6F9zrichYSTKcyvOBo2qWs9VFfnuuebZfdaakV3zEQuTUDaaQXwin2tMH7cVBNu4F6NMsolSqKLk4T+5AAOU5dqpuYSuGWfNNWzmWq+yKe8NHnDmwDCASzVdyLgCk9dcq+TrueXU9IwkIq78F5YgFcVB3ELDcsSvdU4q4h67ssAB1AU3WYcdBL6O3MB8McCOYzwik81PUFZMIFXWZwT/HwqFGPp8hSm74HMfarnEV7PfkfQ==</code> <code><a href="http://ns1.cesca.es" rel="nofollow" target="_blank">ns1.cesca.es</a>. 172800 IN A 84.88.0.3</code> <code><a href="http://ns1.cesca.es" rel="nofollow" target="_blank">ns1.cesca.es</a>. 172800 IN AAAA 2001:40b0:1:1122:ce5c:a000:0:3</code> <code><a href="http://a.nic.es" rel="nofollow" target="_blank">a.nic.es</a>. 172800 IN A 194.69.254.1</code> <code><a href="http://a.nic.es" rel="nofollow" target="_blank">a.nic.es</a>. 172800 IN AAAA 2001:67c:21cc:2000:0:0:64:41</code> <code><a href="http://f.nic.es" rel="nofollow" target="_blank">f.nic.es</a>. 172800 IN A 130.206.1.7</code> <code><a href="http://f.nic.es" rel="nofollow" target="_blank">f.nic.es</a>. 172800 IN AAAA 2001:720:418:caf1:0:0:0:7</code> <code><a href="http://g.nic.es" rel="nofollow" target="_blank">g.nic.es</a>. 172800 IN A 204.61.217.1</code> <code><a href="http://g.nic.es" rel="nofollow" target="_blank">g.nic.es</a>. 172800 IN AAAA 2001:500:14:7001:ad:0:0:1</code> <code><a href="http://ad.ns.nic.es" rel="nofollow" target="_blank">ad.ns.nic.es</a>. 172800 IN A 194.69.254.15</code> <code><a href="http://ns1.nic.es" rel="nofollow" target="_blank">ns1.nic.es</a>. 172800 IN A 194.69.254.1</code> <code><a href="http://ns1.nic.es" rel="nofollow" target="_blank">ns1.nic.es</a>. 172800 IN AAAA 2001:67c:21cc:2000:0:0:64:41</code> Otros capítulos sobre DNS: <ul> <li><a href="https://www.eduardocollado.com/2017/02/02/podcast-10-como-funciona-el-dns/" rel="nofollow" target="_blank">Podcast #10: Cómo funciona el DNS</a></li> <li><a href="https://www.eduardocollado.com/2018/09/19/podcast-175-traspaso-de-la-ksk-en-la-zona-raiz-con-joao-damas/" rel="nofollow" target="_blank">Podcast #175: Traspaso de la KSK en la Zona Raíz con João Damas</a></li> <li><a href="https://www.eduardocollado.com/2018/06/10/podcast-163-seguridad-en-dns/" rel="nofollow" target="_blank">Podcast #163: Seguridad en DNS</a></li> <li><a href="https://www.eduardocollado.com/2019/01/26/podcast-186-dns-flag-day-con-adrian-almenar/" rel="nofollow" target="_blank">Podcast #186: DNS Flag Day con Adrian Almenar</a></li> <li><a href="https://www.eduardocollado.com/2018/06/16/podcast-164-charlando-con-joaquin-gomez-de-infoblox-sobre-dhcp-dns-y-demas/" rel="nofollow" target="_blank">Podcast #164: Charlando con Joaquín Gómez de Infoblox sobre DHCP, DNS y demás</a></li> <li><a href="https://www.eduardocollado.com/2018/02/20/podcast-119-la-importancia-del-dns-en-la-carga-de-una-web/" rel="nofollow" target="_blank">Podcast #119: La importancia del DNS en la carga de una web</a></li> <li><a href="https://www.eduardocollado.com/2017/11/30/podcast-72-el-negocio-del-dns/" rel="nofollow" target="_blank">Podcast #72: El negocio del DNS</a></li> </ul>

Root Servers

El próximo 1 de febrero tenemos otra fecha clave para DNS, si en Septiembre hablamos del traspaso de la KSK en la zona raíz hoy vamos a comentar el DNS Flag Day. La verdad es que el día 1 de Febrero, el próximo Viernes será un día interesante ya que los parches que se han ido añadiendo a los DNSs a lo largo de los años dejarán de funcionar si resultan ser no compatibles con el estándar EDNS que regula los mecanismos de extensión. Todos sabemos como funciona un DNS, todos sabemos cómo resuelve un DNS, pero quizás no conozcáis la problemática que hay con los mecanismos de extensión de DNS, algo tan importante que hará que algunos dominios dejen de funcionar el 1 de Febrero, es decir, el próximo viernes. Pero tampoco nos lo tomemos a la tremenda, esos dominios solo estarán sin funcionar hasta que se actualice el servidor de DNS, porque actualizar será lo más sencillo. También tendremos una serie de dominios que seguirán funcionando aún sin soportar el estándar completo, esto se traducirá en incapacidad para asumir nuevas funcionalidades, posibles problemas a futuro, sobre todo de seguridad, etc. De todos modos está divertido entrar en dnsflagday.net y comprobar dominios de gente, empresas u organismos que conozcáis y descubriréis que gente que le vaya a fallar hay poca, pero gente con problemas muchísimos, podéis dedicarle un rato a curiosear mientras os cuento un poco el tema. El problema que subyace a todo esto del DNS Flag Day es un problema de tamaño ya que un datagrama UDP tiene un tamaño máximo de 512 bytes. Aquí seguramente muchos estaréis extrañados, porque 512 no es el tamaño máximo de un datagrama UDP. Lo que pasa es que 512 bytes es el tamaño que garantiza el reensamblado si son fragmentados en tránsito. IPv4 especifica que cada host debe poder volver a ensamblar paquetes de 576 bytes o menos. Con un encabezado IPv4 (mínimo de 20 bytes y máximo con opciones de 60 bytes) y un encabezado UDP de 8 bytes, un datagrama DNS con una carga útil de 512 bytes será menor que 576 bytes. Y también es verdad que DNS puede utilizar TCP para cargas grandes y para transferencias de zona y DNSSEC, pero eso añade una latencia innecesaria debido al desafío en tres vías de TCP. -&gt;syn &lt;-ack &lt;-syn -&gt;ack Esto de todos modos lo podéis leer en el punto 2.3.4 de la RFC 1035 «DOMAIN NAMES – IMPLEMENTATION AND SPECIFICATION» titulado Size Limits donde pone: labels 63 octets or less names 255 octets or less TTL positive values of a signed 32 bit number. UDP messages 512 octets or less Pues para poder transmitir más información en el año 1999 Paul Vixie, que trabajaba en ISC, se sacó de la manga un estándar titulado «Extension Mechanisms for DNS (EDNS0)», lo podéis leer en la RFC 2671, luego vino la 2673 y finalmente la 6891, que oh sorpresa está escrita por Vixie, Graff y nuestro buen amigo Joao Damas ya vino a contarnos el traspaso de la KSK en el capítulo 175. Al principio el objetivo era permitir respuestas más largas sin perder la compatibilidad con lo ya establecido y luego la cosa se fue completando. Para que esto funcionara no se podía modificar la cabecera de DNS porque ya estaba llena, así que se utilizaron los registros de tipo OPT y es aquí donde indicamos la cantidad de información a transmitir gracias a las 16 opciones adicionales añadidas. Esto aunque os parezca una cosa sin importancia es vital para DNSSEC ya que no cabe la información en datagramas de 512 bytes. Pero hay más extensiones, como la identificación de instancia del servidor NSID, identificar desde qué red viene la consulta con Client-Subnet, controlar los timeouts variables con Keep-alive, el mecanismo de seguridad Cookies. En fin hay y habrá más. El primer problema surge antes de llegar el datagrama porque muchos firewalls filtraban, algunos aún lo hacen, el tamaño máximo de UDP a 512bytes y claro, todos estos datagramas son o eran descartados, mala cosa. Al permitir datagramas UDP más grandes para los DNSs en los firewalls al final conseguimos facilitar los famosos ataques de amplificación, en los que hacemos una pregunta muy pequeña para recibir una respuesta muy grande. Todo esto nos ha llevado a utilizar los DNSs de forma poco óptima por culpa de aquellos que no se han adherido a los estándares. Actualmente tenemos tres problemas principales:  DNS autoritativos que bloquean respuestas Malas implementaciones de DNS que no siguen los estándares. Esto provoca entre otras cosas que algunos resolvers tengan que esperar timeout y reintentar con TCP o sin EDNS y claro … va lento. Firewalls mal configurados que bloquean el tráfico que sigue a los estándares  Pero todo esto se solucionará el 1 de Febrero con las nuevas versiones en paralelo de Bind, PowerDNS, Unbound y Knot que dejarán de funcionar con parches históricos para que pudiera funcionar todo el Mundo, hasta los que no seguían los estándares, pero eso se acabó, no se puede seguir avanzando manteniendo parches para aquellos que no han realizado su trabajo. Además, el cambio del día 1 tiene una cosa muy interesante, no van a caer inocentes, van a fallar aquellos que no se han adaptado al estándar y por desgracia, estos si que no tienen culpa, sus clientes y usuarios. Enlaces: https://www.lacnic.net/innovaportal/file/3207/1/edns-flag-day.pdf

El próximo 1 de febrero tenemos otra fecha clave para DNS, si en Septiembre hablamos del traspaso de la KSK en la zona raíz hoy vamos a comentar el DNS Flag Day. La verdad es que el día 1 de Febrero, el próximo Viernes será un día interesante ya que los parches que se han ido añadiendo a los DNSs a lo largo de los años dejarán de funcionar si resultan ser no compatibles con el estándar EDNS que regula los mecanismos de extensión. Todos sabemos como funciona un DNS, todos sabemos cómo resuelve un DNS, pero quizás no conozcáis la problemática que hay con los mecanismos de extensión de DNS, algo tan importante que hará que algunos dominios dejen de funcionar el 1 de Febrero, es decir, el próximo viernes. Pero tampoco nos lo tomemos a la tremenda, esos dominios solo estarán sin funcionar hasta que se actualice el servidor de DNS, porque actualizar será lo más sencillo. También tendremos una serie de dominios que seguirán funcionando aún sin soportar el estándar completo, esto se traducirá en incapacidad para asumir nuevas funcionalidades, posibles problemas a futuro, sobre todo de seguridad, etc. De todos modos está divertido entrar en <a href="https://dnsflagday.net/index-es.html" rel="noopener noreferrer nofollow" target="_blank">dnsflagday.net</a> y comprobar dominios de gente, empresas u organismos que conozcáis y descubriréis que gente que le vaya a fallar hay poca, pero gente con problemas muchísimos, podéis dedicarle un rato a curiosear mientras os cuento un poco el tema. El problema que subyace a todo esto del DNS Flag Day es un problema de tamaño ya que un datagrama UDP tiene un tamaño máximo de 512 bytes. Aquí seguramente muchos estaréis extrañados, porque 512 no es el tamaño máximo de un datagrama UDP. Lo que pasa es que 512 bytes es el tamaño que garantiza el reensamblado si son fragmentados en tránsito. IPv4 especifica que cada host debe poder volver a ensamblar paquetes de 576 bytes o menos. Con un encabezado IPv4 (mínimo de 20 bytes y máximo con opciones de 60 bytes) y un encabezado UDP de 8 bytes, un datagrama DNS con una carga útil de 512 bytes será menor que 576 bytes. Y también es verdad que DNS puede utilizar TCP para cargas grandes y para transferencias de zona y DNSSEC, pero eso añade una latencia innecesaria debido al desafío en tres vías de TCP. -&gt;syn &lt;-ack &lt;-syn -&gt;ack Esto de todos modos lo podéis leer en el punto 2.3.4 de la RFC 1035 «DOMAIN NAMES – IMPLEMENTATION AND SPECIFICATION» titulado Size Limits donde pone: <blockquote>labels 63 octets or less names 255 octets or less TTL positive values of a signed 32 bit number. UDP messages 512 octets or less</blockquote> Pues para poder transmitir más información en el año 1999 Paul Vixie, que trabajaba en ISC, se sacó de la manga un estándar titulado «Extension Mechanisms for DNS (EDNS0)», lo podéis leer en la <a href="https://tools.ietf.org/html/rfc2671" rel="noopener noreferrer nofollow" target="_blank">RFC 2671</a>, luego vino la <a href="https://tools.ietf.org/html/rfc2673" rel="nofollow" target="_blank">2673</a> y finalmente la <a href="https://tools.ietf.org/html/rfc6891" rel="noopener noreferrer nofollow" target="_blank">6891</a>, que oh sorpresa está escrita por Vixie, Graff y nuestro buen amigo Joao Damas ya vino a contarnos el traspaso de la KSK en el <a href="https://www.eduardocollado.com/2018/09/19/podcast-175-traspaso-de-la-ksk-en-la-zona-raiz-con-joao-damas/" rel="noopener noreferrer nofollow" target="_blank">capítulo 175</a>. Al principio el objetivo era permitir respuestas más largas sin perder la compatibilidad con lo ya establecido y luego la cosa se fue completando. Para que esto funcionara no se podía modificar la cabecera de DNS porque ya estaba llena, así que se utilizaron los registros de tipo OPT y es aquí donde indicamos la cantidad de información a transmitir gracias a las 16 opciones adicionales añadidas. Esto aunque os parezca una cosa sin importancia es vital para DNSSEC ya que no cabe la información en datagramas de 512 bytes. Pero hay más extensiones, como la identificación de instancia del servidor NSID, identificar desde qué red viene la consulta con Client-Subnet, controlar los timeouts variables con Keep-alive, el mecanismo de seguridad Cookies. En fin hay y habrá más. El primer problema surge antes de llegar el datagrama porque muchos firewalls filtraban, algunos aún lo hacen, el tamaño máximo de UDP a 512bytes y claro, todos estos datagramas son o eran descartados, mala cosa. Al permitir datagramas UDP más grandes para los DNSs en los firewalls al final conseguimos facilitar los famosos ataques de amplificación, en los que hacemos una pregunta muy pequeña para recibir una respuesta muy grande. Todo esto nos ha llevado a utilizar los DNSs de forma poco óptima por culpa de aquellos que no se han adherido a los estándares. Actualmente tenemos tres problemas principales: <ul> <li>DNS autoritativos que bloquean respuestas</li> <li>Malas implementaciones de DNS que no siguen los estándares. Esto provoca entre otras cosas que algunos resolvers tengan que esperar timeout y reintentar con TCP o sin EDNS y claro … va lento.</li> <li>Firewalls mal configurados que bloquean el tráfico que sigue a los estándares</li> </ul> Pero todo esto se solucionará el 1 de Febrero con las nuevas versiones en paralelo de Bind, PowerDNS, Unbound y Knot que dejarán de funcionar con parches históricos para que pudiera funcionar todo el Mundo, hasta los que no seguían los estándares, pero eso se acabó, no se puede seguir avanzando manteniendo parches para aquellos que no han realizado su trabajo. Además, el cambio del día 1 tiene una cosa muy interesante, no van a caer inocentes, van a fallar aquellos que no se han adaptado al estándar y por desgracia, estos si que no tienen culpa, sus clientes y usuarios. Enlaces: <a href="https://www.lacnic.net/innovaportal/file/3207/1/edns-flag-day.pdf" rel="noopener noreferrer nofollow" target="_blank">https://www.lacnic.net/innovaportal/file/3207/1/edns-flag-day.pdf</a>

DNS Flag Day con Adrian Almenar

The best podcast episodes of anyone with an interesting story. With famous guests like Obama, LeBron James, Drake, Oprah Winfrey, Richard Branson, Michelle Obama, Serena Williams, to anyone who has a unique and interesting story to tell. Add episodes you're interested into your queue below!

Best Episodes: Personal Stories & Great Interviews

The best philosophy podcast episodes. Asking questions about how to live a better life, what it means to be and do good, to the idea of God. This topic includes episodes that bring about important questions that everyone should be asking themselves. Add episodes you're interested into your queue below!