La app de Linux, a fondo

Esta es la inmersión a fondo: cada superficie importante de la app de Linux, qué controla, sus valores por defecto y cómo arreglarla cuando algo se rompe. Asume que ya instalaste y conectaste. Si no, empieza por los primeros pasos. Para saber cómo funciona la red detrás de la app, lee la visión general.

El cliente de Linux es una app de escritorio GTK4/libadwaita sobre un demonio root de systemd, distribuida como un AppImage más un .deb. Todo es código abierto en github.com/urnetwork/linux.

Los ajustes de un vistazo

Los valores por defecto te protegen sin configurar nada. Los controles de conexión viven en el panel de conexión; compartir conexión está en los controles de la pantalla principal; el ajuste manual de la ubicación del dispositivo está sobre el globo de proveedores conectados.

Salvedades que acompañan a la tabla:

• Desactivar Anonimización fuerte es el modo directo: el cliente habla directamente con el proveedor y va más rápido, y ese proveedor pasa a ver tu dirección real. El valor por defecto protege tu identidad. Gástala a propósito.
• El kill switch también decide qué pasa con un paquete que el filtro de seguridad descarta (ver compartir conexión): activado, se bloquea de plano; desactivado, sale por tu ruta normal.
• El túnel dividido por aplicación no está disponible en Linux. Las reglas de división son de nivel dominio e IP.
• Eliminar tu cuenta tampoco está en Linux. Hazlo en la app web en ur.io, que gestiona la misma cuenta.

La división con el demonio

Dos programas, dos niveles de privilegio:

• urnetworkd es un demonio root gestionado por urnetworkd.service, sin ninguna dependencia de GUI. Incrusta el DeviceLocal del SDK, abre y posee /dev/net/tun, bombea paquetes por el bucle de E/S del SDK y aplica rutas y DNS. Lo instala el .deb o el tarball de instalación.
• urnetwork es la app de escritorio, gtkmm-4.0 y libadwaita, ejecutándose como tu usuario normal y distribuida como AppImage. Sostiene un DeviceRemote: una vista del dispositivo del demonio, no un dispositivo propio.

Hablan por dos canales:

1. El RPC de dispositivo. El DeviceRemote de la app maneja el DeviceLocal del demonio por el RPC TLS mutuamente autenticado del SDK en loopback, 127.0.0.1:12025, el mismo transporte que usa la app de Windows.
2. El socket de control. Un socket de dominio unix en /run/urnetwork/control.sock lleva el ciclo de vida del túnel: levantar el túnel, tumbarlo, fijar el modo de compartir, informar del estado del demonio.

El socket unix es la frontera de autorización real. El TCP de loopback es alcanzable por cualquier proceso local, y por eso el RPC de dispositivo va mutuamente autenticado con certificados. Pero nada arranca un túnel sin pasar por el socket unix, donde el propio kernel le dice al demonio qué usuario pregunta (SO_PEERCRED, comprobado antes de analizar un solo byte de la petición, y autorizando por id de usuario, nunca por id de proceso). El directorio es 0750 root:urnetwork, el socket 0660, y la regla es: root, o un miembro del grupo urnetwork.

Mover también el RPC de dispositivo a un transporte unix es un seguimiento registrado en el SDK; las notas de diseño declaran la limitación del loopback en lugar de tratar el loopback como privado.

Las dos mitades deben coincidir

Linux es la primera plataforma de URnetwork donde la app y el túnel se actualizan por separado: el AppImage se autoactualiza como tú, el demonio se actualiza por apt. Así que la app comprueba dos cosas al conectar: la versión del protocolo de control, y que ambas mitades llevan exactamente la misma compilación del SDK. Un desajuste se rechaza de entrada con un mensaje distinto para cada caso (servicio no en marcha, servicio desactualizado, app desactualizada, compilaciones distintas) porque cada uno tiene un arreglo diferente, y un túnel que funciona a medias en silencio es peor que un error.

Cómo se instalan las piezas

Ambas mitades vienen de la página de versiones: .deb, .install.tar.gz y .AppImage, amd64 y arm64, con un suelo de glibc 2.35 que significa Ubuntu 22.04 o Debian 12 y más recientes. No hay ficha en ninguna tienda.

El paquete posee todo lo privilegiado y estable: el demonio en /usr/lib/urnetwork/urnetworkd, su unidad de systemd, la entrada de escritorio, los iconos, los datos del mapa mundial de los que dibuja el globo, las traducciones y un lanzador en /usr/bin/urnetwork.

