VPN und WireGuard verstehen

Ein interner Server soll unterwegs erreichbar sein.

Du administrierst einen Linux-Server im Firmennetz und sitzt gerade in einem fremden WLAN. Der Server soll keine direkt aus dem Internet erreichbare SSH-Schnittstelle bekommen. Ein Virtual Private Network, kurz VPN, kann einen geschützten Netzweg zum vorgesehenen Gateway herstellen. Über diesen Weg erhält dein Rechner gezielten Zugriff auf interne Ziele. Der Tunnel ersetzt weder die Anmeldung am Server noch dessen Zugriffsrechte.

Ein VPN verpackt innere IP-Pakete in einen äußeren Transport. Bei einem verschlüsselten VPN können die dazwischenliegenden Netze den geschützten Inhalt nicht einfach mitlesen oder unbemerkt verändern. Sie sehen aber weiterhin beispielsweise die äußeren IP-Adressen, Paketgrößen und Zeitpunkte. Der Schutz reicht von einem VPN-Endpunkt bis zum anderen. Hinter dem Gateway ist die ursprüngliche Verbindung wieder ein eigener Kommunikationsweg.

Remote Access verbindet ein einzelnes Gerät mit einem entfernten Netz. Bei Site-to-Site verbinden Gateways zwei Standorte; dahinterliegende Geräte benötigen dann nicht alle einen eigenen VPN-Client. Beide Modelle brauchen passende Routen und Zugriffskontrollen. Ein Tunnel mit funktionierendem Handshake bedeutet noch nicht, dass ein gewünschter Dienst erreichbar oder für den Benutzer freigegeben ist.

Die Grundlagen zu IPv4, IPv6 und Routingtabellen sind dafür wichtiger als ein langer Satz kopierter Konfigurationszeilen. Hier wird das Zusammenspiel als Papierlabor erklärt. Es gibt keine Startbefehle und keine automatisch ausgeführten Änderungen an Hostrouting oder Firewall.

WireGuard kennt Peers und Schlüssel.

WireGuard ist ein VPN-Protokoll mit Implementierungen für verschiedene Betriebssysteme. Es transportiert IP-Pakete verschlüsselt über UDP. Ein Peer ist eine konfigurierte Gegenstelle, identifiziert durch ihren öffentlichen Schlüssel. „Client“ und „Server“ beschreiben in unseren Beispielen die Aufgaben der Geräte; im Protokoll bleiben beide Peers. Das Gateway besitzt keine besondere Fähigkeit, einem beliebigen unbekannten Client automatisch eine vertrauenswürdige Identität zu geben.

Jeder Endpunkt besitzt einen privaten und einen daraus abgeleiteten öffentlichen Schlüssel. Der private Schlüssel bleibt ausschließlich auf dem zugehörigen Gerät. Die Gegenstelle bekommt den öffentlichen Schlüssel über einen verifizierten Verwaltungsweg. Die Kryptografie authentifiziert den Besitz des passenden privaten Schlüssels. Sie beweist nicht von selbst, dass gerade die richtige Person vor dem Laptop sitzt. Gerätezuordnung, Betriebssystemschutz und Benutzeranmeldung müssen deshalb separat stimmen.

Der Handshake vereinbart Schlüssel für den geschützten Transport; die Datenverschlüsselung erfolgt mit Sitzungsschlüsseln, nicht durch das wiederholte direkte Verschlüsseln jedes Pakets mit dem statischen öffentlichen Schlüssel. WireGuard verwendet fest definierte moderne Verfahren, darunter ChaCha20-Poly1305. Die allgemeinen Unterschiede zwischen Schlüsselvereinbarung, Verschlüsselung und Integritätsschutz erklärt der Artikel zu Kryptografie, Hashes und Signaturen.

Ein Endpoint ist die äußere Adresse einer Gegenstelle samt UDP-Port. Sie ist von ihrer inneren Tunneladresse zu unterscheiden. Der Laptop muss das Gateway zunächst über sein vorhandenes Netz erreichen können. Beim mobilen Peer kann sich die äußere Adresse ändern; WireGuard kann einen authentifiziert erkannten neuen Endpoint übernehmen. Bei NAT oder einer zustandsbehafteten Firewall können Zuordnungen während langer Pausen auslaufen. Optionales PersistentKeepalive hält sie durch regelmäßige authentifizierte Pakete offen, ist aber nicht pauschal auf jedem Peer erforderlich.

