# 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](/docs/getting-started-windows). Wie das
Netzwerk hinter der App funktioniert, erklärt der
[Überblick](/docs/overview).

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

| 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, mit denen sie 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; inaktiv in Auto |
| 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 |
| App-Split-Regeln (App split rules) | leer | gelistete Apps umgehen den Tunnel | ihr Datenverkehr ist ungeschützt |
| 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.
- 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](https://ur.io/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](https://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](https://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](/docs/overview).

| Modus | Operator sieht | Provider sieht | Standard und Verfügbarkeit |
|---|---|---|---|
| **Relay, versiegelt** | Konto und Quellverbindung, Provider-Zuordnung, Chiffretext mit Timing und Volumen | Ziele, die er nach außen trägt, eine Geräte-/Vertrags-ID, **nicht** deine echte IP | der ausgelieferte Standard: Post-Quanten-Verschlüsselung an im Drawer |
| **Relay, Standard** | Konto und Quellverbindung, Provider-Zuordnung, innere Ziele und Paketbytes | Ziele, die er nach außen trägt, eine Geräte-/Vertrags-ID, **nicht** deine echte IP | opt-in: Post-Quanten-Verschlüsselung ausschalten |
| **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.

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](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 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](/docs/overview) 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](/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),
[Linux](/docs/getting-started-linux) und der
[Browser](/docs/getting-started-browser).