Glossar für selbstgehostete VPNs: 34 Begriffe erklärt (WireGuard, Headscale, DERP, NAT Traversal…)

Beim Einstieg in selbstgehostete VPNs stößt man schnell auf Begriffe, die in Anleitungen verwendet werden, ohne sie zu definieren: AllowedIPs, DERP, NAT Traversal, MTU, PersistentKeepalive, DPI-Verschleierung… Dieses Glossar vereint die 34 wichtigsten Definitionen, thematisch geordnet, so geschrieben, dass sie in 30 Sekunden verstanden und direkt zitiert werden können.

Es ergänzt die technischen Anleitungen der Website: Für konkrete Konfigurationen siehe den WireGuard vs OpenVPN Leitfaden, den Tailscale vs Headscale Vergleich und den Linux Kill-Switch Leitfaden.

Inhaltsverzeichnis

• Protokolle und Kern-VPN
• Mesh-Netzwerk und Steuerungsebene
• NAT, Relays und Konnektivität
• Verschlüsselung und Kryptographie
• Routing und Konfiguration
• Verschleierung und DPI-Umgehung
• Lecks und Betriebssicherheit
• Schlüsselfunktionen

Protokolle und Kern-VPN

WireGuard

WireGuard ist ein modernes VPN-Protokoll, das im Linux-Kernel (Kernel-Space) implementiert ist. Mit weniger als 4.000 Zeilen Quellcode (im Vergleich zu 400.000 bei OpenVPN) minimiert es die Angriffsfläche und bietet eine Leistung, die nahe an der Rohdurchsatzrate liegt. Es verwendet ChaCha20-Poly1305 zur Verschlüsselung, Curve25519 für den Schlüsselaustausch und BLAKE2s zur Nachrichtenauthentifizierung. Empfohlener Standard für Selbsthosting im Jahr 2026.

OpenVPN

OpenVPN ist seit 2001 das Referenzprotokoll für Open-Source-VPNs. Im Gegensatz zu WireGuard läuft es im Userspace, was es portabler, aber langsamer macht. Es unterstützt TCP und UDP, konfiguriert leicht Port 443 über TCP, um DPI-Firewalls zu umgehen, und akzeptiert verschiedene Verschlüsselungssuiten (standardmäßig AES-256-GCM). Immer noch relevant für Umgebungen, die UDP blockieren oder Compliance-Audit-Trails erfordern.

IPsec / IKEv2

IPsec ist eine Sammlung von Netzwerkverschlüsselungsprotokollen, die auf IP-Ebene (Layer 3) arbeiten. IKEv2 ist das Schlüsselaustauschprotokoll, das mit IPsec verwendet wird — nativ auf iOS und macOS, sehr stabil bei Netzwerkwechseln (Wi-Fi ↔ 4G/5G). Weniger leistungsfähig als WireGuard im Rohdurchsatz, aber nativ in Apple-Mobilbetriebssysteme integriert, ohne Anwendungsabhängigkeiten. Häufig in Unternehmens-VPN-Setups auf Routern verwendet.

VPN-Tunnel (Full Tunnel vs. Split Tunnel)

Ein VPN-Tunnel ist ein verschlüsselter Kanal zwischen zwei Punkten. Im Full Tunnel-Modus (AllowedIPs 0.0.0.0/0) wird der gesamte IP-Verkehr über das VPN geleitet — einschließlich Internetverkehr. Im Split Tunnel-Modus (eingeschränkte AllowedIPs) wird nur ein Teil des Verkehrs durch den Tunnel geleitet, der Rest verlässt direkt. Split Tunneling reduziert die Last auf dem VPN-Server und verbessert die Latenz für lokale Verbindungen.

Mesh-Netzwerk und Steuerungsebene

Mesh-Netzwerk

Ein Mesh-Netzwerk ist eine Netzwerktopologie, bei der jeder Knoten direkt mit allen anderen kommunizieren kann, ohne dass ein zentraler Knoten erforderlich ist. Im VPN-Kontext bedeutet dies, dass jedes Gerät, das mit dem Mesh verbunden ist, die anderen direkt erreichen kann — im Gegensatz zu einer Hub-and-Spoke-Topologie, bei der alles über einen zentralen Server läuft. Tailscale und Headscale erstellen automatisch ein WireGuard-Mesh zwischen allen registrierten Geräten.

Tailscale