AllowedIPs: Zielauswahl hinaus, Quellprüfung hinein.

WireGuard ordnet öffentlichen Schlüsseln IP-Präfixe zu. Diese Zuordnung heißt Cryptokey Routing. AllowedIPs hat zwei zusammengehörige Aufgaben, die leicht verwechselt werden:

1. Ausgehend: Wenn das Betriebssystem ein inneres IP-Paket an die WireGuard-Schnittstelle übergibt, bestimmt dessen Zieladresse den passenden Peer. Maßgeblich ist das am längsten passende Präfix in der Peerzuordnung.
2. Eingehend: Nach erfolgreicher Entschlüsselung und Authentifizierung wird geprüft, ob die innere Quelladresse zum authentifizierten Peer gehört. Ein Laptop soll nicht beliebige interne Absenderadressen behaupten können.

Davon getrennt ist die Routingentscheidung des Betriebssystems: Sie bestimmt zunächst, ob ein Ziel überhaupt über die WireGuard-Schnittstelle erreicht werden soll. Das Werkzeug wg verwaltet WireGuard-Eigenschaften, aber nicht automatisch die vollständige IP-Konfiguration des Hosts. wg-quick ergänzt unter anderem Adressen und aus AllowedIPs abgeleitete Routen; Standardrouten behandelt es unter Linux mit Policy Routing. Andere Netzwerkmanager und Plattformen können diese Arbeit anders übernehmen.

Eine korrekte Peerzuordnung ohne passende Hostroute transportiert noch keine Anwendungspakete. Umgekehrt hilft eine Route nicht, wenn WireGuard keinen passenden Peer findet. Und selbst wenn beides stimmt, enthält AllowedIPs keine Regel „nur SSH“ oder „nur dieser Benutzer“. Die Port- und Dienstentscheidung bleibt bei der Firewall und beim Zielsystem. Identität der Gegenstelle, Netzweg und fachliche Berechtigung sind drei eigene Prüfschritte.

Ein Schema für einen gezielten SSH-Zugang.

Alle folgenden Adressen stammen aus Dokumentationsbereichen. Gateway außen: 192.0.2.10; Tunnelgateway innen: 192.0.2.129 und 2001:db8:10::1; Laptop innen: 192.0.2.130 und 2001:db8:10::2. Der interne Linux-Server hat 198.51.100.10 und 2001:db8:20::10. Die Bereiche sind bewusst verschieden. Es sind keine tatsächlich erreichbaren Labor- oder Produktionsziele.

Die Schlüsselwörter in spitzen Klammern sind absichtlich ungültige Platzhalter. Dieses Schema ist nicht startfähig. Es wird nicht auf einem realen Host installiert. Die INI-Struktur erklärt nur, welche Information auf welche Seite gehört. Adressen und private Schlüssel stehen im jeweiligen Interface-Abschnitt; im Peer-Abschnitt steht der öffentliche Schlüssel der Gegenstelle.

Laptop: nur die beiden Serveradressen durch den Tunnel.

[Interface]
Address = 192.0.2.130/32, 2001:db8:10::2/128
PrivateKey = <PRIVATER_SCHLUESSEL_LAPTOP>

[Peer]
PublicKey = <OEFFENTLICHER_SCHLUESSEL_GATEWAY>
Endpoint = 192.0.2.10:51820
AllowedIPs = 198.51.100.10/32, 2001:db8:20::10/128

Gateway: genau dieser Laptop als eigener Peer.

[Interface]
Address = 192.0.2.129/32, 2001:db8:10::1/128
PrivateKey = <PRIVATER_SCHLUESSEL_GATEWAY>
ListenPort = 51820

[Peer]
PublicKey = <OEFFENTLICHER_SCHLUESSEL_LAPTOP>
AllowedIPs = 192.0.2.130/32, 2001:db8:10::2/128