El AppImage de la GUI nunca lo instala el paquete. Vive en tu directorio personal (~/.local/lib/urnetwork/URnetwork.AppImage), escribible por el usuario para poder reemplazarse sin root. El lanzador busca en una lista fija de ubicaciones ($URNETWORK_APPIMAGE, luego ~/.local/lib/urnetwork/, luego ~/Applications/, luego /usr/lib/urnetwork/, luego cualquier urnetwork-gui en el $PATH) y ejecuta el primer acierto; sin ninguno instalado imprime una pista de una línea diciéndote dónde conseguir uno.

El demonio corre con el privilegio que necesita y renuncia al que no: NoNewPrivileges, ProtectHome (no tiene interfaz y no debe leer jamás los directorios personales de los usuarios), PrivateTmp, directorios de estado y logs solo de root. Está ordenado respecto a network-pre.target, el hueco que una VPN necesita para poder actuar antes de que la red se levante, y está siempre en marcha en lugar de activado por socket, porque una unidad arrancada perezosamente no puede participar en ese orden en absoluto.

Rutas

Cuando el túnel se levanta, el demonio no reemplaza tu ruta por defecto. La supera en la puja, como hace wg-quick:

• Añade rutas a través de la interfaz del túnel (urnet0) que cubren todo el espacio IPv4 excepto los rangos de LAN privados: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
• Son más específicas que tu 0.0.0.0/0 por defecto existente, así que ganan sin tocarlo. El desmontaje es solo quitarlas; tu enrutamiento original nunca se modifica.
• Excluir los rangos privados mantiene funcionando tu impresora, tu NAS y tus servicios locales mientras estás conectado, el mismo comportamiento que los clientes de Android, Apple y Windows.

A NetworkManager se le dice que no toque: urnet0 se marca como no gestionada mediante un drop-in de configuración de NetworkManager y una regla de udev, así que el gestor de red del escritorio nunca pelea con el demonio por la interfaz.

DNS

El DNS del enlace del túnel se establece a través de systemd-resolved (resolvectl), el resolvedor estándar de los escritorios Ubuntu: los resolvedores del enlace se apuntan a los de la red, con ~. para que las consultas se enruten por él, y todo se revierte en el desmontaje. No todo sistema ejecuta resolved, así que el comportamiento es de mejor esfuerzo por diseño:

• Con systemd-resolved: el DNS del enlace del túnel se captura y restaura.
• Sin él: el túnel sigue enrutando, pero el DNS de ese enlace no se captura. Tus consultas siguen usando el resolvedor que el sistema tuviera.

Una sutileza más: un dominio de búsqueda entregado por DHCP (lan, home) es una coincidencia más larga que ~. y le ganará para los nombres de ese dominio. Si usas una configuración de resolvedores inusual, comprueba adónde va de verdad tu DNS.

La propia hoja de DNS personalizado de la app es el control más significativo. Edita los ajustes de resolvedor del SDK, cuyo valor por defecto es DNS cifrado sobre HTTPS resuelto a través del túnel. Ofrece resolución DoH y sin cifrar, remota o local, listas de servidores editables por familia, un interruptor de respaldo de DNS local que hace competir a un resolvedor local mientras el túnel arranca para que las consultas no se atasquen, recomendaciones regionales para lugares donde se sabe que la configuración más estricta se rompe, y una acción para restaurar los valores seguros.

La bandeja

El icono de estado es un StatusNotifierItem con un menú com.canonical.dbusmenu, hablado directamente por GDBus: el protocolo que KDE y la mayoría de los paneles soportan de forma nativa, y GNOME soporta a través de la extensión AppIndicator. Sin anfitrión de bandeja presente, la app no muestra icono en lugar de fallar.

Cerrar la ventana la oculta en la bandeja y mantiene el túnel funcionando. El menú lleva conectar/desconectar, mostrar y salir. Salir es aquí la salida real: termina la sesión y tumba el túnel. En el día a día quieres el botón de cerrar, no salir.

La ventana

Primero el inicio de sesión, luego la vista principal: el control de conexión, el globo de proveedores y el panel. El inicio de sesión acepta un código por correo o teléfono, Crear cuenta (Create account), un código de autorización generado en un dispositivo donde ya tienes sesión, o una firma de cartera a través de Solana (Phantom, Solflare) o Bittensor. También está ahí un botón heredado Probar modo invitado (Try Guest Mode). Acuña una cuenta permanente corriente en el servidor, pero esta app tira la frase de recuperación que vuelve con ella, así que usa una de las otras vías si quieres poder recuperar la cuenta después.

