Últimas Noticias

Hola, che! Hoy te traigo una tecnología que capaz es la más grosa y omnipresente en la vida de los administradores y operadores de sistemas. Estamos hablando de la tecnología VPN, y no es de sorprender que, mientras seguimos con nuestra serie RouterOS 7, estemos chusmeando una nueva funcionalidad que se viene en RouterOS 7, WireGuard. Mirá todo lo que tiene para ofrecer WireGuard y cómo nos ayuda comparado con las soluciones VPN a las que estábamos acostumbrados.

Hasta ahora, conectábamos a nuestros clientes a la red usando algún tipo de solución VPN basada en conexiones. Solo para darte unos ejemplos de nuestra vida diaria, antes usábamos PPTP, después L2TP, L2TP con IPSecs, y quizás SSTP, pero de alguna manera todos tenían sus quilombitos. Si volvés al principio de la lista, por ejemplo, la habilidad NAT. Como sabemos, con PPTP, hay un problema jodido de cómo hacer que todo ese tráfico entre desde una red NAT, o incluso a una red NAT. Estoy hablando específicamente de las conexiones GRE relacionadas.

Y de hecho, todas las tecnologías VPN que te mencioné -capaz con la excepción de SSTP solito- no tienen comportamientos garcas ni cositas garcas que nos causen a los administradores molestias constantes. WireGuard al final va a sacar todo esto de nuestras vidas con un truquito interesante, una solución copada y tecnología. Pero claro, nada es gratis, así que vamos a tener que bancarnos algunas molestias ahora. Veamos cuáles son.

No hay una conectividad posta pasando. Entonces, hay un intercambio de información entre el servidor y el cliente, pero no es una conexión clásica que caduque o se interrumpa o tenga que reestablecerse cuando cambie la IP. El protocolo en sí está diseñado para soportar flexibilidad e incluso roaming. Entonces, en serio, la onda era que si mi compu o mi dispositivo móvil cambia su dirección IP pública porque estoy en roaming en, por ejemplo, una red LTE o móvil, mi túnel VPN no debería cortarse y no debería tener que reconectar. Entonces, en serio, el concepto en sí se construye alrededor de eso, y así nació esta solución, la forma en que se comporta el protocolo ahora. Una cosa muy piola.

Y mientras hablamos de las fallas de los viejos protocolos VPN, mencionamos SSTP. SSTP ahora está cerca de ser, digamos -entre comillas-, una buena solución para nosotros: VPN SSL, habilitada para proxy, es relativamente fácil de atravesar NAT, ya que todo lo que necesitás es NAT o proxy en un puerto TCP 443 dependiendo de la situación en la que estés. Sin embargo, se basa en TCP. Y sabemos cuál es el problema con las soluciones basadas en TCP, con las VPN hay múltiples retransmisiones, múltiples envíos de reconocimientos. No sólo los datos en sí tienen que ser reconocidos muchas veces, sino que el propio canal utiliza el reconocimiento para asegurar que sus propios paquetes lleguen a su destino. Entonces, lamentablemente, esto costará demora, jitter – obviamente si hay pérdida de paquetes. Todo esto suele solucionarse con las VPN basadas en UDP. Ahora, WireGuard es una de esas VPN, así que obviamente se comunica en base a UDP. Va a ser conexión y estado, así que no tenemos que preocuparnos por la conexión, ni por la conexión que no se caiga, ni que los paquetes siempre vengan de la misma dirección IP. Lo hace re piola y utiliza un método de asignación de direcciones IP que es una tabla, un mecanismo, donde en realidad usa estas galletitas criptográficas para emparejar al cliente con el servidor.

Obviamente, de un lado, siempre tenés que poder nombrar al compañero, al otro lado, donde lo podés dirigir por primera vez, pero a partir de ahí, el proceso es automático, loco. Y el comportamiento, como mencioné antes, es muy parecido a la solución MOSH, que es muy similar al acceso SSH y SSH basado en llaves, donde tenemos llaves privadas y públicas, compartimos nuestras llaves públicas y eso será la base de la comunicación, así encriptamos los datos, así nos identificamos entre nosotros, entonces es una solución bastante segura.

