Die Windows-App im Detail

Das ist der Tiefgang: jede größere Fläche der Windows-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 Windows-Client ist zwei Programme mit unterschiedlichen Privilegien, ein Kernel-Treiber für Split-Tunneling pro App und eine UI, ausgerichtet an der macOS-App. All das ist Open Source auf github.com/urnetwork/windows.

Einstellungen auf einen Blick

Die Standardwerte schützen dich ohne Konfiguration. Jedes Steuerelement unten lebt im Connect-Drawer, außer den App-Split-Regeln unter Einstellungen.

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.
• Schalter-Einstellungen bleiben über Verbindungsmodi hinweg erhalten. Feste IP ist inaktiv, bis du Web oder Streaming wählst.
• 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.
• Das Löschen deines Kontos ist nicht auf Windows. Erledige das in der Web-App, die dasselbe Konto verwaltet.

Zwei Prozesse, ein Tunnel

Die App ist absichtlich in zwei Programme geteilt:

• URnetwork.exe. Die WinUI-3-Tray-App, mit der du interagierst. Sie läuft unprivilegiert, in deiner Benutzersitzung: ein Flyout aus dem System-Tray plus ein volles Fenster für Verbinden, Konto, Wallet, Bestenliste, Support und Einstellungen.
• urnetworkd. Ein Windows-Dienst, der als LocalSystem läuft, Windows' privilegiertestem eingebautem Konto: die Macht, Netzwerkadapter zu erstellen und Routen zu setzen, die die App, die du anklickst, nie bekommt. Er bettet das URnetwork SDK ein, besitzt den virtuellen wintun-Adapter, pumpt Pakete, wendet Routen, DNS und MTU an und hält seinen eigenen Steuer-Datenverkehr vom Tunnel fern.

Sie sprechen über zwei Kanäle, jeder mit einer Aufgabe:

1. Device-RPC. Das DeviceRemote der App steuert das DeviceLocal des Dienstes über das eigene RPC des SDK: ein beidseitig authentifizierter TLS-WebSocket auf Loopback. Beide Enden beweisen ihre Identität mit Zertifikaten, und die Verbindung verlässt deine Maschine nie — ein anderes lokales Programm kann sich also nicht einfach verbinden und den Dienst steuern. Alles, was du in der UI tust, reist über diesen Kanal: verbinden, einen Standort wählen, das Teilen umschalten.
2. Eine Named Pipe (\\.\pipe\urnetwork.control). Sie trägt nur Lebenszyklus und Konfiguration: Tunnel starten und stoppen, Split-Tunnel-Regeln anwenden, abmelden. Sie spiegelt, wie die macOS-App mit ihrer Network Extension spricht, damit die beiden Codebasen ausgerichtet bleiben.

Warum die Teilung: Ein VPN-Tunnel braucht Privilegien, und eine UI sollte sie nie haben. Fast jedes Windows-VPN ist aus diesem Grund zwei Programme. Du genehmigst eine UAC-Abfrage, bei der Installation, wenn sich der Dienst registriert. Der Alltag fragt nie nach Admin.

Es heißt auch, dass dein Schutz nicht davon abhängt, dass das Fenster offen ist. Schließ das Fenster, und es versteckt sich in den Tray. Beende über das Tray-Menü, und der Tunnel steht weiter, denn der Dienst besitzt ihn. Nur Trennen (Disconnect), ein Abmelden oder das Stoppen des Dienstes bringt ihn herunter.

Das Fenster

Die Navigation läuft über Verbinden (Connect), Konto (Account), Wallet, Bestenliste (Leaderboard), Support, Einstellungen (Settings).

Verbinden ist der Globus und der Drawer darunter. Der Drawer ist, wo die Sitzung lebt:

