WireGuard AllowedIPs: ein Feld mit zwei Aufgaben (und warum Ihres falsch ist)

Nahezu jedes WireGuard-Konfigurationsproblem, das einen erfolgreichen Handshake überlebt, hängt an einem einzigen Feld und daran, dass es fast niemand richtig liest. AllowedIPs sieht aus wie eine Routing-Anweisung. Das ist es, und zugleich ist es etwas anderes.

Was das Handbuch tatsächlich sagt

Die wg-Manpage definiert es in einem Satz, den man langsam lesen sollte:

a comma-separated list of IP (v4 or v6) addresses with CIDR masks from which incoming traffic for this peer is allowed and to which outgoing traffic for this peer is directed

Zwei Teilsätze, zwei verschiedene Aufgaben. Ausgehend: Pakete, deren Ziel in dieser Liste liegt, werden an diesen Peer gesendet. Das ist die Routing-Hälfte, die jeder kennt. Eingehend: Pakete von diesem Peer werden nur angenommen, wenn ihre Quelladresse in derselben Liste liegt. Das ist eine Zugriffskontrollliste, und das ist die Hälfte, die ignoriert wird.

Genau das nennt WireGuard Cryptokey Routing: die Zuordnung von öffentlichem Schlüssel zu Adressbereich ist das gesamte Autorisierungsmodell. Es gibt keine getrennte Firewallregel, die entscheidet, welcher Peer welche Adresse beanspruchen darf.

Die Folge, mit der niemand rechnet

Setzen Sie AllowedIPs = 0.0.0.0/0 bei einem Peer, dann haben Sie nicht nur allen Verkehr dorthin geroutet. Sie haben zugleich erklärt, dass dieser Peer Ihnen ein Paket mit beliebiger Quelladresse aus dem Internet schicken darf, und Ihre Schnittstelle nimmt es an.

Auf einem Client, dessen einziger Peer Ihr eigener Server ist, ist genau das gewollt und die normale Full-Tunnel-Konfiguration. Auf einem Server mit mehreren Peers, oder auf jeder Maschine, wo ein Peer nicht voll vertrauenswürdig ist, ist es ein unbemerkt geöffnetes Loch.

Schwarz-weiße Nahaufnahme nummerierter Metallbriefkästen, die Zahlen 31 bis 40 handschriftlich auf kleinen Etiketten. Jeder Kasten trägt genau eine Nummer und keine kommt zweimal vor: genau diese Bedingung erzwingt AllowedIPs zwischen den Peers.

Warum zwei Peers nie denselben Bereich haben können

Da die Liste entscheidet, an welchen Peer ein Ziel gesendet wird, kann dieselbe Adresse nicht zwei Peers gleichzeitig gehören: die Zuordnung muss eindeutig sein. Praktisch ist das der Grund, warum serverseitig jeder Client sein eigenes /32 (oder /128 bei IPv6) bekommt statt des ganzen Subnetzes.

Die Asymmetrie überrascht. Auf dem Client beschreibt AllowedIPs, was Sie durch den Tunnel erreichen wollen, oft alles. Auf dem Server beschreibt es, wer dieser konkrete Peer sein darf, meist eine einzige Adresse. Dasselbe Feld bedeutet von zwei Enden gelesen zwei verschiedene Dinge.

Das Problem mit dem lokalen Netz, und warum Subtraktion nicht existiert

Die häufigste echte Frage lautet: wie route ich alles außer meinem lokalen Netz. Eine Subtraktionssyntax gibt es nicht. 0.0.0.0/0 minus 192.168.1.0/24 lässt sich nicht ausdrücken, weil das Feld eine Liste von Bereichen ist und sonst nichts.

Die Antwort ist, das Komplement aufzuzählen: statt eines Sammelbereichs listen Sie die CIDR-Blöcke, die zusammen den gesamten Adressraum außer dem lokal zu haltenden Bereich abdecken. Das ist unelegant, ergibt eine lange Zeile, und ist der einzig korrekte Weg. Die Sammelbereiche selbst sind eindeutig dokumentiert: 0.0.0.0/0 trifft alle IPv4-Adressen, ::/0 alle IPv6-Adressen.

Das Symptom, das hierher führt

Ein Handshake gelingt, und dann nichts. wg show zeigt einen frischen Handshake, die Peers haben sich offensichtlich gefunden, und es fließt kein Verkehr. Wenn der Handshake funktioniert, sind Schlüssel und Endpunkt per Definition korrekt: das Problem liegt danach, und AllowedIPs ist die erste Stelle zum Nachsehen. Entweder steht das Ziel sendeseitig nicht in der Liste, oder die Quelle wird empfangsseitig nicht akzeptiert.