El globo de proveedores se dibuja desde una topología mundial empaquetada con la app. No se descargan teselas de mapa, así que nada del mapa que estás mirando sale de tu máquina.

El panel de conexión lleva la sesión:

• La tarjeta de controles de conexión. La ubicación seleccionada, un modo de conexión de Auto, Web o Streaming, y cuatro conmutadores: IP fija, Anonimización fuerte, Cifrado poscuántico y el kill switch (interruptor de corte). El modo elige qué ventana de proveedores corre: Web es la ventana de calidad (2–6 proveedores a la vez), Streaming la de velocidad (1–2), y Auto ejecuta ambas en paralelo, y por eso una sesión corriente suele tener 3–8 proveedores abiertos, no uno. Anonimización fuerte es lo que prohíbe una ruta directa cliente-proveedor, así que ningún proveedor ve jamás tu dirección real; desactivarla es el intercambio del modo directo de la tabla de arriba. Cifrado poscuántico sella la sesión en sí (ver el panel de identidad abajo).
• Las tarjetas de estadísticas del cliente y locales con gráficas en vivo, cada una abriendo una hoja de detalle.
• El estado de DNS personalizado, que abre el editor de resolvedores de arriba.
• Bloquear anuncios y rastreadores.
• Plan y uso. Tu nivel, la barra de usado/pendiente/disponible, las filas de cuota diaria e invitaciones, Obtener UR Pro (Get UR Pro) y el canje de un código de saldo.
• El panel de identidad poscuántica (abajo).

Hojas, cada una una pantalla real y no un esbozo:

• Ubicaciones. Las secciones agrupadas del SDK: primero los pares de tu red conectados, luego el mejor disponible, luego países con recuentos de proveedores en vivo. Teclear en la caja de búsqueda añade mejores coincidencias más regiones, ciudades y dispositivos. Una ciudad aquí es algo que se busca, no algo a lo que se llega desplazándose.
• Proveedores conectados. Un globo sobre una fila por proveedor actualmente en tu ventana, la conexión más antigua primero, con id de cliente, ciudad/región/país, coordenadas, duración y un quitar en línea.
• Contratos. Los contratos de transferencia en vivo detrás de tu sesión, una pila por par, con envío y recepción separados.
• Reglas de división. Reglas de nivel dominio e IP que fuerzan tráfico concreto a tu conexión local, sobre un feed en vivo de lo que se está aplicando.
• Canjear código. Aplica un código de saldo, con el historial de los que has canjeado.
• Mejorar. UR Pro mensual o anual a través del checkout de Stripe, incrustado en la app donde el sistema tiene WebKitGTK, y recurriendo a tu navegador en caso contrario, porque una vía de pago no debe fallar en firme jamás.

Hoy no hay pantalla aparte de Cuenta, Cartera ni Clasificación en Linux. El plan y el saldo viven en el panel y en la hoja de canje, y los ajustes de la cuenta viven en la app web en ur.io. El cierre de sesión está en la vista principal.

El ajuste manual de la ubicación del dispositivo

Linux recibe una versión real de lo que Android llama "sincronizar la ubicación del dispositivo": a las apps que preguntan al sistema dónde estás se les pueden decir las coordenadas del proveedor al que llevas más tiempo conectado, en lugar de tu ubicación real. El conmutador está sobre el globo de proveedores conectados, con una guía de configuración, y está desactivado hasta que lo enciendas.

El mecanismo es estrecho. GeoClue, el servicio al que las apps de escritorio piden la ubicación, tiene una fuente estática que lee una posición fija de /etc/geolocation y vigila los cambios del archivo. Ese archivo es el único punto de inyección y vive bajo /etc, así que la escritura la hace el demonio por el mismo canal de control; la GUI nunca lo toca y nunca necesita root.