También hay que agregar que estas soluciones de encriptación y hashing se están llevando a cabo actualmente con la tecnología más moderna y eficiente. Podés chequear la página web para ver exactamente cuáles son estos algoritmos. Desafortunadamente, el sistema es intencionalmente y por diseño inflexible en términos de encriptaciones, algoritmos de hash y otras soluciones embebidas, ya que están cableadas en la aplicación. Entonces, si ahora, desafortunadamente, mañana resulta que uno de estos algoritmos de curva elíptica es vulnerable y su resultado es fácil de predecir, entonces estos clientes y software tendrían que ser reemplazados.

Entonces, tenemos que tener esto en cuenta al planificar, digamos, un sistema empresarial grande, con muchos cientos de usuarios – aunque ojalá no, porque creo que WireGuard básicamente no es para eso – pero para una conexión entre muchos puntos finales de sitio a sitio, así que entre routers o para una red administrativa con muchos clientes, tenemos que tener en cuenta que sólo elegiremos un sistema así si podemos vivir con eso. Si algo resulta, lo podemos reemplazar muy rápidamente, incluso en unos pocos minutos.

Entonces, desde ese punto de vista – ya hablé de las llaves públicas – la configuración de los compañeros en sí, los participantes de la comunicación, es muy simple. De hecho, se creará una especie de tabla de enrutamiento criptográfico, en la que el sistema identificará a sus clientes en base a las diferentes llaves públicas y hará diferentes definiciones de subredes hacia ellos. Lo veremos durante la configuración, por eso tengo la compu delante de mí, esto ya no es solo chamuyo, te voy a mostrar detalles de configuración. No solo desde el lado de RouterOS, sino también la configuración de clientes específicos en detalle, y juntos veremos para qué sirven los parámetros y cómo interpretarlos según la terminología de WireGuard.

Te cuento algo importante: WireGuard es una VPN de Capa 3, así que no esperes que el tráfico que fluya a través de ella sea puenteable, lamentablemente no vamos a poder hacer un puente con tramas Ethernet en esto, pero a cambio, el uso de los protocolos IPv4 e IPv6 se tuvo en cuenta durante el diseño. Entonces, es capaz de tunelización 6to4 o 4to6, pero también solo IPv6 o solo IPv4. La siguiente pregunta que suele surgir acerca de un túnel VPN, cuando estás en el mundo de los protocolos es, bueno, cuánta es la sobrecarga? La sobrecarga siempre nos preocupa por la fragmentación y posibles pérdidas. Bueno, tengo malas noticias. Es bastante grande. Entonces, por ejemplo, para IPv6, tenemos que esperar una sobrecarga de 80 bytes, mientras que para IPv4, si podemos proporcionarla y podemos comenzar la configuración para usar solo IPv4, tenemos que esperar una sobrecarga de 60 bytes, que no es poco. Veremos que cuando miramos una interfaz WireGuard en RouterOS, básicamente cuenta como una operación de doble pila, por lo que puede tener una dirección v4 o v6 para dicha interfaz, así que veremos MTU de 1420 bytes allí. WireGuard, además de ser una solución VPN relativamente simple y fácil de usar, también son bastante rápidos, loco. Mirá esta tabla de comparación. Si lo comparás con el simple OpenVPN, verás que la velocidad de operación del sistema aumenta casi cuatro veces. Ahora, obviamente, si nos centramos en IPSec mientras tanto, esta ventaja de velocidad se reduce un poco, pero considerá que nuestros teléfonos móviles, o típicamente nuestras PCs de escritorio, notebooks, no están configurados para usar IPSec nativo. Entonces, de hecho, solo significarían una situación competitiva de la que estábamos hablando de una solución de sitio a sitio entre un router y otro router, pero debería señalar que IPSec también es una solución de cifrado relativamente moderna. Entonces, por ejemplo, ChaCha, y podés ver AES en la tabla. Obviamente, esta ventaja de velocidad proviene del hecho de que WireGuard se basa en UDP, no tenemos que lidiar con la pérdida de múltiples retransmisiones, y también utiliza el método de cifrado ChaCha que es terriblemente rápido, casi a la velocidad del cable, con las CPU modernas de hoy en día. Entonces, realmente no necesitamos preocuparnos por si nuestro sistema o CPU en particular admite esta solución en hardware o no. De hecho, el protocolo puede admitir velocidades muy altas a partir de la potencia bruta. Al lado de él, en la otra tabla, podés ver los tiempos de latencia para comparar. Obviamente, el valor más bajo es mejor aquí. Vemos que WireGuard tiene una latencia significativamente menor para configuraciones similares bajo condiciones de transmisión similares. Entonces, definitivamente podemos ver y experimentar que sí, este protocolo VPN puede ser bueno para nosotros.