• Gewählter Standort und Peers. Worüber du verbunden bist und wie viele Provider gerade deinen Datenverkehr tragen. Klick auf die Peer-Zahl, um das Sheet der verbundenen Provider zu öffnen: ein Globus über einer Zeile pro Provider, mit seiner Client-ID, Stadt/Region/Land, Koordinaten und wie lange er in deinem Fenster ist, plus ein Entfernen inline.
• Verbindungsoptionen (Connect options). Der Verbindungsmodus (Auto, Web oder Streaming: wie aggressiv der Client Provider-Zahl gegen Durchsatz tauscht) und die vier Schalter aus der Tabelle oben: Feste IP, Starke Anonymisierung, Post-Quanten-Verschlüsselung und der Kill Switch.
• Die Karten Client-Statistiken (Client statistics) und Lokale Statistiken (Local statistics), jede öffnet ein Detail-Sheet: Live-Verträge auf der einen Seite, Split-Regeln und Aktivität blockierten Datenverkehrs auf der anderen.
• Eigenes DNS. Eine Statuskarte über dem vollen Resolver-Editor (unten).
• Werbung und Tracker blockieren. Ein Schalter.
• Tarif und Nutzung. Deine Stufe, der Balken verbraucht/ausstehend/verfügbar, das Tageskontingent, Empfehlungen, UR Pro holen (Get UR Pro) und das Einlösen eines Guthaben-Codes.

Konto trägt Tarif und Nutzung, eingelöste Guthaben-Codes, deinen Netzwerknamen und Empfehlungen. Wallet deckt deinen Tarif und Upgrade-Pfad ab, und die Wallet-Einstellungen für die Teilnahme am UR Protocol (ur.xyz). Bittensor-Wallets lassen sich anhängen, werden aber nur für künftige Nutzung aufgezeichnet, und die App sagt das dort, wo du es erwarten würdest. Die Bestenliste reiht Provider-Netzwerke. Support sendet Feedback und erreicht feedback.ur.io. Die Einstellungen halten die App-Split-Regeln und das Abmelden.

Ein Vorbehalt auf dem Weg hinein: Der Anmeldebildschirm bietet noch Gastmodus ausprobieren (Try Guest Mode). Er erstellt ein gewöhnliches, dauerhaftes Konto, aber die Windows-App wirft die Wiederherstellungs-Seedphrase weg, die der Server zurückgibt, und eine Seedphrase-Anmeldung gibt es hier nicht. Häng eine E-Mail oder eine Wallet an dieses Konto, bevor du dich darauf verlässt.

Der Tray

Klassisches Win32-Tray-Verhalten, denn WinUI hat keine eigene Tray-API:

• Linksklick öffnet das Fenster neben dem Tray-Symbol positioniert, im Flyout-Stil.
• Rechtsklick gibt ein Menü mit Verbinden/Trennen, Anzeigen und Beenden.
• Vier Symbolzustände spiegeln die macOS-Menüleisten-Matrix (verbunden oder nicht, teilend oder nicht), jeder in hellem und dunklem Artwork, umgeschaltet passend zu deinem Taskleisten-Theme.

Provider wählen, und was das heißt

Die Standortauswahl ist die eigene Gruppierung des SDK: verbundene Netzwerk-Peers zuerst, dann bester verfügbarer, dann Länder mit Live-Provider-Zahlen. Tipp ins Suchfeld, und die Ergebnisse gliedern sich neu in Top-Treffer plus Regionen, Städte und Geräte. Gezielt wird auf Stadtebene; eine Stadt erreichst du per Suche, nicht per Scrollen.

Zwei Schutzmechanismen stehen hinter jeder Relay-Sitzung, und keiner braucht eine angefasste Einstellung. Der Provider, der deinen Datenverkehr nach außen trägt, erfährt nie, wer du bist, denn der Operator sitzt dazwischen. Der Operator kann die Pakete, die er weiterleitet, nicht lesen, denn Post-Quanten-Verschlüsselung versiegelt die Sitzung standardmäßig Ende-zu-Ende bis zum Provider. Zusammen hält keine einzelne Partei zugleich deine Identität und deine Aktivität. Der volle Pfad, einschließlich der Extender-Etappe, die deine verschlüsselte Sitzung zum Operator trägt, steht im Überblick.