Tailscale ist ein auf WireGuard basierendes Mesh-VPN, das als SaaS verwaltet wird. Es automatisiert den Schlüsselaustausch, NAT Traversal, ACLs und DNS über seine in den USA gehostete Steuerungsebene. Kostenlos für bis zu 100 Geräte zur privaten Nutzung. Der Datenpfad (Verkehr zwischen Geräten) ist mit WireGuard Ende-zu-Ende verschlüsselt — Tailscale Inc. kann den Inhalt nicht sehen. Die Steuerungsebene (die Verbindungen orchestriert) bleibt unter ihrer Kontrolle.

Headscale

Headscale ist eine Open-Source-Implementierung der Tailscale-Steuerungsebene, die auf jedem Linux-VPS selbst gehostet werden kann. Es ist mit offiziellen Tailscale-Clients auf allen Betriebssystemen kompatibel. Es bietet die gleiche Benutzererfahrung (MagicDNS, ACLs, Exit Nodes), jedoch ohne Abhängigkeit von den Servern von Tailscale Inc. Die Steuerungsebene läuft auf Ihrem eigenen VPS — siehe den Headscale-Leitfaden für die vollständige Bereitstellung.

Steuerungsebene vs. Datenebene

Die Steuerungsebene ist das Gehirn des VPNs: Sie orchestriert die Geräteanmeldung, den öffentlichen Schlüsselaustausch, ACLs und die Konfigurationsverteilung. Bei Tailscale ist es der SaaS-Dienst von Tailscale Inc.; bei Headscale ist es Ihr eigener VPS. Die Datenebene ist der tatsächliche verschlüsselte Datenfluss zwischen Geräten — sie verwendet direkt WireGuard, unabhängig von der Steuerungsebene. Selbst wenn die Steuerungsebene kompromittiert wird, bleibt der Datenverkehr der Datenebene verschlüsselt.

MagicDNS

MagicDNS ist die automatische DNS-Funktion von Tailscale und Headscale, die jedem Gerät im Mesh einen stabilen Domainnamen zuweist (machine.tailnet.ts.net). Ohne MagicDNS müssten Sie sich die statische IP-Adresse jedes Geräts merken (z. B. 100.64.0.x). MagicDNS eliminiert die Notwendigkeit, eine /etc/hosts-Datei oder einen internen DNS-Server zu pflegen, und vereinfacht Automatisierungsskripte.

Exit Node

Ein Exit Node ist ein Gerät im Tailscale- (oder Headscale-) Mesh, das so konfiguriert ist, dass es den gesamten Internetverkehr anderer Geräte routet — ähnlich wie ein traditionelles VPN. Wenn Sie den Exit Node auf einem Gerät aktivieren, wird Ihr gesamter ausgehender Verkehr durch dieses geleitet, bevor er das Internet erreicht. Nützlich, um einer entfernten Maschine eine feste IP zu geben oder den Verkehr von öffentlichem WLAN zu verschlüsseln, indem ein VPS als Exit Node verwendet wird. Leitfaden: Tailscale Exit Node.

NAT, Relays und Konnektivität

NAT (Network Address Translation)

NAT ist der Mechanismus, durch den ein Router private IP-Adressen (192.168.x.x, 10.x.x.x) für ausgehenden Verkehr in eine öffentliche Adresse übersetzt und den Prozess für eingehenden Verkehr umkehrt. Fast alle privaten und mobilen Verbindungen befinden sich hinter einem NAT, was direkte eingehende Verbindungen ohne manuelle Konfiguration (Portweiterleitung) unmöglich macht. Dies ist das Kernproblem, das NAT Traversal zu lösen versucht.

NAT Traversal (Hole Punching)

NAT Traversal ist die Sammlung von Techniken, die es zwei Maschinen hinter separaten NATs ermöglichen, sich direkt über UDP zu erreichen, ohne Portweiterleitung. Die Haupttechnik (Hole Punching) besteht darin, dass beide Peers gleichzeitig UDP-Pakete aneinander senden — beide NATs öffnen dann einen Eintrag in ihrer Verbindungstabelle, der bidirektionalen Verkehr ermöglicht. Tailscale verwendet STUN/ICE, um diesen Prozess zu orchestrieren.

DERP (Designated Encrypted Relay for Packets)