Kommt der Handshake selbst nie zustande, ist die Diagnose eine ganz andere, und unser Leitfaden zur Handshake-Fehlersuche behandelt sie. Fließen Pakete, bleiben Seiten aber auf halbem Weg hängen, haben Sie eher ein MTU-Problem als eines mit diesem Feld.

Nicht mit PersistentKeepalive verwechseln

Beide werden verwechselt, weil beide im Peer-Abschnitt stehen und beide nach „Verbindung am Leben halten" klingen. Sie haben nichts miteinander zu tun. Das Handbuch beschreibt PersistentKeepalive als Intervall zwischen 1 und 65535 Sekunden, das regelt, wie oft ein authentifiziertes leeres Paket an den Peer geht, damit ein zustandsbehafteter Firewall- oder NAT-Eintrag gültig bleibt. Es ist standardmäßig aus, und das Handbuch ergänzt, die meisten Nutzer werden es nicht brauchen.

AllowedIPs entscheidet, was erlaubt ist. PersistentKeepalive entscheidet, wie oft Sie anklopfen, damit eine NAT-Box Sie nicht vergisst.

Beim ersten Mal richtig machen

Setzen Sie die Peer-Einträge auf dem Server auf eine Adresse pro Client und nicht mehr. Setzen Sie den Client auf die Bereiche, die Sie wirklich erreichen wollen: die Sammelbereiche für einen Full Tunnel, die konkreten Subnetze für einen Split Tunnel. Lesen Sie jede AllowedIPs-Zeile zweimal: einmal als Route, einmal als Gästeliste. Unsere gebrauchsfertigen Konfigurationsvorlagen setzen diese Trennung um.

Das Feld ist klein, es akzeptiert fast alles, was man eintippt, und es scheitert lautlos, wenn es falsch ist. Diese Kombination ist der Grund, warum es mehr Aufmerksamkeit verdient, als es üblicherweise bekommt.

★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200+ Mbps garantiert

Hoste dein VPN auf deinem eigenen VPS → ContaboVoller Root-Zugriff · öffentliche IPv4 · wähle deine Region→

Häufig gestellte Fragen

Wozu dient AllowedIPs in WireGuard?

Es tut zwei Dinge gleichzeitig. Das wg-Handbuch definiert es als die Liste der Adressen, von denen eingehender Verkehr dieses Peers erlaubt ist und zu denen ausgehender Verkehr für diesen Peer geleitet wird. Es ist also zugleich Routingregel für das, was Sie senden, und Zugriffskontrollliste für das, was Sie annehmen. Die meisten Fehler entstehen, weil nur die erste Hälfte gelesen wird.

Warum gelingt mein Handshake, aber es fließt kein Verkehr?

Weil der Handshake nur beweist, dass Schlüssel und Endpunkt stimmen. Was danach mit den Paketen geschieht, entscheidet AllowedIPs. Entweder ist das Ziel sendeseitig nicht gelistet und nichts gelangt in den Tunnel, oder die Quelladresse ist empfangsseitig nicht gelistet und das Paket wird bei Ankunft verworfen.

Können zwei Peers dasselbe AllowedIPs haben?

Nein, und der Grund ist struktureller Natur und keine Ordnungsregel. Da die Liste entscheidet, an welchen Peer ein Ziel gesendet wird, würde eine Adresse, die zwei Peers gehört, die Wahl mehrdeutig machen. Deshalb bekommt serverseitig jeder Client normalerweise sein eigenes /32 statt des ganzen Subnetzes.

Wie schließe ich mein lokales Netz vom Tunnel aus?

Indem Sie das Komplement aufzählen, denn das Feld kennt keine Subtraktion. Statt eines Sammelbereichs listen Sie die CIDR-Blöcke, die zusammen den gesamten Adressraum außer dem lokal zu haltenden Bereich abdecken. Das ergibt eine lange Zeile und ist der einzig korrekte Ausdruck.

Was ist der Unterschied zwischen AllowedIPs und PersistentKeepalive?

Sie lösen unverwandte Probleme. AllowedIPs entscheidet, welcher Verkehr in welche Richtung erlaubt ist. PersistentKeepalive ist ein Intervall zwischen 1 und 65535 Sekunden, das regelt, wie oft ein authentifiziertes leeres Paket gesendet wird, damit ein zustandsbehafteter Firewall- oder NAT-Eintrag gültig bleibt. Es ist standardmäßig aus, und das Handbuch merkt an, die meisten Nutzer brauchen es nicht.