Das Bedrohungsmodell spielt diese Zeilen gegen benannte Angreifer durch und benennt ausdrücklich, wo jede versagt.

In Auto laufen zwei Provider-Fenster nebeneinander, Datenverkehr tritt also typischerweise über 3–8 Provider zugleich aus, mit jeder Website auf einen gepinnt. Ein einzelner Provider sieht immer nur einen Ausschnitt deiner Sitzung. Web und Streaming fahren je ein Fenster, schmaler. Feste IP kollabiert es auf einen Provider und eine Exit-Adresse.

Split-Tunneling pro App und der Treiber

„Lass diese App das VPN umgehen“ — damit ein Spiel seinen niedrigsten Ping behält oder eine VPN-feindliche Banking-App auf deiner normalen Verbindung bleibt — lässt sich auf Windows aus dem User-Space nicht gut machen. Die Umleitungsentscheidung muss dort passieren, wo der Socket entsteht, im Netzwerk-Stack. Also liefert die App SplitTunnel.sys mit, einen Callout-Treiber der Windows Filtering Platform (WFP):

• Clean-Room. Von Grund auf gegen Microsofts Dokumentation und öffentliche Spezifikationen implementiert, nicht vom Treiber eines anderen Herstellers abgeleitet.
• MPL-2.0-lizenziert, entwickelt im selben offenen Repository wie die App.
• Prozessbasiert, nie zielbasiert. Der Treiber registriert genau einen Callout, an Windows' Bind-Redirect-Schicht. Öffnet irgendein Prozess einen Socket, vergleicht der Treiber den Pfad der ausführbaren Datei dieses Prozesses mit deiner Ausschlussliste und schreibt bei einem Treffer die lokale Adresse des Sockets auf das physische Interface um, sodass der Flow über deine normale Verbindung austritt. Er liest überhaupt keine Remote-Adresse. Der Dienst nimmt seinen eigenen Datenverkehr per Prozess-ID aus.
• Kindprozesse erben. Die Helferprozesse eines Launchers folgen der App, die du ausgeschlossen hast.
• Fail-open, nie Blackhole. Ist kein physisches Interface gesetzt, wird die Umleitung untätig, statt Datenverkehr zu verwerfen.

Verwalte die Liste unter Einstellungen → App-Split-Regeln (Settings → app split rules). Drei Grenzen. Sockets, die ein Prozess schon offen hatte, behalten ihren bestehenden Pfad, bis sie neu verbinden. Die DNS-Anfragen einer ausgeschlossenen App gehen weiter durch Windows' geteilten Resolver-Dienst — sie können also dem Tunnel folgen, auch wenn die App selbst es nicht tut. Und der Treiber ist eine Build-Zeit-Option: Ein ohne ihn gepacktes MSI installiert einen funktionierenden Tunnel ohne Pro-App-Regeln.

Separat erledigt das Split-Regeln-Sheet im Connect-Drawer Regeln auf Domain- und IP-Ebene durch den Tunnel selbst, dieselbe Fläche, die die Apple- und Linux-Apps haben. Die beiden kombinieren sich: Der Treiber entscheidet pro App, die Regeln entscheiden pro Ziel.

Den Dienst von seinem eigenen Tunnel fernhalten

Ein Tunnel-Prozess hat ein Bootstrapping-Problem: Sein eigener Datenverkehr zur Plattform darf nicht durch den Tunnel gehen, den er erstellt, sonst schleift das erste Paket ewig. Der Dienst löst das an der Socket-Schicht. Das SDK legt einen Egress-Binding-Hook offen, und der Dienst pinnt seine eigenen Steuer- und Relay-Sockets auf das physische Interface, verfolgt von einem Egress-Monitor, der bei jedem Netzwechsel das richtige Interface neu berechnet (WLAN zu Ethernet, Adapter, die auftauchen und verschwinden).

Routen und DNS