DERP ist Tailscales TCP-Relay-Netzwerk, das aktiviert wird, wenn das direkte NAT Traversal fehlschlägt (symmetrisches NAT, blockierter UDP-Port). Der Verkehr wird über einen DERP-Server geleitet, bleibt jedoch mit WireGuard Ende-zu-Ende verschlüsselt — der Server sieht nur verschlüsselte Pakete. DERP ist langsamer als eine direkte Verbindung, garantiert jedoch die Konnektivität in allen Netzwerkkontexten. Headscale kann Tailscales DERP-Server verwenden oder eigene bereitstellen.

Portweiterleitung

Portweiterleitung besteht darin, einen Router oder eine Firewall so zu konfigurieren, dass eingehende Verbindungen auf einem bestimmten Port an eine interne Maschine weitergeleitet werden. Für ein selbstgehostetes WireGuard-VPN auf einem VPS ist dies im Allgemeinen nicht erforderlich (der VPS hat eine direkte öffentliche IP). Für einen WireGuard-Server zu Hause (hinter einem ISP-NAT) ist jedoch eine UDP-Portweiterleitung auf dem WireGuard-Port (standardmäßig 51820) erforderlich.

Endpoint

In WireGuard ist ein Endpoint die öffentliche IP-Adresse und der UDP-Port eines Peers: 203.0.113.42:51820. WireGuard merkt sich den zuletzt bekannten Endpoint jedes Peers und aktualisiert diese Informationen automatisch, wenn sich die IP ändert (Mobilfunknetz, dynamische IP). Der Endpoint ist auf der Client-Seite nicht festgelegt (er kann 0.0.0.0:0 sein, wenn der Client keine feste IP hat), aber der Server muss einen stabilen Endpoint oder Domainnamen haben.

Handshake

Das WireGuard-Handshake ist der initiale kryptografische Austausch, der eine verschlüsselte Sitzung zwischen zwei Peers etabliert. Es verwendet Curve25519 (Diffie-Hellman-Schlüsselaustausch) und wird in weniger als einer Millisekunde abgeschlossen. WireGuard erneuert das Handshake automatisch alle 3 Minuten, um perfekte Vorwärtsgeheimnis zu gewährleisten — jede Sitzung hat ihren eigenen flüchtigen Schlüssel. Wenn 3 Minuten lang kein Verkehr ausgetauscht wird, wird vor dem nächsten Paket ein neues Handshake ausgelöst.

PersistentKeepalive

PersistentKeepalive ist ein WireGuard-Parameter, der in regelmäßigen Abständen (in Sekunden) ein leeres UDP-Paket sendet, um den NAT-Eintrag zwischen Client und Server offen zu halten. Empfohlener Wert: 25 Sekunden (unterhalb des Standard-NAT-Timeouts von 30 Sekunden). Ohne Keepalive verliert ein Client hinter einem NAT seine Sitzung nach einigen Minuten Inaktivität und muss ein Handshake neu starten. Essentiell für mobile Clients.

Verschlüsselung und Kryptographie

Curve25519

Curve25519 ist die elliptische Kurve, die von WireGuard für den Diffie-Hellman-Schlüsselaustausch (ECDH) verwendet wird. Sie bietet ein Sicherheitsniveau, das RSA-3072 entspricht, mit Schlüsseln von nur 32 Bytes, was das Handshake beschleunigt und den Speicherverbrauch reduziert. Entwickelt, um Timing-Angriffen zu widerstehen. Jeder WireGuard-Peer generiert ein Curve25519-Schlüsselpaar: privater Schlüssel (32 Bytes, geheim) und öffentlicher Schlüssel (32 Bytes, mit Peers geteilt).

ChaCha20-Poly1305

ChaCha20-Poly1305 ist die AEAD (Authenticated Encryption with Associated Data) Suite, die von WireGuard zur Verschlüsselung und Authentifizierung von Paketen verwendet wird. ChaCha20 ist der Stromchiffre; Poly1305 ist der MAC, der die Integrität garantiert. Diese Suite ist besonders schnell auf Prozessoren ohne AES-NI-Beschleunigung (ARM auf Raspberry Pi, MIPS auf Routern) und widersteht strukturell Timing-Angriffen.

BLAKE2s