Ahora, vamos a ver un dispositivo enseguida. Tengo un RouterBOARD con RouterOS 7.4.1 frente a mí, y luego en su consola veremos cómo entramos en los detalles de configuración de WireGuard. Empecemos con el ítem de menú WireGuard. Primero, en el menú Interfaz, en la pestaña WireGuard, tenemos que crear una nueva interfaz. Acá podés ver el tamaño de MTU y que el servicio en sí estará funcionando en el puerto 13231 por defecto. No te alarmes porque los campos de Clave Privada y Clave Pública no estén completados en este momento, de hecho, no necesariamente los necesitas. Obviamente, si querés mover alguna configuración existente aquí, tendrás que completarlos. Básicamente, si los dejás en blanco, verás que el sistema los genera después de agregarlos. Obviamente, necesitaremos la clave pública, así que es recomendable copiarla al portapapeles, porque definiremos y agregaremos esta clave pública a nuestro cliente remoto.

Después de eso, lo que tenemos que hacer es el siguiente paso, que es definir la dirección IP o el rango de IP con el que nuestra interfaz WireGuard debería operar. Voy a tomar una dirección IP aquí de 10.70.70.1 con una máscara de red de 24 y asignarla a la interfaz WireGuard 1. Intentaremos acceder a esta dirección IP desde nuestros clientes. Ahora veamos la configuración de los peers.

Pasando a agregar peers, algo muy importante que debería llamar nuestra atención de inmediato es que no podemos agregar un peer sin conocer la clave pública del peer. Para esto, primero instalaremos el cliente WireGuard en una computadora con Windows 10. Podés hacer esto yendo al sitio web wireguard.com y, en la pestaña de instalación, encontrarás los paquetes para los diferentes sistemas operativos; descarga el paquete de Windows. La instalación se realiza en cuestión de momentos, por cierto, el paquete de instalación en sí carga el kit desde el sitio web de WireGuard, y una vez que se inicia la interfaz de configuración, podemos y debemos hacer nuestra primera configuración.

Aquí, en «Agregar túnel», elijo crear un nuevo túnel en bruto. Y como ves, como en el caso de RouterOS, la clave pública ya está disponible aquí de inmediato. Esta es, por supuesto, la clave pública que tendremos que mencionar en la página de RouterOS, así que la de RouterOS en Windows y la de Windows en la configuración de RouterOS. Así es como se va a crear esta solución de enrutamiento de clave criptográfica.

Y una vez que estamos aquí en la configuración, y tenemos la clave pública, configuraremos el cliente Windows. Primero necesitamos la interfaz, seleccionamos una dirección IP del dominio en sí que definimos en el lado de RouterOS. Esta es la subred 10.70.70.0/subred 24, la dirección 1 está en el enrutador, la dirección 2 la tomamos aquí en el cliente de Windows. Opcionalmente, podemos elegir usar nuestro enrutador como DNS (servidor DNS). Lo dejaré sin comentarios aquí por ahora.