La guía declara sus límites directamente. Necesita GeoClue 2.7.0 o más reciente, que no está en todos los sistemas; Ubuntu 22.04 y Debian 12 traen una versión más antigua y no pueden satisfacerlo jamás. Y mueve solo lo que GeoClue informa: Ajustes y Mapas de GNOME, Firefox y las apps Flatpak y Snap en sandbox lo siguen. Chrome y KDE Plasma no preguntan nunca a GeoClue, nada que deduzca tu ubicación de tu dirección IP se ve afectado, y Firefox recurre a su propia consulta si el sistema responde despacio. También cambia la ubicación informada a todas las apps de la máquina, no solo a URnetwork. Todo lo demás de la app funciona igual en cualquier caso.

Compartir conexión

Compartir está desactivado por defecto, y los controles de la pantalla principal ofrecen Auto, Siempre (Always), Red (Network, solo los dispositivos de tu propia cuenta) o Nunca (Never). Los proveedores participan en el protocolo UR; ur.xyz documenta cómo funcionan las recompensas.

Lo que te protege cuando compartes es la capa ip_security de código abierto del motor connect. Ejecuta inspección profunda de paquetes en tu propia salida y descarta el tráfico de clase DMCA (firmas con seguimiento de estado de BitTorrent e intercambio de archivos, descartes de protocolo opaco) y el de clase CFAA (patrones de ataque e intrusión) antes de que salga de tu máquina. El mismo filtro corre también sobre tu propia ruta de envío como usuario corriente, actives o no el compartir, así que tu tráfico se juzga en tu máquina antes de llegar a ningún proveedor.

Con una coincidencia el paquete se descarta, sin destino, dominio ni contenidos registrados. Una firma de BitTorrent en tráfico que transportas para otro levanta además una señal de abuso al operador que lleva solo el id del dispositivo emisor y un booleano, y el operador no incluye hoy ningún gestor para ella. Un flujo cifrado opaco es un descarte simple que no reporta nada en absoluto. El sellado no esquiva el filtro, porque corre donde el tráfico sale. Y el kill switch decide la suerte de un paquete de clase descartada desde tu propia máquina: desactivado, sale por tu conexión local; activado, se detiene.

El panel de identidad poscuántica

El panel muestra la identidad de sesión de este dispositivo: un identicon, el hash de clave canónico y el id de cliente (clic para copiar), una baraja de las identidades de proveedor con las que has establecido sesiones verificadas, la lista completa de identidades de proveedor y un diálogo de compartir para comparar tu huella fuera de banda.

Lo que hace el ajuste: Cifrado poscuántico sale activado de fábrica, y mientras lo está tu cliente sella el tráfico de extremo a extremo hasta el proveedor sobre una sesión negociada con X25519MLKEM768 (híbrido clásico más ML-KEM). Ese tramo sellado es lo que ciega al salto de en medio: el operador transporta bytes que no puede leer. Falla en cerrado: mientras el ajuste está activado el cliente no envía ni acepta datos de aplicación en claro, así que un proveedor con el que no logra establecer esa sesión queda descartado en vez de usarse sin sellar; el coste es perder un proveedor, no perder el cifrado, y no te pueden degradar en silencio. Toda compilación actual de proveedor habilita el lado que responde, así que el descarte es raro. Desactiva el ajuste y el tráfico puede volver a tomar la ruta TLS-hasta-plataforma estándar. Las firmas de identidad siguen siendo Ed25519 y el cifrado es AES-256-GCM. "Poscuántico" significa este intercambio de claves, nada más amplio.

Qué hace la red por debajo

Tu tráfico recorre cuatro tramos: tú → extensor → operador → proveedor → internet. El extensor es un salto de alcanzabilidad que reenvía tu sesión cifrada sin leerla; como tu primer salto, sí ve tu dirección. La visión general explica la ruta completa, por qué se detiene en cuatro tramos y las ventanas de proveedores.

Lo que importa para los controles de esta app es el reparto entre las dos partes retransmisoras. El proveedor nunca sabe quién eres, porque el operador se interpone. El operador no puede leer lo que envías, porque el Cifrado poscuántico sella la sesión de extremo a extremo hasta el proveedor por defecto. Ambas cosas se cumplen en una instalación de fábrica, así que ninguna parte por sí sola reúne tu identidad y tu actividad. Los tres estados que producen los dos conmutadores:

El modelo de amenazas trabaja estas filas frente a adversarios con nombre y es explícito sobre dónde falla cada una.