BLAKE2s ist die kryptografische Hash-Funktion, die von WireGuard zur Nachrichtenauthentifizierung und zur Ableitung von Sitzungsschlüsseln verwendet wird. Eine Variante von BLAKE2, die für 32-Bit- und eingebettete Prozessoren optimiert ist. Schneller als SHA-256 auf diesen Architekturen, während sie gleichwertige Sicherheitsmerkmale beibehält. Wird im WireGuard-Handshake-Protokoll verwendet, um flüchtige Schlüssel und Sitzungsdaten zu mischen.

Perfekte Vorwärtsgeheimnis (PFS)

Perfekte Vorwärtsgeheimnis garantiert, dass das Kompromittieren eines Sitzungsschlüssels nicht die Entschlüsselung vergangener oder zukünftiger Sitzungen ermöglicht. WireGuard implementiert dies nativ: Bei jedem Handshake (alle 3 Minuten) werden neue flüchtige Curve25519-Schlüssel generiert und nach Gebrauch zerstört. Selbst wenn ein Angreifer verschlüsselten Verkehr aufzeichnet und später den statischen privaten Schlüssel eines Peers kompromittiert, kann er keine früheren Sitzungen wiederherstellen.

WireGuard Öffentlicher / Privater Schlüssel

WireGuard verwendet asymmetrische Kryptographie zur Authentifizierung. Der private Schlüssel (32 Bytes, Base64-Format) verlässt niemals das Gerät und signiert Handshakes. Der öffentliche Schlüssel wird aus dem privaten Schlüssel abgeleitet und mit Peers geteilt — er ist der Identifikator eines Peers in WireGuard. Jeder Peer in einer WireGuard-Konfiguration wird durch seinen öffentlichen Schlüssel im [Peer]-Abschnitt identifiziert. Der Befehl wg genkey | tee private.key | wg pubkey > public.key generiert ein Schlüsselpaar.

Routing und Konfiguration

AllowedIPs

AllowedIPs ist der wichtigste WireGuard-Konfigurationsparameter auf der Peer-Seite. Er definiert gleichzeitig die Routen, die in den Tunnel gesendet werden (jedes Paket, das für diese Bereiche bestimmt ist, geht durch diesen Peer) und die Whitelist der akzeptierten Quell-IPs von diesem Peer. 0.0.0.0/0, ::/0 = Full Tunnel (aller Verkehr). 10.0.0.0/24 = nur dieses Subnetz. Die AllowedIPs eines Peers auf der Serverseite definieren, welche interne IP diesem Client zugewiesen wird.

MTU (Maximum Transmission Unit)

MTU ist die maximale Größe eines Netzwerkpakets in Bytes. Für WireGuard über Ethernet (MTU 1500) muss die Tunnel-MTU um 60 Bytes für WireGuard/UDP/IP-Overhead reduziert werden: Standardempfehlung von 1420 Bytes. Eine falsch konfigurierte MTU verursacht stille Fragmentierung oder Verbindungen, die auf bestimmten Websites "hängen" (insbesondere TLS). Eingestellt im [Interface]-Abschnitt der WireGuard-Konfiguration. Testen mit ping -M do -s 1400 8.8.8.8.

DNS-Leck

Ein DNS-Leck tritt auf, wenn DNS-Anfragen (Domainnamenauflösung) außerhalb des VPN-Tunnels austreten und über den ISP oder den OS-Resolver gehen. Ergebnis: Ihr ISP sieht, welche Domains Sie besuchen, trotz aktivem VPN. In WireGuard erzwingt die Konfiguration DNS = 1.1.1.1 im [Interface]-Abschnitt, dass alle DNS-Anfragen in den Tunnel gehen. Vollständiger Präventionsleitfaden: WireGuard DNS-Leck-Prävention.

PostUp / PostDown

PostUp und PostDown sind WireGuard-Konfigurationshooks, die Shell-Befehle ausführen, wenn die Schnittstelle startet und stoppt. Verwendet, um iptables-Regeln zu konfigurieren (NAT-Maskerade, Kill-Switch), IP-Weiterleitung zu aktivieren (sysctl net.ipv4.ip_forward=1) oder Überwachungsskripte zu starten. Der PostUp-Befehl läuft nach wg-quick up; PostDown nach wg-quick down. Essentiell für Maskerade und systemd Kill-Switch.

wg-quick