Y luego, también en el cliente de Windows, debes especificar el peer con el que debe contactarse. Para esto, necesito la clave pública de RouterOS, que ya inserté desde el portapapeles. Y ahora viene una directiva que ha sido malinterpretada por los usuarios durante mucho tiempo, este campo llamado «Allowed Addresses». En este campo es donde enumerás, y de hecho con una lista separada por comas, las subredes o direcciones IP a las que querés acceder y direccionar a través del túnel. De hecho, la selección de tráfico no se realizará de la misma manera que estamos acostumbrados en una VPN stateful, una VPN basada en conexiones, así que no estamos dirigiendo el tráfico hacia ella, sino que vamos a usar este selector, un selector de túnel, si querés, para seleccionar el tráfico basado en su dirección de destino, que el sistema luego exprimirá en estos túneles.

Y luego aquí, si continuamos con la configuración, voy a especificar la red 10.70.70, que en nuestro caso es en realidad la red WireGuard de nuestro RouterOS, pero podemos soñar más grande, incluso podemos especificar todo el dominio RFC 1918 y decir que esta es nuestra conexión WireGuard, que podrá enrutar o acceder a todas las direcciones IP privadas de nuestra red a través de este túnel.

Bien, lo siguiente importante es «Endpoint». Esta es en realidad la dirección y la ID del peer WireGuard, al cual tendrá que enviar el primer paquete. Así es como realmente contacta a su peer. Y una cosa más importante, es el parámetro «PersistentKeepAlive», que configuro y especifico intencionalmente, a pesar de que es opcional y no obligatorio, porque se trata de tráfico UDP. Y si este tráfico UDP está sujeto a la traducción de direcciones, es decir, si está sujeto a NAT por, digamos, nuestra rutina de casa o por nuestro proveedor de servicios a nivel de proveedor de servicios, entonces es ciertamente posible que, si no intercambiamos datos entre dos peers, no haya tráfico, no haya paquetes en marcha, entonces las tablas de seguimiento de conexiones pueden eliminar estas entradas y será necesario algún intercambio de paquetes para que WireGuard vuelva a crear las cookies criptográficas adecuadas y para que los peers se conozcan mutuamente otra vez. Esto se puede evitar configurando el parámetro KeepAlive en, digamos, 20 segundos. Esto incluso mantendrá vivo un recolector de basura de seguimiento de conexión relativamente estricto, de modo que las conexiones que soporten esta conexión no caduquen. Básicamente, un valor de 20 segundos en este campo, mucho menos o más puede no ser apropiado.

Bueno, eso es todo para nuestro cliente. Nuestro cliente de Windows ha guardado el túnel con sus parámetros, podés ver los parámetros de la interfaz arriba y los parámetros del peer abajo, los parámetros para el lado opuesto. Si mirás la clave pública, hay algunas cositas sobre ella. Un ojo de programador astuto detectará de inmediato que es una clave pública encriptada o hash MD5. Y, de hecho, me equivoco ahora mismo, porque es Base64. El protocolo parece que en realidad es una clave pública de 32 bytes, y para evitar tener caracteres en ella que no podamos representar, por precaución, se le da otro giro con Base64 para facilitar su representación con simples caracteres ASCII.

Tenemos nuestras subredes para «Allowed Address», tenemos nuestra dirección de Endpoint, hagamos clic en activar. La activación se realiza en cuestión de momentos. De hecho, lo que sucede en segundo plano es que, en función de nuestros parámetros de túnel, estos peers se conectan entre sí y tenemos esta tabla de enrutamiento de claves criptográficas en segundo plano. Esto realmente se inyectará en cierta capa del kernel, donde los paquetes que van en esa dirección serán exprimidos en nuestro túnel WireGuard definido por el sistema.