Auf dem Gateway bekommt jeder einzelne Remote-Access-Peer seine eigene IPv4-Hostadresse mit /32 und IPv6-Hostadresse mit /128. Das gesamte Tunnelnetz einem einzelnen Laptop zuzuordnen wäre unnötig weit. Ein weiteres Gerät benötigt ein eigenes Schlüsselpaar und eigene Präfixe. Überlappende oder doppelte Peerzuordnungen können zu unerwarteter Auswahl führen und sind zu vermeiden.

Die asymmetrischen AllowedIPs sind beabsichtigt: Der Laptop sendet zum Server über das Gateway und akzeptiert von diesem Peer innere Antworten mit der Serveradresse. Das Gateway akzeptiert vom Laptop die Laptop-Quelladresse und wählt für Antworten an ihn diesen Peer. Die Tunneladresse des Gateways steht hier nicht in den AllowedIPs des Laptops, weil das Beispiel keinen Zugriff auf das Gateway selbst vorsieht. Sie ist auch kein automatisch erreichbarer DNS-Dienst.

ListenPort legt den UDP-Port des Gateways fest. Endpoint beim Laptop bezeichnet dessen äußeres Ziel. Auf dem Gateway ist für den mobilen Laptop kein fester Endpoint eingetragen; eine authentifizierte Kontaktaufnahme kann dessen aktuelle äußere Adresse bekannt machen. Ein Name statt einer Endpoint-IP würde zusätzlich funktionierende Namensauflösung vor dem Tunnelaufbau voraussetzen.

Für den vollständigen SSH-Weg fehlen im Schema absichtlich die betrieblichen Voraussetzungen: Das Gateway muss den äußeren UDP-Eingang zulassen und für beide verwendeten IP-Familien weiterleiten können. Seine Firewall erlaubt vom VPN-Peer gezielt TCP 22 zu den beiden Serveradressen sowie zugehörigen Antwortverkehr. Der Server braucht einen Rückweg zu den Laptopadressen über das Gateway und eine passende Host-Firewall. Weiterleitung allein ist keine Freigabe. Ein Routeintrag allein aktiviert keine Weiterleitung.

Im Papiermodell benutzt das Servernetz das VPN-Gateway als zuständigen Rückrouter oder besitzt entsprechende spezifische Rückrouten. Fehlt dieser Weg, kann der Handshake funktionieren, während SSH scheitert. Eine Adressübersetzung wäre eine eigene Architekturvariante mit Folgen für sichtbare Quellen und Logs; sie wird hier nicht als Ersatz für saubere Rückwege eingefügt. Die SSH-Hostprüfung und Benutzeranmeldung bleiben auch bei vollständig funktionierendem Tunnel erforderlich.

Split Tunnel und Full Tunnel sind Routingentscheidungen.

Beim Split Tunnel laufen nur ausgewählte Ziele über das VPN. Unser Beispiel enthält genau einen Server in beiden IP-Familien. Allgemeiner Webverkehr nimmt weiterhin den bisherigen Internetzugang. Der Zugriff auf ein ganzes internes Netz würde zusätzliche passende Präfixe verlangen, sollte aber nur bei tatsächlichem Bedarf freigegeben werden. Bei überlappenden Netzen am aktuellen Aufenthaltsort können lokale Routen die beabsichtigte Auswahl verändern.

Ein Full Tunnel soll den allgemeinen Internetverkehr über das entfernte Gateway führen. Als Peerzuordnung auf dem Laptop wären dafür 0.0.0.0/0 und ::/0 relevant. Nur IPv4 umzuleiten und IPv6 direkt hinauszulassen ist kein vollständiger Dual-Stack-Tunnel. Diese breiten Clientpräfixe gehören nicht pauschal in jeden Laptop-Peer auf dem Gateway: Dort bleibt die Zuordnung des einzelnen Laptops eng.

Zusätzlich braucht ein Full Tunnel funktionierende Standard- beziehungsweise Policy-Routen, Gateway-Weiterleitung, Internet-Rückwege und die passende Firewall für beide Familien. Auch das äußere UDP zum Endpoint muss weiterhin über das wirkliche Transportnetz hinauskommen und darf nicht rekursiv im eigenen Tunnel landen. Die konkrete Umsetzung übernimmt beispielsweise wg-quick mit besonderer Standardroutenbehandlung. Die Präfixe allein lösen diese Aufgaben nicht auf jeder Plattform.