wg-quick ist das High-Level-Konfigurationstool, das mit WireGuard geliefert wird und die Verwaltung von Schnittstellen vereinfacht. Es liest .conf-Dateien aus /etc/wireguard/, erstellt die Netzwerkschnittstelle, konfiguriert Routen, DNS und führt PostUp/PostDown-Hooks aus. Hauptbefehle: wg-quick up wg0, wg-quick down wg0. Es erstellt automatisch Routen für AllowedIPs und verwaltet das Standardrouting im Full Tunnel-Modus. Unterschied zu wg (dem Low-Level-Befehl).

Verschleierung und DPI-Umgehung

DPI (Deep Packet Inspection)

DPI ist eine Netzwerkanalysetechnik, die den Inhalt von Paketen (nicht nur die Header) untersucht, um Protokolle zu identifizieren, den Verkehr zu filtern oder VPNs zu erkennen. Unternehmensfirewalls, Regierungen (Chinesische Große Firewall) und einige ISPs verwenden DPI, um WireGuard oder OpenVPN zu blockieren. WireGuard ist durch DPI erkennbar, da es eine charakteristische UDP-Signatur hat. Verschleierung zielt darauf ab, diesen Verkehr als normalen HTTPS zu tarnen.

Verschleierung

VPN-Verschleierung tarnt verschlüsselten Verkehr, sodass er wie gewöhnlicher HTTPS-Verkehr aussieht, was die Erkennung durch DPI erschwert. Häufige Techniken: wstunnel (Tunneln von WireGuard in WebSocket auf Port 443), Cloak (obfsproxy-Plugin für OpenVPN), Shadowsocks (verschlüsselter SOCKS5-Proxy), V2Ray VMess/VLESS. Verschleierung ist in Netzwerken mit aggressiver DPI (China, Iran, Unternehmensnetzwerke) notwendig. Leitfaden: Anti-DPI-Umgehung 2026.

wstunnel

wstunnel ist ein Tool, das UDP-Verkehr (insbesondere WireGuard) in einer WebSocket-Verbindung auf Port 443 (HTTPS) kapselt. Auf der Client-Seite hört wstunnel auf einem lokalen UDP-Port und leitet an den entfernten wstunnel-Server über WebSocket weiter. Auf der Serverseite dekapsuliert wstunnel und leitet an den lokalen WireGuard-Port weiter. Ergebnis: Alles sieht von außen wie HTTPS-Verkehr aus. Detaillierter Leitfaden: wstunnel TCP über WebSocket.

Shadowsocks

Shadowsocks ist ein verschlüsseltes SOCKS5-Proxy-Protokoll, das ursprünglich entwickelt wurde, um die Chinesische Große Firewall zu umgehen. Es verschlüsselt den Verkehr mit AES-256-GCM oder ChaCha20-Poly1305 und tarnt ihn als HTTPS-Verkehr. Unterschied zu einem VPN: Shadowsocks ist ein Anwendungsproxy, kein vollständiger Netzwerktunnel. Kann mit WireGuard kombiniert werden (Shadowsocks als Transport) für eine doppelte Verschleierungsschicht. Siehe Shadowsocks vs VPN.

V2Ray / VMess / VLESS

V2Ray ist ein Multi-Protokoll-Proxy- und Tunneling-Framework. VMess ist sein proprietäres Protokoll (Authentifizierung, Verschlüsselung, HTTPS-Tarnung); VLESS ist seine leichte Version ohne eingebettete Verschlüsselung (delegiert an TLS). Beide unterstützen mehrere Transporte (WebSocket, gRPC, HTTP/2) zur Umgehung von DPI. V2Ray ist komplexer zu konfigurieren als WireGuard oder Shadowsocks, bietet jedoch die besten Tarnfähigkeiten in Umgebungen mit fortschrittlicher DPI.

Lecks und Betriebssicherheit

WebRTC-Leck

WebRTC ist eine Browser-API für Peer-to-Peer-Kommunikation. Um zu funktionieren, fragt es alle Netzwerkschnittstellen auf der Maschine ab — einschließlich der realen IP vor der VPN-Verschleierung. Eine Website kann somit die reale IP über JavaScript abrufen, trotz aktivem Tunnel. Lösung für Selbsthosting: Konfigurieren Sie den WireGuard-Client auf Betriebssystemebene (nicht nur im Browser) und aktivieren Sie den WebRTC-Schutz im Browser (Firefox: media.peerconnection.enabled = false).

IPv6-Leck