Del lado del operador hay poco que conservar: los registros de conexión guardan un hash unidireccional con clave (revuelto con una clave secreta) de tu bloque de IP y no la dirección, el registro de contratos guarda ids de cliente y recuentos de bytes sin destino, host, URL ni dominio en ninguna parte, y la ruta de datos no registra nada. Una consulta geográfica sí anota una ciudad aproximada por conexión; lo que alcanzas a través de ella no se registra en absoluto. Ninguna auditoría independiente cubre el protocolo ni el código de servidor del operador (las dos evaluaciones de terceros de 2025 cubren otras superficies: una prueba de penetración de la aplicación web y la API, y una evaluación MASA AL2 de Leviathan superada sobre la app de Android, no el cliente de Linux). Las comprobaciones que existen en su lugar son el propio código abierto, comprobable continuamente por cualquiera, y el diseño de la salida: la salida es una flota descentralizada de proveedores operados por separado y no un único custodio que lo tiene todo. Límite: cómo de independiente es de verdad esa flota nunca se ha medido, y nada impide que el operador ejecute proveedores propios (modelo de amenazas §6.1).

Límites

• El kill switch sale desactivado de fábrica. Es un conmutador real en el panel de conexión, pero hasta que lo actives, el tráfico recurre a tu conexión normal cuando ningún proveedor está arriba en lugar de detenerse. El panel lo aplica en vivo por el RPC de dispositivo y el demonio restaura tu elección en el siguiente arranque.
• Solo IPv4 por el túnel. IPv6 no se enruta por él, así que en una red con IPv6 un sitio capaz de v6 aún puede ver tu dirección real. Desactiva IPv6 en la conexión si necesitas que todo salga por un proveedor.
• Sin túnel dividido por aplicación. Las reglas son de nivel dominio e IP.
• Sin inicio de sesión con Google ni Apple.
• La captura de DNS depende de systemd-resolved, como se describe arriba.

Resolución de problemas

"El servicio del sistema URnetwork no está en marcha" (The URnetwork system service is not running)

Comprueba el demonio y su socket:

systemctl status urnetworkd
journalctl -u urnetworkd -f

El demonio narra lo que configura y lo que restaura, así que este es el primer sitio donde mirar los problemas de levantado del túnel, rutas y DNS. Los logs de la GUI se quedan en tu sesión de usuario, separados de la mitad privilegiada, que es el sentido de la división.

Si el demonio está en marcha y la app sigue sin poder alcanzarlo, probablemente no estás en el grupo urnetwork: id -nG te lo dirá. Añádete con sudo usermod -aG urnetwork "$USER" y cierra sesión y vuelve a entrar.

"El servicio está desactualizado" / "compilaciones distintas" (The service is out of date / different builds)

Actualiza ambas mitades a la misma versión: el demonio instalando el .deb más nuevo (o volviendo a ejecutar install.sh del tarball más nuevo), y el AppImage en ~/.local/lib/urnetwork/. La comprobación existe para que una instalación actualizada a medias lo diga en lugar de portarse mal en silencio.

El AppImage no arranca

Ubuntu 22.04+ no trae libfuse2 por defecto y los AppImage lo necesitan. El .deb declara esa dependencia, así que instalar el paquete del demonio suele resolverlo; si no, instala libfuse2 (o libfuse2t64 en versiones más nuevas). Comprueba también que el archivo es ejecutable.

No hay icono de bandeja

Tu escritorio no tiene anfitrión de StatusNotifierItem. En GNOME, instala la extensión AppIndicator; KDE y la mayoría de los paneles lo soportan de forma nativa. La app funciona bien sin uno: cerrar la ventana solo la oculta, y la reabres desde el menú de aplicaciones.

Los enlaces urnetwork:// no hacen nada

El inicio de sesión con cartera vuelve a través de un enlace urnetwork://, que necesita la base de datos de escritorio refrescada tras la instalación. Ejecuta update-desktop-database ~/.local/share/applications (o la ruta del sistema con sudo). La instalación empaquetada lo dispara por ti; una instalación manual puede no haberlo hecho.

La interfaz existe pero nada se enruta

Comprueba que NetworkManager no está gestionando urnet0. El paquete incluye un drop-in de configuración y una regla de udev que la marcan como no gestionada, y ambos necesitan una recarga (nmcli general reload conf, udevadm control --reload), que el instalador hace.

En otros lugares

La visión general explica la red de extremo a extremo: proveedores, contratos, lo que cada parte puede ver y no ver, y el cifrado. Las preguntas frecuentes responden las dudas comunes. Otras plataformas: Android, iOS, macOS, Windows y el navegador.