Kommt der Tunnel hoch, löscht der Dienst deine Default-Route nicht. Er überbietet sie: Der ganze IPv4-Raum außer den privaten LAN-Bereichen (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) wird als Satz spezifischerer Routen durch den Tunnel-Adapter installiert. Sie gewinnen über deine bestehende Default-Route, ohne sie anzufassen, der Abbau ist bloß ihr Entfernen, und dein Drucker und NAS arbeiten lokal weiter. Der Tunnel-Adapter bekommt seine Adresse und eine MTU von 1440 vom SDK, und die Resolver des Netzwerks werden auf diesem Adapter gesetzt.

Drei Grenzen, an denen du die App messen kannst:

• DNS wird pro Adapter gesetzt, und Windows löst pro Adapter auf. Die eigenen DNS-Einstellungen der App (das Eigenes-DNS-Sheet, dessen Standard verschlüsseltes DNS-over-HTTPS durch den Tunnel ist) sind hier der wirksame Schutz. Fährst du ein ungewöhnliches Resolver-Setup, prüf, wohin deine Anfragen wirklich gehen.
• Der Tunnel trägt IPv4. IPv6 wird heute nicht durch ihn geroutet — in einem IPv6-fähigen Netz kann eine v6-fähige Website also weiterhin deine echte Adresse sehen. Muss alles über einen Provider austreten, deaktivier IPv6 auf der Verbindung.
• Geschlossen zu scheitern ist ein Schalter, keine Annahme. Lass den Kill Switch aus, und ein gestoppter Tunnel heißt, Windows fällt auf deine normale Verbindung zurück. Schalte ihn ein, und der Datenverkehr stoppt stattdessen. Es ist das SetRouteLocal-Primitiv des SDK, invertiert, dasselbe, das jede URnetwork-App bindet, und es wird standardmäßig aus ausgeliefert.

Eigenes DNS

Dasselbe plattformübergreifende Resolver-Panel, das die Apple- und Linux-Apps haben. Der Standard ist die strengste Option: verschlüsseltes DNS over HTTPS, aufgelöst durch den Tunnel. Du kannst bewusst tauschen: DoH oder unverschlüsselt, entfernt oder lokal aufgelöst, mit bearbeitbaren Serverlisten, einem Schalter für den lokalen DNS-Fallback, der einen lokalen Resolver mitlaufen lässt, während der Tunnel startet, damit Auflösungen nicht stocken, und einer Aktion, die die sicheren Standardwerte wiederherstellt.

Verbindung teilen

Das Teilen ist standardmäßig aus und lebt im Connect-Drawer: 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 inspiziert Datenverkehr 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 Verbindung verlässt. Ein Treffer ist ein verworfenes Paket, ohne dass Ziel, Domain oder Inhalte aufgezeichnet werden. Eine Klartext-BitTorrent-Signatur auf Datenverkehr, den du für jemand anderen trägst, sendet dem Operator zusätzlich eine Missbrauchsmarkierung mit der Geräte-ID des Peers und einem Boolean, sonst nichts, und der Operator liefert dafür heute keinen Handler aus. Derselbe Filter läuft auf deinem eigenen Sendepfad, ob du teilst oder nicht, und dein eigener Datenverkehr wird nie gemeldet. Die Versiegelung umgeht den Filter nicht, denn er läuft dort, wo Datenverkehr austritt. Der Überblick behandelt die Schicht vollständig.

Was Post-Quanten-Verschlüsselung wirklich tut

Dein Client versiegelt 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 standardmäßig an und fail-closed: Solange sie an ist, sendet und akzeptiert der Client keine Anwendungsdaten im Klartext; ein Provider, mit dem er keine versiegelte Sitzung aufbauen kann, wird deshalb übersprungen statt unversiegelt genutzt. Jeder aktuelle Provider-Build aktiviert die Responder-Seite, in der Praxis ist die Versiegelung also automatisch. Der Preis ist Verfügbarkeit, nicht Vertraulichkeit: Du kannst einen Provider verlieren, nie deine Verschlüsselung, und es gibt keine stille Herabstufung. 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.

