# Die Linux-App im Detail

Das ist der Tiefgang: jede größere Fläche der Linux-App, was sie steuert,
ihre Standardwerte und wie du sie reparierst, wenn etwas kaputtgeht. Er
setzt voraus, dass du schon installiert und verbunden hast. Falls nicht,
starte mit [Erste Schritte](/docs/getting-started-linux). Wie das Netzwerk
hinter der App funktioniert, erklärt der [Überblick](/docs/overview).

Der Linux-Client ist eine GTK4/libadwaita-Desktop-App über einem
Root-systemd-Daemon, ausgeliefert als AppImage plus `.deb`. All das ist
Open Source auf
[github.com/urnetwork/linux](https://github.com/urnetwork/linux).

## Einstellungen auf einen Blick

Die Standardwerte schützen dich ohne Konfiguration. Die
Verbindungs-Steuerelemente leben im Connect-Drawer; Verbindung teilen
(provide mode) sitzt in den Home-Steuerelementen; der
Gerätestandort-Override sitzt über dem Globus der verbundenen Provider.

| Einstellung | Standard | Wirkung | Hauptkosten |
|---|---|---|---|
| Verbindungsmodus (Connection mode) | Auto | wählt die Provider-Fenster; Auto fährt Qualität und Geschwindigkeit zusammen | Web oder Streaming verengen auf ein Fenster |
| Starke Anonymisierung (Strong Anonymization) | An | verbirgt deine Quell-IP vor dem Provider | mehr Latenz |
| Post-Quanten-Verschlüsselung (Post Quantum Encryption) | An | verschlüsselt von der App bis zum Provider | überspringt Provider, die er nicht versiegeln kann |
| Kill Switch | Aus | stoppt den lokalen Fallback, wenn der Tunnel unten ist | kein Datenverkehr, während Provider ausfallen |
| Feste IP (Fixed IP) | Aus | ein Provider, eine Exit-Adresse | kein Failover |
| Werbung und Tracker blockieren (Block ads and trackers) | Aus | filtert Werbe- und Tracker-Datenverkehr | Filterung kann manche Websites brechen |
| Eigenes DNS (Custom DNS) | verschlüsseltes DoH durch den Tunnel | DNS bleibt verschlüsselt und im Tunnel | es zu lockern ist der Tausch |
| Verbindung teilen (Provide mode) | Aus | teilt übrige Bandbreite als Exit für andere | fremder Datenverkehr tritt von deiner IP aus |
| Gerätestandort-Override (Device location override) | Aus | Apps, die GeoClue fragen, sehen die Stadt deines am längsten gehaltenen Providers | braucht GeoClue 2.7+; betrifft jede App auf der Maschine |
| Split-Regeln (Domain/IP) | leer | gelistete Ziele nutzen deine lokale Verbindung | dieser Datenverkehr ist ungeschützt |

Vorbehalte, die zur Tabelle gehören:

- **Starke Anonymisierung** auszuschalten ist der Direktmodus: Der Client
  spricht direkt mit dem Provider und wird schneller, und dieser Provider
  sieht dann deine echte Adresse. Der Standard schützt deine Identität. Gib
  sie bewusst her.
- Der Kill Switch entscheidet auch, was mit einem Paket passiert, das der
  Sicherheitsfilter verwirft (siehe Verbindung teilen): an, wird es rundweg
  blockiert; aus, verlässt es über deine normale Route.
- Split-Tunneling pro App gibt es auf Linux nicht. Die Split-Regeln sind
  auf Domain- und IP-Ebene.
- Das Löschen deines Kontos ist auch nicht auf Linux. Erledige das in der
  [Web-App](https://ur.io/app), die dasselbe Konto verwaltet.

## Die Daemon-Aufteilung

Zwei Programme, zwei Privilegienstufen:

- **`urnetworkd`** ist ein Root-Daemon, verwaltet von `urnetworkd.service`,
  ganz ohne GUI-Abhängigkeiten. Er bettet das `DeviceLocal` des SDK ein,
  öffnet und besitzt `/dev/net/tun`, pumpt Pakete durch die IO-Loop des SDK
  und wendet Routen und DNS an. Das `.deb` oder das Install-Tarball
  installiert ihn.
- **`urnetwork`** ist die Desktop-App, gtkmm-4.0 und libadwaita, die als
  dein normaler Benutzer läuft und als AppImage ausgeliefert wird. Sie hält
  ein `DeviceRemote`: eine Sicht auf das Device des Daemons, kein eigenes
  Device.

Sie sprechen über zwei Kanäle:

1. **Device-RPC.** Das `DeviceRemote` der App steuert das `DeviceLocal` des
   Daemons über das beidseitig authentifizierte TLS-RPC des SDK auf
   Loopback, `127.0.0.1:12025`, derselbe Transport, den die Windows-App
   nutzt.
2. **Der Steuer-Socket.** Ein Unix-Domain-Socket unter
   `/run/urnetwork/control.sock` trägt den Tunnel-Lebenszyklus: Tunnel
   hochbringen, abbauen, Verbindung teilen einstellen, Daemon-Zustand
   melden.

Der Unix-Socket ist die echte Autorisierungsgrenze. Loopback-TCP ist für
jeden lokalen Prozess erreichbar, weshalb das Device-RPC beidseitig mit
Zertifikaten authentifiziert ist. Aber nichts startet einen Tunnel, ohne
den Unix-Socket zu passieren, wo der Kernel selbst dem Daemon sagt, welcher
Benutzer fragt (`SO_PEERCRED`, geprüft, bevor ein einziges Byte der Anfrage
geparst wird, und autorisiert über die Benutzer-ID, nie die Prozess-ID).
Das Verzeichnis ist `0750 root:urnetwork`, der Socket `0660`, und die Regel
lautet: Root, oder ein Mitglied der Gruppe `urnetwork`.

Auch das Device-RPC auf einen Unix-Transport zu heben ist ein
festgehaltenes Follow-up im SDK; die Design-Notizen benennen die
Loopback-Einschränkung, statt Loopback als privat zu behandeln.

### Die zwei Hälften müssen zusammenpassen

Linux ist die erste URnetwork-Plattform, auf der sich App und Tunnel
unabhängig aktualisieren: Das AppImage aktualisiert sich selbst als du, der
Daemon über apt. Die App prüft beim Verbinden also zwei Dinge: die Version
des Steuerprotokolls, und dass beide Hälften exakt denselben SDK-Build
tragen. Ein Missverhältnis wird vorab mit einer eindeutigen Meldung
abgelehnt (*Dienst läuft nicht*, *Dienst veraltet*, *App veraltet*, *Builds
unterscheiden sich*), denn jede hat eine andere Lösung, und ein still halb
funktionierender Tunnel ist schlimmer als ein Fehler.

### Wie die Teile installiert werden

Beide Hälften kommen von der Release-Seite: `.deb`, `.install.tar.gz` und
`.AppImage`, amd64 und arm64, mit einer glibc-2.35-Untergrenze, die Ubuntu
22.04 oder Debian 12 und neuer bedeutet. Einen Store-Eintrag gibt es nicht.

Das Paket besitzt alles Privilegierte und Stabile: den Daemon unter
`/usr/lib/urnetwork/urnetworkd`, seine systemd-Unit, den Desktop-Eintrag,
Icons, die Weltkarten-Daten, aus denen der Globus zeichnet, Übersetzungen
und einen Launcher unter `/usr/bin/urnetwork`.

Das GUI-AppImage wird vom Paket nie installiert. Es lebt in deinem
Home-Verzeichnis (`~/.local/lib/urnetwork/URnetwork.AppImage`),
benutzerbeschreibbar, damit es sich ohne Root selbst ersetzen kann. Der
Launcher durchsucht eine feste Liste von Orten (`$URNETWORK_APPIMAGE`, dann
`~/.local/lib/urnetwork/`, dann `~/Applications/`, dann
`/usr/lib/urnetwork/`, dann ein beliebiges `urnetwork-gui` auf `$PATH`) und
führt den ersten Treffer aus; ohne installiertes druckt er einen
Einzeiler-Hinweis, wo du eines bekommst.

Der Daemon läuft mit dem Privileg, das er braucht, und gibt ab, was er
nicht braucht: `NoNewPrivileges`, `ProtectHome` (er ist headless und darf
Benutzer-Home-Verzeichnisse nie lesen), `PrivateTmp`, Zustands- und
Log-Verzeichnisse nur für Root. Er ist gegen `network-pre.target`
geordnet, den Slot, den ein VPN braucht, um handeln zu können, bevor das
Netz hochkommt, und er läuft dauerhaft statt socket-aktiviert, denn eine
träge gestartete Unit kann an dieser Ordnung gar nicht teilnehmen.

## Routen

Kommt der Tunnel hoch, ersetzt der Daemon deine Default-Route nicht. Er
überbietet sie, wie `wg-quick` es tut:

- Er fügt Routen durch das Tunnel-Interface (`urnet0`) hinzu, die den
  ganzen IPv4-Raum abdecken, **außer** den privaten LAN-Bereichen:
  10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
- Diese sind spezifischer als deine bestehende `0.0.0.0/0`-Default-Route,
  sie gewinnen also, ohne sie anzufassen. Der Abbau ist bloß ihr Entfernen;
  dein ursprüngliches Routing wird nie verändert.
- Das Ausnehmen der privaten Bereiche hält deinen Drucker, dein NAS und
  lokale Dienste am Laufen, während du verbunden bist — dasselbe Verhalten
  wie bei den Android-, Apple- und Windows-Clients.

NetworkManager wird angewiesen, die Finger davon zu lassen: `urnet0` wird
über ein NetworkManager-Config-Drop-in und eine udev-Regel als unmanaged
markiert, damit der Netzwerkmanager des Desktops nie mit dem Daemon um das
Interface kämpft.

## DNS

DNS auf dem Tunnel-Link wird über **systemd-resolved** (`resolvectl`)
gesetzt, den Standard-Resolver auf Ubuntu-Desktops: Die Resolver des Links
werden auf die des Netzwerks gerichtet, mit `~.`, damit Anfragen darüber
routen, und alles wird beim Abbau zurückgenommen. Nicht jedes System fährt
resolved, das Verhalten ist also per Design best-effort:

- **Mit systemd-resolved:** DNS für den Tunnel-Link wird erfasst und
  wiederhergestellt.
- **Ohne:** Der Tunnel routet trotzdem, aber DNS auf diesem Link wird nicht
  erfasst. Deine Anfragen nutzen weiter den Resolver, den das System hatte.

Noch eine Feinheit: Eine per DHCP gelieferte Such-Domain (`lan`, `home`)
ist ein längerer Treffer als `~.` und schlägt es für Namen in dieser
Domain. Fährst du ein ungewöhnliches Resolver-Setup, prüf, wohin dein DNS
wirklich geht.

Das app-eigene Sheet **Eigenes DNS** (Custom DNS) ist das gewichtigere
Steuerelement. Es bearbeitet die Resolver-Einstellungen des SDK, deren
Standard verschlüsseltes DNS over HTTPS ist, aufgelöst durch den Tunnel. Es
bietet DoH und unverschlüsselte Auflösung, entfernt oder lokal,
bearbeitbare Serverlisten pro Familie, einen Schalter für den lokalen
DNS-Fallback, der einen lokalen Resolver mitlaufen lässt, während der
Tunnel startet, damit Auflösungen nicht stocken, regionale Empfehlungen für
Orte, an denen die strengste Konfiguration bekanntermaßen bricht, und eine
Aktion, die die sicheren Standardwerte wiederherstellt.

## Der Tray

Das Status-Symbol ist ein **StatusNotifierItem** mit einem
`com.canonical.dbusmenu`-Menü, direkt über GDBus gesprochen: das Protokoll,
das KDE und die meisten Panels nativ unterstützen und GNOME über die
AppIndicator-Erweiterung. Ohne vorhandenen Tray-Host zeigt die App kein
Symbol, statt zu scheitern.

Das Fenster zu schließen versteckt in den Tray und lässt den Tunnel laufen.
Das Menü trägt Verbinden/Trennen, Anzeigen und Beenden. Beenden ist hier
der echte Ausstieg: Es beendet die Sitzung und bringt den Tunnel herunter.
Im Alltag willst du den Schließen-Button, nicht Beenden.

## Das Fenster

Zuerst die Anmeldung, dann die Home-Ansicht: das Verbinden-Steuerelement,
der Provider-Globus und der Drawer. Die Anmeldung nimmt einen E-Mail- oder
Telefon-Code, **Konto erstellen** (Create account), einen Auth-Code,
erzeugt auf einem Gerät, auf dem du schon angemeldet bist, oder eine
Wallet-Signatur über Solana (Phantom, Solflare) oder Bittensor. Ein
Alt-Button **Gastmodus ausprobieren** (Try Guest Mode) sitzt auch dort. Er
prägt ein gewöhnliches dauerhaftes Konto auf dem Server, aber diese App
wirft die Wiederherstellungs-Seedphrase weg, die damit zurückkommt — nutz
also einen der anderen Wege, wenn du das Konto später wiederherstellen
können willst.

**Der Provider-Globus** wird aus einer Welt-Topologie gezeichnet, die der
App beiliegt. Keine Kartenkacheln werden geholt — nichts über die Karte,
die du ansiehst, verlässt also deine Maschine.

**Der Connect-Drawer** trägt die Sitzung:

- **Die Karte mit den Verbindungs-Steuerelementen.** Der gewählte Standort,
  ein Verbindungsmodus aus **Auto**, **Web** oder **Streaming** und vier
  Schalter: **Feste IP**, **Starke Anonymisierung**,
  **Post-Quanten-Verschlüsselung** und der **Kill Switch**. Der Modus
  wählt, welches Provider-Fenster läuft: **Web** ist das Qualitätsfenster
  (2–6 Provider zugleich), **Streaming** das Geschwindigkeitsfenster (1–2),
  und **Auto** fährt beide nebeneinander — weshalb eine gewöhnliche Sitzung
  üblicherweise 3–8 Provider offen hat, nicht einen. Starke Anonymisierung
  ist, was einen direkten Client-zu-Provider-Pfad verbietet, sodass kein
  Provider je deine echte Adresse sieht; sie auszuschalten ist der
  Direktmodus-Tausch aus der Tabelle oben. Post-Quanten-Verschlüsselung
  versiegelt die Sitzung selbst (siehe das Identitäts-Panel unten).
- Die Karten **Client- und lokale Statistiken** mit Live-Diagrammen, jede
  öffnet ein Detail-Sheet.
- Der Status **Eigenes DNS**, der den Resolver-Editor oben öffnet.
- **Werbung und Tracker blockieren.**
- **Tarif und Nutzung.** Deine Stufe, der Balken
  verbraucht/ausstehend/verfügbar, die Zeilen für Tageskontingent und
  Empfehlungen, **UR Pro holen** (Get UR Pro) und das Einlösen eines
  Guthaben-Codes.
- **Das Post-Quanten-Identitäts-Panel** (unten).

**Sheets**, jedes ein echter Bildschirm statt eines Stummels:

- **Standorte (Locations).** Die gebündelten Abschnitte des SDK: deine
  verbundenen Netzwerk-Peers zuerst, dann bester verfügbarer, dann Länder
  mit Live-Provider-Zahlen. Tippen im Suchfeld ergänzt Top-Treffer plus
  Regionen, Städte und Geräte. Eine Stadt ist hier etwas, das du suchst,
  nicht etwas, zu dem du scrollst.
- **Verbundene Provider (Connected providers).** Ein Globus über einer
  Zeile pro Provider, der gerade in deinem Fenster ist, älteste Verbindung
  zuerst, mit Client-ID, Stadt/Region/Land, Koordinaten, Dauer und einem
  Entfernen inline.
- **Verträge (Contracts).** Die Live-Transferverträge hinter deiner
  Sitzung, ein Stapel pro Peer, Senden und Empfangen getrennt gehalten.
- **Split-Regeln (Split rules).** Regeln auf Domain- und IP-Ebene, die
  bestimmten Datenverkehr auf deine lokale Verbindung zwingen, über einem
  Live-Feed dessen, worauf gerade gewirkt wird.
- **Code einlösen (Redeem code).** Einen Guthaben-Code anwenden, mit der
  Historie der eingelösten.
- **Upgrade.** UR Pro monatlich oder jährlich über den Stripe-Checkout,
  eingebettet in die App, wo das System WebKitGTK hat, und sonst mit
  Fallback auf deinen Browser, denn ein Zahlungspfad darf nie hart
  scheitern.

Einen separaten Konto-, Wallet- oder Bestenlisten-Bildschirm gibt es auf
Linux heute nicht. Tarif und Guthaben leben im Drawer und im Einlöse-Sheet,
und die Kontoeinstellungen leben in der Web-App auf [ur.io](https://ur.io).
Das Abmelden ist in der Home-Ansicht.

## Der Gerätestandort-Override

Linux bekommt eine echte Version dessen, was Android „Gerätestandort
synchronisieren“ (sync device location) nennt: Apps, die das System fragen,
wo du bist, können die Koordinaten des Providers gesagt bekommen, mit dem
du am längsten verbunden bist, statt deines tatsächlichen Standorts. Der
Schalter sitzt über dem Globus der verbundenen Provider, mit einer
Einrichtungsanleitung, und er ist aus, bis du ihn einschaltest.

Der Mechanismus ist schmal. GeoClue, der Dienst, den Desktop-Apps nach dem
Standort fragen, hat eine statische Quelle, die eine feste Position aus
`/etc/geolocation` liest und die Datei auf Änderungen beobachtet. Diese
Datei ist der einzige Injektionspunkt, und sie liegt unter `/etc` — das
Schreiben erledigt also der Daemon über denselben Steuerkanal; die GUI
fasst sie nie an und braucht nie Root.

Die Anleitung benennt ihre Grenzen direkt. Sie braucht GeoClue 2.7.0 oder
neuer, das nicht auf jedem System ist; Ubuntu 22.04 und Debian 12 liefern
eine ältere Version aus und können es nie erfüllen. Und sie bewegt nur, was
GeoClue meldet: Die GNOME-Einstellungen und -Karten, Firefox und
gesandboxte Flatpak- und Snap-Apps folgen ihr. Chrome und KDE Plasma fragen
GeoClue gar nie, alles, was deinen Standort aus deiner IP-Adresse ableitet,
bleibt unberührt, und Firefox fällt auf sein eigenes Nachschlagen zurück,
wenn das System langsam antwortet. Sie ändert außerdem den Standort, der
jeder App auf der Maschine gemeldet wird, nicht nur URnetwork. Alles Übrige
in der App funktioniert unabhängig davon.

## Verbindung teilen

Das Teilen ist standardmäßig aus, und die Home-Steuerelemente bieten
**Auto**, **Immer** (Always), **Netzwerk** (Network, nur die Geräte deines
eigenen Kontos) oder **Nie** (Never). Provider nehmen am UR Protocol teil;
[ur.xyz](https://ur.xyz) dokumentiert, wie die Vergütung funktioniert.

Was dich beim Teilen schützt, ist die quelloffene `ip_security`-Schicht der
Connect-Engine. Sie fährt Deep Packet Inspection an deinem eigenen Ausgang
und verwirft Datenverkehr der DMCA-Klasse (zustandsbehaftete BitTorrent-
und Filesharing-Signaturen, Verwürfe opaker Protokolle) und der CFAA-Klasse
(Angriffs- und Einbruchsmuster), bevor er deine Maschine verlässt.
Derselbe Filter läuft auch auf deinem eigenen Sendepfad als gewöhnlicher
Nutzer, ob du das Teilen je einschaltest oder nicht — dein Datenverkehr
wird also auf deiner Maschine beurteilt, bevor er irgendeinen Provider
erreicht.

Bei einem Treffer wird das Paket verworfen, ohne dass Ziel, Domain oder
Inhalte aufgezeichnet werden. Eine BitTorrent-Signatur auf Datenverkehr,
den du für jemand anderen trägst, hebt zusätzlich eine
Missbrauchsmarkierung an den Operator, die nur die ID des sendenden Geräts
und einen Boolean hält, und der Operator liefert dafür heute keinen Handler
aus. Ein opak verschlüsselter Flow ist ein schlichter Verwurf, der gar
nichts meldet. Die Versiegelung umgeht den Filter nicht, denn er läuft
dort, wo Datenverkehr austritt. Und der Kill Switch entscheidet das
Schicksal eines Pakets der Verwurfsklasse von deiner eigenen Maschine: aus,
geht es über deine lokale Verbindung hinaus; an, stoppt es.

## Das Post-Quanten-Identitäts-Panel

Der Drawer zeigt die Sitzungsidentität dieses Geräts: ein Identicon, den
kanonischen Schlüssel-Hash und die Client-ID (Klick zum Kopieren), ein Deck
der Provider-Identitäten, mit denen du verifizierte Sitzungen aufgebaut
hast, die volle Liste der Provider-Identitäten und einen Teilen-Dialog, um
deinen Fingerabdruck über einen anderen Kanal abzugleichen.

Was die Einstellung tut: **Post-Quanten-Verschlüsselung** wird an
ausgeliefert, und solange sie an ist, versiegelt dein Client Datenverkehr
Ende-zu-Ende bis zum Provider über eine Sitzung, ausgehandelt mit
**X25519MLKEM768** (hybrid klassisch plus ML-KEM). Diese versiegelte Etappe
ist, was den mittleren Hop blind macht: Der Operator trägt Bytes, die er
nicht lesen kann. Sie ist fail-closed: Solange die Einstellung an ist,
sendet und akzeptiert der Client keine Anwendungsdaten im Klartext, ein
Provider, mit dem er diese Sitzung nicht aufbauen kann, wird also
übersprungen statt unversiegelt genutzt. Der Preis ist ein verlorener
Provider, nicht verlorene Verschlüsselung, und still herabgestuft werden
kannst du nicht. Jeder aktuelle Provider-Build aktiviert die
Responder-Seite, das Überspringen ist also selten. Schalte die Einstellung
aus, dann kann der Verkehr wieder den Standardpfad TLS-zur-Plattform nehmen.
Identitätssignaturen bleiben
Ed25519, und die Chiffre ist AES-256-GCM. „Post-Quanten“ meint diesen
Schlüsselaustausch, nichts Breiteres.

## Was das Netzwerk darunter tut

Dein Datenverkehr nimmt vier Etappen: du → Extender → Operator → Provider →
Internet. Der Extender ist ein Erreichbarkeits-Hop, der deine verschlüsselte
Sitzung weiterleitet, ohne sie zu lesen; als dein erster Hop sieht er
allerdings deine Adresse. Der [Überblick](/docs/overview) erklärt den
vollen Pfad, warum er bei vier Etappen endet, und die Provider-Fenster.

Was für die Schalter dieser App zählt, ist die Aufteilung über die beiden
Relay-Parteien. Der Provider erfährt nie, wer du bist, denn der Operator
sitzt dazwischen. Der Operator kann nicht lesen, was du sendest, denn
Post-Quanten-Verschlüsselung versiegelt die Sitzung standardmäßig
Ende-zu-Ende bis zum Provider. Beides gilt auf einer unveränderten
Installation — keine einzelne Partei hält also zugleich deine Identität und
deine Aktivität. Die drei Zustände, die die zwei Schalter erzeugen:

| Modus | Operator sieht | Provider sieht | Standard und Verfügbarkeit |
|---|---|---|---|
| **Relay, versiegelt** | dein Konto und deine Quellverbindung, auf welchen Providern du bist, und Chiffretext mit Timing und Volumen | Ziele, die er nach außen trägt, und eine Geräte-/Vertrags-ID, **nicht** deine echte IP | der ausgelieferte Standard: Post-Quanten-Verschlüsselung, an im Connect-Drawer |
| **Relay, Standard** | dein Konto und deine Quellverbindung, auf welchen Providern du bist, und die Ziele und Paketbytes darin | Ziele, die er nach außen trägt, und eine Geräte-/Vertrags-ID, **nicht** deine echte IP | nur mit ausgeschalteter Post-Quanten-Verschlüsselung |
| **Direkt** | weniger Relay-Beteiligung | **deine echte IP** und die Ziele, die er nach außen trägt | opt-in: **Starke Anonymisierung** ausschalten |

Das [Bedrohungsmodell](/docs/threat-model) spielt diese Zeilen gegen
benannte Angreifer durch und benennt ausdrücklich, wo jede versagt.

Auf der Seite des Operators gibt es wenig zu behalten:
Verbindungsdatensätze halten einen Einweg-Hash mit geheimem Schlüssel
(verwürfelt mit einem geheimen Schlüssel) deines IP-Blocks statt der
Adresse, das Vertragsregister hält Client-IDs und Bytezahlen ohne Ziel,
Host, URL oder Domain irgendwo, und der Datenpfad loggt nichts. Eine
Geo-Abfrage verzeichnet allerdings eine ungefähre Stadt pro Verbindung; was
du darüber erreichst, wird gar nicht verzeichnet. Kein unabhängiges Audit
deckt das Protokoll oder den Server-Code des Operators ab (die zwei
externen Prüfungen aus 2025 decken andere Flächen ab: ein Penetrationstest
der Web-Anwendung und API und eine bestandene Leviathan-MASA-AL2-Prüfung
der Android-App, nicht des Linux-Clients). Die Prüfungen, die es
stattdessen gibt, sind der offene Quellcode selbst, von jedem fortlaufend
prüfbar, und das Exit-Design: Der Ausgang ist eine dezentrale Flotte
separat betriebener Provider statt eines Verwahrers, der alles hält.
Grenze: Wie unabhängig diese Flotte wirklich ist, wurde nie gemessen, und
nichts hindert den Operator daran, eigene Provider zu betreiben
([Bedrohungsmodell](/docs/threat-model) §6.1).

## Grenzen

- **Der Kill Switch wird aus ausgeliefert.** Er ist ein echter Schalter im
  Connect-Drawer, aber bis du ihn einschaltest, fällt Datenverkehr auf
  deine normale Verbindung zurück, wann immer kein Provider oben ist, statt
  zu stoppen. Der Drawer wendet ihn live über das Device-RPC an, und der
  Daemon stellt deine Wahl beim nächsten Start wieder her.
- **Nur IPv4 durch den Tunnel.** IPv6 wird nicht durch ihn geroutet — in
  einem IPv6-fähigen Netz kann eine v6-fähige Website also weiterhin deine
  echte Adresse sehen. Deaktivier IPv6 auf der Verbindung, wenn alles über
  einen Provider austreten muss.
- **Kein Split-Tunneling pro App.** Regeln sind auf Domain- und IP-Ebene.
- **Keine Google- oder Apple-Anmeldung.**
- **Die DNS-Erfassung hängt an systemd-resolved**, wie oben beschrieben.

## Fehlerbehebung

### „Der URnetwork-Systemdienst läuft nicht“

Prüf den Daemon und seinen Socket:

```
systemctl status urnetworkd
journalctl -u urnetworkd -f
```

Der Daemon erzählt, was er konfiguriert und was er wiederherstellt — das
ist also der erste Ort, an dem du bei Problemen mit Tunnel-Hochfahren,
Routen und DNS nachsiehst. GUI-Logs bleiben in deiner Benutzersitzung,
getrennt von der privilegierten Hälfte, was der Sinn der Teilung ist.

Läuft der Daemon und die App erreicht ihn trotzdem nicht, bist du
wahrscheinlich nicht in der Gruppe `urnetwork`: `id -nG` sagt es dir. Füg
dich mit `sudo usermod -aG urnetwork "$USER"` hinzu und melde dich ab und
wieder an.

### „Der Dienst ist veraltet“ / „unterschiedliche Builds“

Aktualisiere beide Hälften auf dasselbe Release: den Daemon durch
Installieren des neueren `.deb` (oder durch erneutes Ausführen von
`install.sh` aus dem neueren Tarball), und das AppImage in
`~/.local/lib/urnetwork/`. Die Prüfung existiert, damit eine halb
aktualisierte Installation es sagt, statt sich leise danebenzubenehmen.

### Das AppImage startet nicht

Ubuntu 22.04+ liefert `libfuse2` nicht standardmäßig aus, und AppImages
brauchen es. Das `.deb` deklariert diese Abhängigkeit, das Daemon-Paket zu
installieren löst es also meist; andernfalls installier `libfuse2` (oder
`libfuse2t64` auf neueren Releases). Prüf auch, dass die Datei ausführbar
ist.

### Kein Tray-Symbol

Dein Desktop hat keinen StatusNotifierItem-Host. Auf GNOME installier die
AppIndicator-Erweiterung; KDE und die meisten Panels unterstützen es nativ.
Die App funktioniert auch ohne: Das Fenster zu schließen versteckt sie nur,
und du öffnest sie über das App-Menü wieder.

### `urnetwork://`-Links tun nichts

Die Wallet-Anmeldung kehrt über einen `urnetwork://`-Link zurück, der nach
der Installation eine aufgefrischte Desktop-Datenbank braucht. Führ
`update-desktop-database ~/.local/share/applications` aus (oder den
Systempfad mit sudo). Die paketierte Installation stößt das für dich an;
eine manuelle vielleicht nicht.

### Das Interface existiert, aber nichts routet

Prüf, dass NetworkManager `urnet0` nicht verwaltet. Das Paket liefert ein
Config-Drop-in und eine udev-Regel mit, die es als unmanaged markieren, und
beide brauchen ein Reload (`nmcli general reload conf`,
`udevadm control --reload`), das der Installer erledigt.

## Anderswo

Der [Überblick](/docs/overview) erklärt das Netzwerk Ende zu Ende:
Provider, Verträge, was jede Partei sehen kann und was nicht, und die
Verschlüsselung. Die [FAQ](/docs/faq) beantwortet die häufigen Fragen.
Andere Plattformen: [Android](/docs/getting-started-android),
[iOS](/docs/getting-started-ios), [macOS](/docs/getting-started-macos),
[Windows](/docs/getting-started-windows) und der
[Browser](/docs/getting-started-browser).