Von Tailscale langsam: DERP-Relay oder direkte Verbindung?
Tailscale über DERP ist langsam, direkt fast mit Leitungsrate. Zwei Befehle zeigen den Pfad; bei blockiertem UDP und hartem NAT helfen konkrete VPS-Fixes.
Warum Tailscale langsam ist: Relay statt direkter Verbindung
Tailscale ist langsam, wenn die Verbindung über einen gemeinsam genutzten DERP-Server weitergeleitet wird. Bei einer direkten Verbindung ist die Geschwindigkeit dagegen nahezu so hoch wie die Leitungsrate. Eine direkte Verbindung überträgt verschlüsselte WireGuard-Pakete unmittelbar von einem Rechner zum anderen. Daher erreicht sie die Geschwindigkeit, die die beiden Internetverbindungen ermöglichen. Bei einer Relay-Verbindung wird jedes Paket zunächst über einen dritten Rechner gesendet. Daher übernimmt sie die Latenz dieses Rechners und den Bandbreitenanteil, der Ihnen dort zur Verfügung steht. Wie stark sich das auswirkt, hängt vom Relay ab. Tailscale bezeichnet seine DERP-Server als „generally slower than direct connections“. Ein selbst betriebener Peer-Relay ist dagegen „usually faster than DERP“ und erreichte in frühen Tests von Tailscale einen Durchsatz „nearing that of a direct connection“. Auf der eigenen Performance-Seite fasst Tailscale die allgemeine Regel in einem Satz zusammen: „Direct connections nearly always result in lower latency and higher throughput.“
Innerhalb Ihrer Anwendung ist der Unterschied nicht sichtbar. Der Dateikopiervorgang ist einfach langsam. Die SSH-Sitzung reagiert einfach verzögert. Daher müssen Sie zuerst feststellen, welche Verbindungsart derzeit verwendet wird. Zwei Befehle liefern diese Information in weniger als einer Minute. Danach geht es darum, die Ursache zu beheben. Die Grundlagen sollten Sie vorab kennen, weil der Koordinationsserver und die WireGuard-Datenebene getrennte Systeme sind und nur die Datenebene Ihre Daten überträgt.
Die beiden Befehle, die direkte von weitergeleiteten Verbindungen unterscheiden
Senden Sie Datenverkehr an den Peer, bevor Sie etwas messen. Tailscale baut einen Pfad bei Bedarf auf. Ein Peer, mit dem Sie heute noch nicht kommuniziert haben, hat möglicherweise noch keinen Pfad ausgehandelt. Dann würden Sie einen veralteten Status auswerten. Ein ping oder ein curl an die Tailnet-Adresse des Peers genügt.
tailscale statusDie Antwort steht am Ende der Zeile des jeweiligen Peers.
100.113.160.82 device-a tagged-devices linux active; offers exit node; direct 203.0.113.9:41641
100.104.93.78 device-b you@ android active; relay "tor"direct gefolgt von einer Adresse und einem Port bedeutet, dass die Pakete direkt an diese Adresse gesendet werden. relay "tor" bezeichnet einen DERP-Server (designated encrypted relay for packets). Das ist eine der Relay-Maschinen von Tailscale. Jedes Paket an diesen Peer wird über diesen Server übertragen. Ein dritter Wert, peer-relay, wird im nächsten Abschnitt behandelt.
tailscale ping device-bEine funktionierende Verbindung beginnt als Relay-Verbindung und wechselt anschließend den Pfad. Die ersten Pakete laufen über den nächstgelegenen DERP-Server, während die beiden Maschinen den Pfad aushandeln. Danach ändert sich der Pfad:
pong from device-b (100.113.160.82) via DERP(tor) in 51ms
pong from device-b (100.113.160.82) via DERP(tor) in 48ms
pong from device-b (100.113.160.82) via 203.0.113.9:41641 in 35msDer Lauf endet an dieser Stelle, weil --until-direct standardmäßig auf true gesetzt ist. Eine Verbindung, die nicht direkt hergestellt werden kann, sieht stattdessen so aus. Sie endet mit einem Satz und nicht mit einem Pong:
pong from device-b (100.104.93.78) via DERP(tor) in 53ms
pong from device-b (100.104.93.78) via DERP(tor) in 60ms
direct connection not establishedDie letzte Zeile enthält das Ergebnis. Tailscale hat alle vorgesehenen Prüfungen gesendet und keinen direkten Pfad gefunden. Um einen weitergeleiteten Pfad weiter zu überwachen, statt beim ersten direkten Pfad zu stoppen, führen Sie tailscale ping --until-direct=false -c 20 device-b aus und prüfen Sie die Streuung der Latenzwerte. Ein weitergeleiteter Pfad weist normalerweise sowohl höhere Werte als auch größere Schwankungen auf, weil dabei zwei Internetpfade über eine von Ihnen nicht kontrollierte Maschine verbunden werden.
Was bedeutet peer-relay in tailscale status?
Ein Peer-Relay ist eine Maschine in Ihrem eigenen tailnet, die den Datenverkehr anderer Mitglieder weiterleitet, wenn keine direkte Verbindung möglich ist. Sie lauscht an einem von Ihnen festgelegten UDP-Port, und der Daemon verwendet sie bevorzugt vor DERP. tailscale status kennzeichnet eine solche Verbindung peer-relay, und tailscale ping gibt den Endpunkt des Relays aus:
pong from device-b (100.97.143.93) via peer-relay(203.0.113.42:40000:vni:1) in 4ms
direct connection not establishedLesen Sie die Ausgabe genau. Es handelt sich weiterhin nicht um eine direkte Verbindung, daher endet der Lauf weiterhin mit direct connection not established. Geändert hat sich nur, wer den Datenverkehr weiterleitet. Ein VPS mit öffentlicher IP-Adresse und großzügigem Bandbreitenlimit ist für Ihren eigenen Datenverkehr ein wesentlich besseres Relay als ein gemeinsam genutzter DERP-Knoten. Deshalb ist diese Funktion für alle relevant, die einen Server mieten. Aktivieren Sie sie auf der Maschine mit dem öffentlich erreichbaren Endpunkt:
sudo tailscale set --relay-server-port=40000Mit dem Port 0 wird ein zufällig ausgewählter, nicht belegter Port verwendet. Eine leere Zeichenfolge deaktiviert den Relay-Server. Erteilen Sie den Clientgeräten anschließend in der tailnet-Richtliniendatei die Berechtigung, ihn mit der Fähigkeit tailscale.com/cap/relay zu verwenden:
{
"grants": [
{
"src": ["tag:us-east-vpc"],
"dst": ["tag:us-east-relays"],
"app": {
"tailscale.com/cap/relay": []
}
}
]
}Sowohl das Relaygerät als auch die Clientgeräte benötigen Tailscale 1.86 oder höher. Prüfen Sie daher auf jedem Gerät mit tailscale version die Version, bevor Sie eine Stunde mit der Richtliniendatei verbringen. Die Reihenfolge, in der der Daemon Verbindungen versucht, sollten Sie sich merken. Zuerst versucht er eine direkte Verbindung. Wenn das fehlschlägt, sucht er nach einem Peer-Relay, das er verwenden darf. Wenn kein solches Relay vorhanden ist, verwendet er DERP. DERP ist nie vollständig aus dem Ablauf entfernt, weil es auch der Kanal ist, über den die beiden Maschinen zunächst die Verbindung aushandeln.
Ursache 1: Eine Egress-Firewall blockiert UDP
Tailscale dokumentiert zwei Gründe dafür, dass eine Verbindung über ein Relay läuft. Der erste ist blockiertes UDP. Fragen Sie den Rechner direkt ab:
tailscale netcheckDie Ausgabe ist hier gekürzt. Das oberste Feld ist ausschlaggebend:
Report:
* UDP: true
* IPv4: yes, 203.0.113.9:41641
* IPv6: no
* MappingVariesByDestIP: false
* PortMapping:
* Nearest DERP: DallasUDP: false ist der deutlichste Hinweis, den Sie erhalten werden. Der Wert bedeutet, dass der Rechner kein UDP-Paket an die Probe-Server von Tailscale senden konnte. Laut der CLI-Referenz von Tailscale ist es in diesem Fall „unwahrscheinlich, dass Tailscale Punkt-zu-Punkt-Verbindungen herstellen kann“. Der Datenverkehr läuft dann über DERP über TCP-Port 443. Dieser Fallback erklärt, warum der Rechner weiterhin vollständig funktionsfähig wirkt: Er ist verbunden, erreichbar, und jedes Byte wird über ein Relay weitergeleitet. netcheck beschreibt das Netzwerk und nicht eine einzelne Verbindung. Prüfen Sie daher mit tailscale status oder tailscale ping, welchen Pfad ein Peer tatsächlich verwendet, bevor Sie Regeln ändern.
Es sind zwei Regeln für ausgehenden Datenverkehr dokumentiert. „Lassen Sie Ihre internen Geräte UDP von :41641 zu *:* starten.“ Das ist der eigentliche WireGuard-Datenverkehr. Die zweite Regel lautet: „Lassen Sie Ihre internen Geräte UDP zu *:3478 starten.“ Dabei handelt es sich um STUN (Session Traversal Utilities for NAT), das Protokoll, mit dem der Rechner seine eigene öffentliche Adresse und seinen Port ermittelt. Verwenden Sie Platzhalter für die Ziele. Tailscale fügt im Laufe der Zeit Relay-Server hinzu. Eine manuell gepflegte Liste von Adressen ist daher innerhalb eines Jahres veraltet.
Auf einem gemieteten Server ist meistens eine restriktive Egress-Richtlinie die Ursache. Entweder stammt sie aus einem gehärteten Image, oder der Provider wendet sie vorgelagert an. Prüfen Sie zuerst die Standardrichtlinie für ausgehenden Datenverkehr:
sudo ufw status verbose
sudo nft list rulesetDefault: deny (incoming), allow (outgoing) ist in Ordnung und nicht die Ursache. Ein Standardwert für ausgehenden Datenverkehr von deny mit einer kurzen Allowlist für TCP 443 und DNS führt genau dazu, dass ein Server dauerhaft über ein Relay verbunden bleibt. Der DERP-Pfad über TCP 443 passt durch diese Freigabe, der direkte Pfad jedoch nicht. Wo diese Regeln tatsächlich definiert sind, hängt davon ab, ob der Server darunter iptables oder nftables verwendet. Das Bearbeiten der falschen Regel ist eine häufige Ursache dafür, dass sich nichts ändert.
Auch die eingehende Seite ist wichtig. Ein VPS besitzt eine öffentliche IP-Adresse und kann daher die besser erreichbare Seite des Verbindungspaars sein. Akzeptiert seine Firewall eingehendes UDP auf dem Port, auf dem tailscaled lauscht, können Peers hinter problematischen Heimroutern ihn ohne zusätzliche Maßnahmen erreichen. Ermitteln Sie den tatsächlich verwendeten Port:
sudo ss -lunp | grep tailscaled
sudo ufw allow 41641/udp41641 ist der standardmäßige statische Port. In einem Tailnet mit aktivierter Einstellung randomizeClientPort wählen die Clients stattdessen einen zufälligen Port. Verwenden Sie in diesem Fall die tatsächliche Portnummer aus der Ausgabe von ss und nicht den Wert auf dieser Seite. Prüfen Sie anschließend das Control Panel Ihres Providers. Die meisten Hosts betreiben eine Netzwerk-Firewall, die von der Firewall innerhalb des Servers getrennt ist. Eine Regel, die Sie mit ufw hinzugefügt haben, hat auf diese Firewall keinen Einfluss.
Ursache 2: Symmetrisches NAT an einem oder beiden Enden
Die zweite dokumentierte Ursache ist symmetrisches NAT. NAT (Network Address Translation) bezeichnet die Übersetzung, die ein Router vornimmt, wenn er Ihre private Adresse in eine öffentliche Adresse umschreibt. Ein Router mit endpoint-unabhängigem Mapping verwendet für einen bestimmten internen Socket unabhängig vom Kommunikationspartner denselben öffentlichen Port. Bei symmetrischem NAT wird dagegen für jedes Ziel ein anderer öffentlicher Port vergeben. Die Adresse, die der Rechner von einem STUN-Server gelernt hat, ist dann nicht die Adresse, die ein Peer verwenden kann. Tailscale meldet dies in netcheck als MappingVariesByDestIP: true.
Ein einzelnes symmetrisches NAT ist überwindbar. Wenn die andere Seite einen stabilen öffentlichen Endpunkt hat, kann der Rechner hinter dem symmetrischen NAT weiterhin eine Verbindung zu ihr herstellen, und der Pfad wird aufgebaut. Zwei symmetrische NATs gleichzeitig verursachen den Fehler, weil keine Seite den Port vorhersagen kann, unter dem die andere Seite erreichbar sein wird.
Auf einem VPS mit öffentlicher IPv4-Adresse sollte dieses Feld normalerweise false anzeigen. Eine öffentliche Adresse bedeutet nicht immer, dass keine Übersetzung stattfindet. AWS dokumentiert beispielsweise, dass sein Internet-Gateway eine 1:1-NAT zwischen der öffentlichen IPv4-Adresse einer Instanz und ihrer privaten Adresse durchführt. Eine statische 1:1-Zuordnung wie diese verwendet unabhängig vom Kommunikationspartner denselben Port. Sie ist daher kein symmetrisches NAT, und das Feld zeigt weiterhin false an. Wenn es auf einem gemieteten Server true anzeigt, vergibt etwas im Netzwerk des Providers für jedes Ziel einen anderen Port. Keine Firewall-Regel innerhalb des Rechners kann das ändern. Ihre Möglichkeiten bestehen darin, einen Peer-Relay auf einem Rechner mit einem uneingeschränkt erreichbaren öffentlichen Endpunkt einzurichten oder die Workload zu verschieben. Auch in diesem Fall lohnt sich das Ankündigen Ihrer privaten Bereiche über einen Subnet Router, weil Sie dann nur einen funktionierenden Pfad in das Netzwerk benötigen und nicht für jedes darin befindliche Gerät einen eigenen.
Warum ein Exit Node langsamer wirkt, als Tailscale tatsächlich ist
Ein Exit Node ist ein zusätzlicher Hop, und viele machen dafür den Tunnel verantwortlich. Wenn ein Exit Node ausgewählt ist, verlässt eine Anfrage Ihren Laptop, durchquert den Tunnel zum VPS, verlässt den VPS in Richtung öffentliches Internet, und die Antwort kommt auf demselben Weg zurück. Selbst eine perfekt direkte Verbindung zu diesem VPS kann die gesamte Übertragung nicht schneller machen als die eigene Anbindung des VPS. Die zusätzliche Entfernung macht sich bei jedem Seitenaufruf bemerkbar.
Messen Sie die beiden Teilstrecken getrennt. Deaktivieren Sie den Exit Node und testen Sie anschließend nur den Tunnel zur Tailscale-Adresse des VPS:
sudo tailscale set --exit-node=
sudo apt install -y iperf3
iperf3 -sFühren Sie auf dem Client iperf3 -c 100.113.160.82 mit dieser Tailscale-Adresse als Ziel aus. Dieser Wert beschreibt Ihren Tunnel. Aktivieren Sie den Exit Node anschließend wieder mit sudo tailscale set --exit-node=100.113.160.82 und führen Sie einen normalen Geschwindigkeitstest ins öffentliche Internet aus. Dieser Wert umfasst den Tunnel und die Anbindung des VPS. Wenn der erste Wert gut und der zweite schlecht ist, liegt das Problem nicht bei Tailscale. Prüfen Sie dann das Netzwerk und die Dimensionierung des Exit Nodes. Mit tailscale exit-node list sehen Sie, welche Optionen verfügbar sind, wenn Sie nicht sicher sind, welchen Node Sie ausgewählt haben.
Die CPU ist der zweite begrenzende Faktor eines Exit Nodes. Tailscale empfiehlt, eine neuere CPU-Generation mit höherem Takt gegenüber einer größeren Anzahl von Kernen zu bevorzugen. Ein Plan mit mehr vCPUs ist daher nicht automatisch schneller. Auf einem ausgelasteten Shared Host entspricht die CPU-Leistung, die Ihnen zugesagt wurde, nicht unbedingt der tatsächlich verfügbaren Leistung. Steal Time durch einen stark ausgelasteten Nachbarn zeigt sich als Durchsatz, der sich im Laufe des Tages ändert, obwohl Sie auf Ihrer Seite nichts geändert haben.
Die zentrale Optimierung: rx-udp-gro-forwarding
Tailscale dokumentiert eine einzelne Linux-Einstellung. Sie gilt für Systeme, die Datenverkehr weiterleiten, also Exit Nodes und Subnet Routers. Ein gewöhnlicher Client profitiert davon nicht. Dafür benötigen Sie Tailscale 1.54 oder höher und den Linux-Kernel 6.2 oder höher. Prüfen Sie daher beides, bevor Sie Änderungen vornehmen:
tailscale version
uname -rAktivieren Sie anschließend die UDP-GRO-Weiterleitung (Generic Receive Offload) auf der Schnittstelle, die mit dem Internet verbunden ist:
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list offPrüfen Sie, ob die Einstellung übernommen wurde:
ethtool -k $NETDEV | grep -E 'rx-udp-gro-forwarding|rx-gro-list'Sie sollten rx-udp-gro-forwarding: on und rx-gro-list: off sehen. Das hilft, weil Tailscale UDP verwendet. Wenn der Kernel kleine UDP-Pakete auf dem Weiterleitungspfad zusammengefasst lässt, verarbeitet der Daemon bei gleicher Datenmenge weniger, dafür größere Segmente. ethtool -K bleibt nach einem Reboot nicht erhalten. Machen Sie die Einstellung daher dauerhaft. Auf einem System mit networkd-dispatcher:
printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscaleFühren Sie das Skript einmal manuell aus und prüfen Sie, ob sein Exit-Status 0 ist. Ein System, das Datenverkehr weiterleitet, benötigt außerdem grundsätzlich aktiviertes IP-Forwarding. Dabei handelt es sich um eine separate Einstellung und einen separaten Fehlerfall:
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.confWelche MTU verwendet Ihre tailscale0-Schnittstelle?
Raten Sie diesen Wert nicht, sondern lesen Sie ihn direkt auf dem System aus:
ip link show tailscale0Der Wert mtu in dieser Ausgabe wird tatsächlich für Ihren Tunnel verwendet. Er ist niedriger als der Wert 1500, den Ihre Ethernet-Schnittstelle meldet. Das ist beabsichtigt und kein Fehler. Jedes Paket, das Sie innerhalb des Tunnels senden, wird gekapselt: mit einem äußeren IP-Header von 20 Byte bei IPv4 oder 40 Byte bei IPv6, einem UDP-Header von 8 Byte sowie dem WireGuard-Framing und einem Authentifizierungs-Tag von 32 Byte. All das muss in die maximale Paketgröße passen, die der tatsächliche Netzwerkpfad übertragen kann. Tailscale wählt deshalb einen Wert, der auch bei Verbindungen funktioniert, die kein vollständiges Paket mit 1500 Byte übertragen können. Dazu gehören PPPoE-Verbindungen, einige Mobilfunknetze und IPv6-Tunnel.
Das Symptom eines MTU-Problems ist eindeutig. Diagnostizieren Sie es daher nicht allein anhand einer langsamen Verbindung. SSH reagiert, ping funktioniert, und große Übertragungen oder umfangreiche HTTPS-Seiten bleiben anschließend vollständig hängen, statt nur langsam zu laufen. Dieses Muster bedeutet, dass übergroße Pakete irgendwo verworfen werden und keine ICMP-Nachricht den Absender darüber informiert. Wenn Sie die tailscale0-MTU in Richtung 1500 erhöhen, verschlimmert sich das Problem, weil die Pakete, die bereits nicht in den Pfad passen, dadurch noch größer werden. Die korrekte Lösung besteht darin, die funktionierende Pfad-MTU per Halbierungssuche zu ermitteln und die TCP-MSS auf dem Router zu begrenzen, der den Datenverkehr weiterleitet. Der Verbindungstyp ändert daran nichts: Ein Relay-Pfad und ein direkter Pfad verwenden dieselbe Schnittstellen-MTU.
FAQ
Woher weiß ich, ob meine Tailscale-Verbindung direkt oder weitergeleitet ist?
Führen Sie tailscale status aus und lesen Sie das Ende der Zeile des Peers. direct 203.0.113.9:41641 bezeichnet eine direkte Verbindung, relay "tor" bedeutet, dass jedes Paket über diesen DERP-Server läuft, und peer-relay bedeutet, dass die Pakete über eine Maschine in Ihrem eigenen tailnet laufen. Für eine zweite Prüfung führen Sie tailscale ping <peer> aus: Ein funktionierender Pfad beginnt mit DERP und gibt anschließend einen Pong mit einer normalen Adresse und einem Port aus. Bei einem weitergeleiteten Pfad werden bis zum Ende des Laufs DERP-Pongs ausgegeben, der mit direct connection not established endet. Senden Sie zuerst Datenverkehr an den Peer, da Tailscale einen Pfad nur bei Bedarf aufbaut.
Warum erhält mein VPS nie eine direkte Verbindung?
Führen Sie tailscale netcheck auf dem VPS aus. Gibt der Befehl UDP: false aus, kann ausgehender UDP-Datenverkehr den Server nicht verlassen. Die häufigste Ursache ist eine Egress-Firewall. Laut Tailscale ist eine Punkt-zu-Punkt-Verbindung dann unwahrscheinlich. Bestätigen Sie mit tailscale status oder tailscale ping, dass der Peer DERP verwendet. DERP läuft über TCP 443. Deshalb wirkt die Maschine weiterhin als verbunden. Erlauben Sie ausgehenden UDP-Datenverkehr von Port 41641 zu jedem Ziel sowie ausgehenden UDP-Datenverkehr zu jedem Ziel auf Port 3478. Prüfen Sie sowohl die Netzwerk-Firewall Ihres Anbieters als auch die Firewall auf dem Server. Beide sind getrennte Kontrollen. Eine ufw-Regel wirkt nicht auf die Firewall des Anbieters.
Ist eine weitergeleitete Tailscale-Verbindung weniger sicher als eine direkte?
Nein. Ein DERP-Server leitet WireGuard-Pakete weiter, die er nicht entschlüsseln kann. Die Verschlüsselungsschlüssel werden auf Ihren Geräten erzeugt und verlassen diese nicht. Ein Relay verursacht zusätzliche Latenz und geringeren Durchsatz, aber keinen Verlust der Vertraulichkeit. Der Koordinationsserver steuert jedoch, welche Geräte voneinander erfahren. Die Trennung zwischen Schlüsselmaterial und Verbindungsmetadaten sollten Sie verstehen, bevor Sie entscheiden, welchen Teil Sie selbst hosten möchten.
Hilft die Einstellung rx-udp-gro-forwarding auf jeder Maschine?
Nein. Sie ist für Linux-Maschinen dokumentiert, die Datenverkehr für andere weiterleiten. Dazu gehören Exit Nodes und Subnet Routers. Ein Laptop oder ein Server, der nur mit seinen eigenen Peers kommuniziert, profitiert nicht davon. Außerdem sind Tailscale 1.54 oder höher und der Linux-Kernel 6.2 oder höher erforderlich. Prüfen Sie daher zuerst tailscale version und uname -r. Beachten Sie außerdem, dass ethtool -K nach einem Reboot zurückgesetzt wird, sofern Sie die Einstellung nicht dauerhaft speichern.
Ist Tailscale langsamer als reines WireGuard?
Beide verwenden WireGuard zur Verschlüsselung Ihres Datenverkehrs. Tailscale ergänzt den Verbindungsaufbau, den Sie bei plain WireGuard manuell konfigurieren müssen. Dieser Aufbau führt manchmal zu einer Verbindung über ein Relay. Plain WireGuard kann keine Verbindung über ein Relay herstellen. Es verbindet sich entweder direkt oder die Verbindung schlägt vollständig fehl. Vergleichen Sie daher gleichartige Konfigurationen. Führen Sie Benchmarks mit Tailscale nur aus, wenn tailscale status direct meldet. Wenn Sie zum Vergleich eine manuell konfigurierte Variante wünschen, umfasst ein selbst eingerichteter WireGuard-Server etwa vierzig Konfigurationszeilen. Der damit verbundene Kompromiss wird in dem Vergleich der beiden Ansätze erläutert.