Bueno, ahora vamos a pasar al lado de RouterOS. Ya configuramos nuestra Windows, el cliente está iniciado, el túnel activado, pero obviamente el tráfico todavía no puede llegar al lado de RouterOS porque no tenemos ningún peer definido todavía, así que vamos a abrir de nuevo la pestaña de peers y agregar un nuevo peer. No hay mucho para configurar acá, solo tenemos que meter la clave pública generada por el cliente de Windows en el campo de clave pública, y en el campo de Dirección Permitida voy a poner la dirección IP de mi compu con Windows, así solo voy a meter datos que se envían desde esta dirección IP en este túnel específico. Y eso básicamente completa nuestra configuración. Volvamos a la página de Windows y revisemos la conexión. Podés hacer esto simplemente haciendo ping a la dirección IP 10.70.70.1 que configuramos en RouterOS. Responderá, así que nuestro túnel está vivo. Pero veamos cómo funciona en, digamos, un celular. Para esto te traje un iPhone 12. Y entonces nuestra primera tarea es descargar el cliente de WireGuard de la App Store. Vamos a buscar WireGuard. Por suerte, ya lo tengo instalado, así que acá está la configuración. Voy a agregar un túnel en crudo. Primero tengo que llenar el parámetro de nombre, cómo se llamará este túnel. Debajo de eso, hago clic en el botón Generar Keypair, esto generará la clave pública y privada. Vamos a necesitar la clave pública acá también, que tendremos que ingresar en la página de RouterOS. En el campo Direcciones ingreso la dirección que el cliente, el móvil en sí, recogerá al activar el túnel, esa es la dirección con la que realmente va a ser accesible. Y luego vienen los otros parámetros. La clave pública, por supuesto, tengo que copiarla del campo de clave pública definido en RouterOS. Punto final; aquí es donde tengo que ingresar la dirección IP de RouterOS, la dirección IP de mi router. El puerto es 13231, este fue el predeterminado. Y luego viene el campo Direcciones IP permitidas. Aquí simplemente voy a tomar una ruta predeterminada, es decir, voy a meter todo el tráfico de mi móvil en el túnel de WireGuard. Bueno, lo habilito… y la configuración está lista. Lo que básicamente activé arrastrando el pequeño interruptor. El ícono de VPN arriba muestra que la conexión está activa y funcionando. Y lo genial de esta solución es que en realidad nunca se desconectará. Podés moverte con tu móvil de una red a otra, de Wi-Fi a LTE, y así sucesivamente. Esta conexión siempre está viva y siempre enviará paquetes donde los necesites. Así que también es muy conveniente, por ejemplo, para acceder a tu servidor de archivos doméstico, NAS doméstico o dispositivos domésticos inteligentes, y así sucesivamente. Te lo recomiendo mucho. Lo he estado usando por mucho tiempo y debo decir que es una de las mejores y más flexibles tecnologías que he usado para VPNear. Veamos el lado de RouterOS, porque todavía no terminamos acá. Veamos cómo configurar este cliente de iPhone en el lado del router. Primero que nada, necesito la clave pública generada por el iPhone, la pondré aquí en el campo de clave pública. La dirección, oops, no 10.10, sino 10.70.70, este va a ser mi cliente con IPv n.º 3, y también establecí este tiempo de espera persistente de 20 segundos aquí. Verificación: haciendo ping y funciona bien. Genial, funciona desde el lado del router, pero veamos si obtenemos el mismo resultado desde el móvil. Tengo una aplicación simple de ping para esto, queremos obtener la dirección 10.70.70.1. Esta es, por supuesto, la interfaz de Wireguard del router en sí, y responde perfectamente a un ping. Y veamos, ya que redirigí el gateway predeterminado, ahora vamos a intentar hacer ping al DNS público de Google, también lo obtendremos. Pero el tráfico seguramente va por ese camino? Y no se escapa en, digamos, mi interfaz LTE? Hagamos también un traceroute. Vamos a hacer traceroute, por ejemplo, al DNS público de Google, y está funcionando por completo. Y podemos ver que este traceroute se realizó tocando el gateway 10.70.70.1, así que podemos estar seguros de que nuestra VPN funciona bien. Así que es así de simple configurar WireGuard.

Claro que podemos decir sí, pero dónde están los nombres de usuario, las contraseñas? Cómo habilitamos o deshabilitamos un cliente? No es un problema si puedo asignar accidentalmente la misma dirección IP a varios clientes? Y sí, lo es: desafortunadamente, ese es el inconveniente del protocolo. Entonces, para administrar esto, para llevar un registro de quién tiene qué claves públicas y cómo se construye mi tabla de enrutamiento criptográfico, esto tiene que registrarse en algún lugar, y no necesariamente recomendaría la configuración del router para esto. Me he encontrado con varios programas recientemente que están diseñados específicamente para configurar y registrar túneles de Wireguard e incluso para la llamada inscripción automática. Podés encontrar un millón de esos proyectos en Github.

