AllowedIPs ist eine Routingliste, keine Firewall-Regel

Das Feld wählt einen Peer für ausgehenden Verkehr und prüft eingehende Quellen. Es ist keine Zugriffsliste, und das Abschalten der Routenverwaltung behebt keinen Split-Tunnel.

Die meisten lesen AllowedIPs als Berechtigungsliste, also als die Adressen, die sich mit einem Peer verbinden dürfen, ähnlich einer für einen Tunnel geschriebenen Firewall-Regel. Das ist es nicht. Das Feld ist eine Routing-Tabelle, die in beide Richtungen arbeitet: Es wählt einen Peer für ein ausgehendes Paket und prüft die Quelle eines eingehenden. Wer es als Zugriffsliste liest, erzeugt Konfigurationen, die Verkehr routen, den niemand angefordert hat.

Ein Feld, zwei Leser: Ausgangswahl und Quellenprüfung

Beim Client entscheiden die Präfixe, welche Ziele zu diesem Peer reisen und welche im gewöhnlichen Netz bleiben. Ein Eintrag für 0.0.0.0/0 erfasst daher jedes IPv4-Ziel, und deshalb schickt der Import eines Volltunnel-Profils gewöhnliches Browsen über die entfernte Maschine. Enge Einträge tun das Gegenteil: Sie routen nur die von Ihnen gelisteten Netze und lassen alles andere, wo es war. Der Abschnitt zum Kryptoschlüssel-Routing in der WireGuard-Dokumentation nennt beide Aufgaben an einer Stelle: die Wahl des ausgehenden Peers und die Prüfung der eingehenden Quelle.

Auf dem Server beschreibt dasselbe Feld, welche Quelladressen jeder Peer verwenden darf. Das ist eine kryptografische Prüfung und kein Paketfilter: Ein Paket, dessen innere Quelle nicht zur Liste des Peers passt, wird innerhalb von WireGuard verworfen, bevor irgendeine Firewall des Hosts es sieht. Beide Aufgaben teilen sich eine Liste, und genau deshalb verhält sich eine anderswoher kopierte Liste an einer Stelle falsch, die Sie nicht bedacht haben.

Der Client-Block ist der Ort, an dem der meiste Teil dieser Verwirrung beginnt. Ein Split-Tunnel nennt die entfernten Netze, und ein Volltunnel ist dasselbe Feld mit einem Standardpräfix:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Beide Formen sind für sich vollständig, und sie sind Alternativen statt Schritte. Die erste schickt nur diese beiden Netze durch den Tunnel; die zweite schickt jedes Ziel, wobei der Eintrag ::/0 IPv6 zum IPv4-Standard hinzufügt. Welche Sie auch wählen, diese Präfixe sind die gesamte Routingentscheidung für diesen Peer, sobald wg-quick beginnt, Routen zu installieren.

Der Hub braucht eine andere Liste

Ein Hub führt die Tunneladresse jedes Clients als Host-Präfix auf, dazu jedes Netz, das wirklich hinter diesem Client liegt. Eine breite Liste eines Clients auf jeden Hub-Peer zu kopieren sagt dem Hub, dass viele Peers dieselben Adressen als Quelle nutzen dürfen, und das ist kein Adressplan. Das Feld Endpoint gehört einer ganz anderen Schicht an: Es nennt die äußere Adresse und den Port des Peers, nie ein Ziel innerhalb des Tunnels.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

Das Host-Präfix trägt die Tunneladresse, und das Netzpräfix trägt das, was hinter dem Client liegt, und beide werden gebraucht. Ohne das Host-Präfix kann der Hub den eigenen Verkehr des Clients nicht zurückgeben, und ohne das Netzpräfix bleibt das dahinterliegende LAN unerreichbar; ein Peer ohne etwas dahinter erhält nur das Host-Präfix.

Wer die Routeninstallation überspringt, lässt eine Lücke

wg-quick, der Helfer, der eine Schnittstelle aus einer Konfigurationsdatei aufbringt, installiert Schnittstellenadressen und Routen als Teil dieser Aufgabe. Table = off zu setzen sagt dem Helfer, die Routenarbeit zu überspringen, was keine Ersatzrouten installiert und das private Netz nicht erreichbar macht. Wenn automatische Routen die Aufgabe bereits erledigen, ist es die klarere Konfiguration, die benötigten Präfixe zu nennen. Die Routenverwaltung abzuschalten und den Ersatz ungeschrieben zu lassen ist kein Entwurf, sondern eine Auslassung.

Das Basiswerkzeug wg verhält sich anders: Es konfiguriert die Schnittstelle und berührt nie Routen, daher braucht ein direkt darauf aufgebautes Setup eigene Routenbefehle. Anleitungen, die für ein Werkzeug geschrieben wurden, können falsch wirken, wenn man sie gegen das andere befolgt. Ein erfolgreicher Ping ist ebenfalls ein schwacher Beleg, denn er prüft einen Pfad statt jedes Anwendungspfads, den Sie brauchen.

DNS und IPv6 werden getrennt entschieden

Prüfen Sie die DNS-Serveradresse, die der Tunnel bekannt gibt, und bestätigen Sie, dass über die gewählten Präfixe eine Route zu dieser Adresse existiert. Eine Resolver-Einstellung macht den Resolver nicht erreichbar, und das Verengen eines Tunnels kann die Route still entfernen, die dorthin führte. Untersuchen Sie IPv6 auch für sich, denn eine korrekte IPv4-Aufteilung sagt nichts über eine IPv6-Standardroute, die noch auf die physische Verbindung zeigt. Drei getrennte Entscheidungen können sich auf einmal ändern, wenn Sie einen Peer-Block bearbeiten.

Öffnen Sie dann eine private Ressource und eine gewöhnliche Website aus einer bekannten Ausgangskonfiguration. Antwortet die Ressource und verlässt das Browsen weiterhin die lokale Verbindung, tut die Aufteilung, was Sie verlangt haben. Bricht das Browsen im selben Moment, hat der Tunnel die Standardroute übernommen, und die Präfixliste ist der Ort, an dem Sie nachsehen sollten.

Ähnliche Artikel