# 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](/docs/getting-started-linux). Para saber cómo funciona la
red detrás de la app, lee la [visión general](/docs/overview).

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](https://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.

| Ajuste | Valor por defecto | Efecto | Coste principal |
|---|---|---|---|
| Modo de conexión (Connection mode) | Auto | elige las ventanas de proveedores; Auto ejecuta calidad y velocidad juntas | Web o Streaming se estrechan a una ventana |
| Anonimización fuerte (Strong Anonymization) | Activado | oculta tu IP de origen al proveedor | más latencia |
| Cifrado poscuántico (Post Quantum Encryption) | Activado | cifra desde la app hasta el proveedor | descarta un proveedor que no puede sellar |
| Kill switch | Desactivado | impide el recurso a la ruta local cuando el túnel está caído | sin tráfico mientras los proveedores fallan |
| IP fija (Fixed IP) | Desactivado | un proveedor, una dirección de salida | sin relevo ante fallos |
| Bloquear anuncios y rastreadores (Block ads and trackers) | Desactivado | filtra el tráfico de anuncios y rastreadores | el filtrado puede romper algunos sitios |
| DNS personalizado (Custom DNS) | DoH cifrado vía túnel | el DNS queda cifrado y dentro del túnel | aflojarlo es el intercambio |
| Compartir conexión (Provide mode) | Nunca (Never) | comparte ancho de banda sobrante como salida para otros | el tráfico de desconocidos sale por tu IP |
| Ajuste manual de la ubicación del dispositivo (Device location override) | Desactivado | las apps que preguntan a GeoClue ven la ciudad de tu proveedor más antiguo | necesita GeoClue 2.7+; afecta a todas las apps de la máquina |
| Reglas de división (dominio/IP) | vacías | los destinos listados usan tu conexión local | ese tráfico va sin proteger |

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](https://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](https://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](https://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](/docs/overview) 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:

| Modo | El operador ve | El proveedor ve | Valor por defecto y disponibilidad |
|---|---|---|---|
| **Retransmitido sellado** | tu cuenta y conexión de origen, en qué proveedores estás, y texto cifrado con su tiempo y volumen | los destinos que saca a internet y un id de dispositivo/contrato, **no** tu IP real | el valor de fábrica: Cifrado poscuántico, activado en el panel de conexión |
| **Retransmitido estándar** | tu cuenta y conexión de origen, en qué proveedores estás, y los destinos y bytes de paquete del interior | los destinos que saca a internet y un id de dispositivo/contrato, **no** tu IP real | solo con el Cifrado poscuántico desactivado |
| **Directo** | menos intervención en la retransmisión | **tu IP real** y los destinos que saca a internet | opcional: desactiva **Anonimización fuerte** |

El [modelo de amenazas](/docs/threat-model) 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](/docs/threat-model) §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](/docs/overview) explica la red de extremo a extremo:
proveedores, contratos, lo que cada parte puede ver y no ver, y el cifrado.
Las [preguntas frecuentes](/docs/faq) responden las dudas comunes. Otras
plataformas: [Android](/docs/getting-started-android),
[iOS](/docs/getting-started-ios), [macOS](/docs/getting-started-macos),
[Windows](/docs/getting-started-windows) y el
[navegador](/docs/getting-started-browser).