Y ese es realmente el único inconveniente, pero los desarrolladores nunca afirmaron que traerían la nirvana a cada capa del sistema. A veces tenemos que hacer un poco de trabajo nosotros mismos, pero eso es realmente en lo que nos hemos acostumbrado como usuarios de MikroTik a lo largo de los años. Obtenemos una base relativamente estable, una tecnología confiable, un buen marco simple y tenemos que agregarle un poco más.

Ahora, solo una pequeña cosa que podemos usar para facilitarnos la vida es transferir y procesar la configuración mediante código QR. Esto se puede hacer de manera relativamente fácil, y hay un pequeño binario para esto que se ejecuta en Linux llamado QR Encode, pero hay innumerables proyectos por ahí en Internet que pueden hacer lo mismo, ya sea a través de un sitio web, o más específicamente a través de alguna aplicación web.

Eso es todo por WireGuard en RouterOS 7, ves que es fácil de configurar. Existe para varias plataformas, tiene clientes para Linux, Windows, dispositivos con Android, iOS, Mac OS, así que tiene un soporte bastante amplio, ¡TAMBIÉN PARA VYATTA, ASÍ QUE LOS ROUTERS UBIQUITI TAMBIÉN! y obviamente eso no va a cambiar, solo se expandirá. La única sorpresa, además de las muchas ventajas y la flexibilidad que aporta a nuestras vidas, son las desventajas que no debemos olvidar. Quizás uno de los más peligrosos es que funciona con algoritmos cableados, por lo que una vez que uno de ellos se encuentre defectuoso, tendremos que reemplazar los clientes en todas partes con versiones más nuevas. Pero hoy, cuando nos vemos obligados a actualizar constantemente nuestro software de todos modos, quizás este no sea un precio tan alto que pagar.

El siguiente problema es la administración de direcciones IP, porque desafortunadamente tenemos que conectar las direcciones IP de los clientes en sus configuraciones. Pero creo que un operador o administrador inteligente planificará esto de antemano de todos modos, y en sus tablas de IP designará los dominios o registros hacia o desde los que se dirigirá a estos clientes, pero es molesto, porque si tenemos que cambiar las direcciones IP en este medio, en este canal de comunicación de Wireguard, tendremos que volver a tocar la configuración de cada cliente. No se puede simplemente reescribir de manera centralizada, por ejemplo, un conjunto de pools, como estamos acostumbrados con SSTP u otros tipos de VPN conectados.

Y, por último, y quizás el más doloroso, es llevar un registro. Ya sabes, las claves públicas, no son información simplemente legible y responsable. Tienen que almacenarse en algún lugar en pares con sus claves privadas. Y, por supuesto, si estas claves se ven comprometidas, nuestra red puede verse comprometida, así que hay que tener cuidado con ellas, obviamente.

Quizás un defecto adicional, que he estado probando durante las semanas y meses al implementar VPN de Wireguard en ciertos sistemas, es que desafortunadamente las colisiones de IP pueden estar presentes en la vida de la red, en la vida de la malla de Wireguard, sin que el operador lo sepa. A lo que me refiero aquí es que la misma dirección IP desafortunadamente se puede dar a varios pares al mismo tiempo, e incluso pueden estar activos al mismo tiempo. Los clientes no son notificados y los pares no pueden notificarse entre sí de que hay una colisión de IP en la red, por lo que este es un problema grave.

Sospecho, o al menos tengo la sensación después de unos meses de experiencia con esto, que solo se puede resolver mediante registro o algún tipo de sistema de análisis. Así que estén atentos, lleven registros, registros, registros. Quizás esa sea una de las lecciones más importantes de esta implementación.

Gracias por seguirnos, y volvere con otra parte de RouterOS 7 pronto. Chau!