Grenze: Die Windows-App hat kein Panel zur Identitätsprüfung. Es gibt keinen Schlüssel-Fingerabdruck zum Abgleich über einen anderen Kanal, und kein Urteil pro Verbindung, das dir sagt, ob diese Sitzung versiegelt hat. Das Sheet der verbundenen Provider ist die nächstgelegene Fläche.

Signierung und Updates

• Windows 10 21H2 oder neuer und Windows 11, x64 und ARM64, als Per-Machine-MSI von der Release-Seite. ARM64 ist ein nativer Build, keine Emulation.
• App, Dienst und Installer sind Authenticode-signiert.
• Der Treiber braucht mehr: ein EV-Zertifikat plus Microsofts Attestation-Signierung. Windows lädt nur attestation-signierte Treiber — das ist also die Ladeschranke, keine Zeremonie.
• Der Treiber liegt im MSI. Nichts wird zur Laufzeit geholt; was der Installer enthält, ist, was läuft. Gepinnte Fremd-Abhängigkeiten (wintun) werden vor dem Paketieren per Hash und Upstream-Signierer verifiziert.
• Updates sind die Aufgabe des Dienstes, nicht des Stores. Der Microsoft Store pusht keine Updates für EXE-/MSI-Einträge, und ein MSIX-Paket (die Art, die der Store automatisch aktualisiert) kann keinen Kernel-Treiber sauber tragen. Der Update-Pfad läuft also durch urnetworkd: holen, die Signatur verifizieren, die Binärdateien tauschen. Keine UAC-Abfrage pro Update, und Sicherheitskorrekturen warten nicht auf die Store-Prüfung. Windows sichert dieses Muster ebenfalls ab: Eine Dienst-Binärdatei lässt sich nur ersetzen, wenn alt und neu vom selben Herausgeber signiert sind.

Fehlerbehebung

Die App sagt, sie erreicht den Dienst nicht

Der Tunnel lebt in urnetworkd. Prüf in den Diensten (Services) — oder mit sc query urnetworkd —, dass er läuft; er ist registriert, automatisch zu starten und sich bei Ausfall zweimal selbst neu zu starten. Ist er gestoppt und will nicht starten, installier das MSI neu, das den Dienst neu registriert.

Verbunden, aber eine bestimmte App hat kein Internet

Prüf Einstellungen → App-Split-Regeln. Eine App auf der Ausschlussliste umgeht den Tunnel per Design, und hast du etwas ausgeschlossen, das dann einen Dienst über deine normale Verbindung nicht erreichen konnte, ist das die Regel bei der Arbeit. Änderungen greifen bei der nächsten Verbindung dieser App, denn schon offene Sockets behalten ihren Pfad — starte die App also neu.

Split-Tunneling pro App ist nicht verfügbar

Der Treiber ist ein optionales Feature im Installer. Führ das MSI erneut aus und stell sicher, dass das Split-Tunneling-Feature ausgewählt ist. Kernel-Treiber verlangen außerdem den attestation-signierten Build; ein selbst gebauter Treiber lädt nicht auf einer Maschine, die nicht im Test-Signing-Modus ist.

Websites sehen weiter meine echte Adresse

Fast immer IPv6. Der Tunnel trägt heute IPv4; deaktivier IPv6 auf dem Netzwerkadapter und teste neu. Am zweitwahrscheinlichsten: ein DNS-Pfad pro Adapter, den der Standard des Eigenes-DNS-Sheets (DoH durch den Tunnel) schließen soll.

Datenverkehr stockt nach dem Netzwechsel

Der Wechsel zwischen WLAN und Ethernet ändert, auf welches Interface der Dienst seine eigenen Sockets pinnen muss. Er achtet darauf und berechnet neu, aber wenn eine Sitzung klemmt, trenn und verbinde neu, um sauber neu aufzubauen.

Beim Beenden passiert nichts

Das ist das Design: Das Beenden der Tray-App lässt den Tunnel im Dienst weiterlaufen. Nutz Trennen.

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, Linux und der Browser.