„Full“ bedeutet außerdem keine garantierte Ausfallsperre: Wenn der Tunnel verschwindet, können wieder normale Routen greifen. Ein gewünschtes Verhalten „ohne VPN kein allgemeiner Netzzugriff“ benötigt eine separat geplante, getestete Policy einschließlich DNS und notwendiger lokaler Verbindungen. Hier wird dafür kein kopierbarer Kill-Switch angeboten. Eine unbedachte Sperre könnte den einzigen Verwaltungszugang unterbrechen.

Bei Site-to-Site liegen die Endpunkte auf den Gateways.

Standort A erreicht ein benötigtes Netz hinter Standort B, ohne dass jedes Endgerät einen Tunnel betreibt. Die Peerpräfixe enthalten dann die tatsächlich über die jeweilige Gegenstelle erreichbaren Zielnetze. Auf der empfangenden Seite autorisieren sie zugleich deren innere Quellen. Ein Standortpräfix gehört deshalb nur dem dafür zuständigen Gateway-Peer, nicht zusätzlich beliebigen Remote-Laptops.

Die Endgeräte oder ihre Standardrouter benötigen passende Wege zum entfernten Standort. Beide Gateways brauchen Weiterleitung und Dienstregeln; beide Netze brauchen Rückwege. Überschneiden sich die Adressbereiche, fehlt eine eindeutige Zielzuordnung. Ein VPN beseitigt diese Planungsfrage nicht. VLAN-Trennung an beiden Standorten ersetzt ebenfalls keine Regel dafür, welche Systeme durch den Tunnel miteinander kommunizieren dürfen.

DNS und MTU erklären viele scheinbar rätselhafte Fehler.

Eine erreichbare Server-IP garantiert keine Auflösung seines internen Namens. Der Client benötigt den vorgesehenen Resolver, einen Weg zu ihm und eine zulässige DNS-Verbindung. Das DNS-Feld von wg-quick ist eine Zusatzfunktion des Werkzeugs, kein Feld des WireGuard-Protokolls. Die dokumentierte Linux-Variante integriert dafür resolvconf; andere Plattformen haben eigene Mechanismen. Unser Schema enthält keinen DNS-Eintrag, weil nur der SSH-Zugriff per IP erklärt wird.

Bei Split DNS sollen bestimmte interne Namensräume über interne Resolver aufgelöst werden. Ein globaler Wechsel des Resolvers kann dagegen alle Abfragen betreffen oder interne Namen an ungeeignete Stellen senden. Bei Full Tunnel ist zu prüfen, wohin das Betriebssystem und gegebenenfalls der Browser ihre DNS-Abfragen tatsächlich schicken. Ein per HTTPS angesprochener Browserresolver wird nicht automatisch durch die Auswahl eines klassischen Systemresolvers ersetzt. Mehr dazu im DNS-Artikel.

Die MTU begrenzt die Größe eines IP-Pakets auf einer Schnittstelle. Durch die Tunnelverpackung entsteht zusätzlicher Platzbedarf. Eine zu große innere MTU kann dazu führen, dass der Handshake und kleine Abfragen funktionieren, größere Übertragungen aber scheitern. Der sinnvolle Wert hängt vom äußeren Pfad und dessen IP-Familie ab; eine überall angeblich richtige Zahl ist keine Diagnose. wg-quick kann einen Wert ableiten, ein Betreiber muss Problemfälle trotzdem nachvollziehen.

Notwendige ICMP- beziehungsweise ICMPv6-Fehler dürfen dabei nicht verschwinden. Insbesondere IPv6 Packet Too Big unterstützt die Pfad-MTU-Ermittlung. Geprüft wird schrittweise: äußerer Endpoint und UDP, authentifizierter Handshake, innere Route und Peerzuordnung, Forwarding und Firewall, Rückweg, dann Dienst und DNS. Ein frischer Handshake belegt die kryptografische Gegenstelle, nicht das gesamte Nutzdatennetz.

Ein VPN verschiebt Vertrauen und braucht einen Entzugsplan.

