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. Wie das Netzwerk hinter der App funktioniert, erklärt der Überblick.

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.

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.

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, 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. 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 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 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:

Das Bedrohungsmodell 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 §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 erklärt das Netzwerk Ende zu Ende: Provider, Verträge, was jede Partei sehen kann und was nicht, und die Verschlüsselung. Die FAQ beantwortet die häufigen Fragen. Andere Plattformen: Android, iOS, macOS, Windows und der Browser.