Wenn Ihr VPS oder Netzwerk IPv6 unterstützt und Ihre WireGuard-Konfiguration nur IPv4 tunnelt, verlassen IPv6-Verbindungen im Klartext und offenbaren Ihre echte Identität. Lösung: Fügen Sie ::/0 zu AllowedIPs hinzu (vollständiger IPv6-Tunnel) oder deaktivieren Sie IPv6 auf der Betriebssystem-Schnittstellenebene, wenn Ihre Konfiguration es nicht unterstützt. WireGuard unterstützt nativ IPv6 — einfach in die [Interface]-Konfiguration (Adresse) und [Peer] (AllowedIPs) aufnehmen.

Schlüsselfunktionen

Kill Switch

Der Kill Switch kappt alle Netzwerkverbindungen, wenn der VPN-Tunnel abbricht, um die Exposition der realen IP zu verhindern. Unter Linux mit WireGuard wird er über iptables/nftables-Regeln im PostUp-Hook implementiert: Blockieren Sie allen Verkehr außerhalb der wg0-Schnittstelle, außer dem Verkehr zum WireGuard-Endpoint. Vollständiger Leitfaden mit systemd und iptables: VPN Kill Switch Linux.

Split Tunneling

Split Tunneling leitet nur einen Teil des Verkehrs durch das VPN, der Rest verlässt direkt. In WireGuard wird es über AllowedIPs konfiguriert: indem nur die Zielsubnetze aufgelistet werden (z. B. 10.8.0.0/24), verlässt der Rest des Verkehrs über die normale Schnittstelle. Nützlich, um auf VPN-Netzwerkressourcen (NAS, interne Dienste) zuzugreifen und gleichzeitig optimale Latenz für Internetverkehr zu erhalten.

ACLs (Access Control Lists)

ACLs in Tailscale und Headscale definieren, welche Maschinen im Mesh miteinander kommunizieren können. In JSON (HuJSON-Format in Tailscale) konfiguriert, ermöglichen sie die Zugriffsegmentierung: zum Beispiel, Produktionsserver dürfen miteinander kommunizieren, aber persönliche Maschinen dürfen nicht direkt auf sie zugreifen. Ohne ACLs können alle Mesh-Geräte einander sehen und miteinander kommunizieren — praktisch, aber nicht geeignet für den professionellen Einsatz in mehreren Teams.

Subnet Router

Ein Subnet Router ist ein Tailscale/Headscale-Gerät, das so konfiguriert ist, dass es ein privates Subnetz an den Rest des Meshs ankündigt. Beispiel: Ein NAS im 192.168.1.0/24 kann aus dem Internet zugänglich gemacht werden, wenn eine Maschine in diesem Netzwerk als Subnet Router fungiert und diesen Bereich ankündigt. Auf diese Weise können andere Mesh-Geräte alle LAN-Maschinen erreichen, ohne dass jede einzeln in Tailscale registriert werden muss.

Peer-to-Peer (Direct P2P)

Im Kontext von Tailscale/Headscale bezieht sich P2P auf direkte Verbindungen zwischen zwei Geräten, ohne über einen Zwischenserver zu gehen. Tailscale versucht immer, eine direkte P2P-Verbindung über NAT Traversal herzustellen, bevor es auf DERP zurückgreift. Eine P2P-Verbindung bietet minimale Latenz (direktes UDP zwischen den beiden Endpunkten). Die tailscale status-Schnittstelle zeigt an, ob eine Verbindung direkt (Direct) oder über Relay (Relay) erfolgt.

Was dieses Glossar nicht ersetzt

Diese Definitionen bieten das grundlegende Vokabular, aber echtes Verständnis kommt durch Praxis. Um weiterzugehen: Der WireGuard vs OpenVPN Vergleich erläutert konkrete Entscheidungen nach Anwendungsfall, der Tailscale vs Headscale Leitfaden vergleicht die beiden Steuerungsebenen-Ansätze, und der Anti-DPI-Leitfaden behandelt Verschleierung von A bis Z.

Veröffentlicht am 12. Juni 2026. Definitionen basieren auf offiziellen WireGuard-Spezifikationen (Jason A. Donenfeld, whitepapers.wireguard.com), Tailscale-Dokumentation (tailscale.com/kb), Headscale-Quellcode (github.com/juanfont/headscale) und relevanten IETF-RFCs. Wird kontinuierlich aktualisiert.