HTTPS schützt eine Verbindung zwischen TLS-Endpunkten, häufig Browser und Webserver. Ein VPN schützt auf einer anderen Ebene IP-Verkehr zwischen seinen Tunnelendpunkten. Beides kann gleichzeitig sinnvoll sein: Der VPN-Betreiber oder das Netz hinter dem Gateway soll ebenfalls keine unverschlüsselten Anwendungspasswörter sehen. Der Tunnel macht einen kompromittierten Laptop weder sauber noch automatisch vertrauenswürdig.

Ein kommerzielles VPN macht Nutzer nicht automatisch anonym. Das lokale WLAN sieht typischerweise den Tunnel zum Anbieter; der Anbieter beziehungsweise dessen Ausgang wird zum zusätzlichen Vertrauenspunkt. Webseiten können Nutzer weiterhin über Konten, Cookies oder andere Merkmale erkennen. Bei Split Tunnel verlassen manche Verbindungen den Rechner direkt. Auch beim Full Tunnel bleiben Metadaten und Anwendungsidentitäten relevant.

Geht ein Gerät verloren oder wird sein privater Schlüssel offengelegt, muss die alte Peeridentität auf allen betroffenen Gegenstellen entfernt beziehungsweise ersetzt werden. WireGuard-Schlüssel besitzen hier kein automatisch geprüftes Zertifikatsablaufdatum und keine zentrale Widerrufsliste. Der Betreiber braucht deshalb Geräteinventar, sichere Verteilung neuer öffentlicher Schlüssel und einen überprüften Entzug. Dateien mit privaten Schlüsseln gehören nur für berechtigte Konten lesbar gespeichert, unter Linux beispielsweise mit Modus 600; sie gehören nicht in Repository, Screenshot oder Supportprotokoll. Backups dieser Dateien brauchen denselben Schutz.

Ein geplanter Wechsel wird über einen unabhängigen Verwaltungsweg vorbereitet und nachgeprüft. Nur den neuen Schlüssel auf dem Laptop einzutragen genügt nicht: Die Gegenstelle muss ihn der richtigen Identität und den richtigen Präfixen zuordnen. Bei einem tatsächlichen Vorfall werden zusätzlich Sitzungen, Serverzugriffe und mögliche weitere Zugangsdaten bewertet. Schlüsselwechsel ist eine konkrete Betriebsaufgabe, keine pauschale Garantie, dass vorher nichts passiert ist.

Zwei Tunnelprobleme begründen.

Aufgabe 1: Im gezeigten Papierlabor funktioniert der Handshake. Der Laptop besitzt aber nur für die IPv4-Serveradresse eine Hostroute zur WireGuard-Schnittstelle. Reicht die korrekte IPv6-Adresse in AllowedIPs aus, damit auch IPv6-SSH denselben Weg benutzt?

Aufgabe 2: Ein Betreiber nennt seine Konfiguration Full Tunnel, setzt am Laptop aber nur 0.0.0.0/0. Der Browser erreicht öffentliche IPv6-Ziele direkt. Als Reparatur möchte er auf dem Gateway bei jedem Laptop-Peer ebenfalls beide Standardpräfixe eintragen. Ist das richtig?

Quellen und fachlicher Stand.

Fachlich geprüft am 23.10.2026. Bezugsstand: offizielle WireGuard-Dokumentation und wireguard-tools; neuestes im offiziellen Tagverzeichnis gefundenes Release v1.0.20260223. Kernelmodule, Clients und Distributionspakete können andere Versionsstände haben. Die gezeigten Schemata enthalten ungültige Schlüsselplatzhalter und wurden nicht auf Netzwerkgeräten ausgeführt.

• WireGuard: Conceptual Overview und Cryptokey Routing: Peerzuordnung, Quellprüfung und IP-Transport über UDP.
• WireGuard: Protocol & Cryptography: Handshake, Schlüsselableitung und Datentransport.
• Offizielle wg(8)-Manpage: Schlüssel, Endpoint, AllowedIPs und Keepalive.
• Offizielle wg-quick(8)-Manpage: Adressen, Routen, DNS, MTU und Standardroutenbehandlung unter Linux.
• WireGuard: Routing & Network Namespaces: Trennung von innerem Routing und äußerem Transport sowie Full-Tunnel-Architektur.
• WireGuard: Quick Start: Schlüsselaufbewahrung und situationsabhängiger Keepalive.
• Offizielles wireguard-tools-Tagverzeichnis: geprüfter Werkzeugstand.