WireGuard funktioniert auf macOS, aber nicht unter Windows

_tnt_ schrieb:
Hatte die Einrichtung mit diesem Video gemacht:
Ok... da bin ich raus. Das ist mir alles zu merkwürdig.

Edit: @_tnt_ aber vom Prinzip sollte es egal sein. Wenn die Config komplett ist, also mit privatem Key, dann sollte diese Config überall laufen, nur nicht gleichzeitig, wenn noch ein anderer Peer diese schon nutzt.
 
Zuletzt bearbeitet:
Jedenfalls sieht man auf den ersten Blick, dass die Anleitung eine Katastrophe sein muss, dafür muss man das Video nicht mal ansehen. Wer einen Address Eintrag mit Subnetzmaske /12 erzeugt, also das ganze 172er Netz belegt, der hat das Prinzip von Wireguard und IP Routing jedenfalls nicht verstanden.
 
riversource schrieb:
Wer einen Address Eintrag mit Subnetzmaske /12 erzeugt, also das ganze 172er Netz belegt, der hat das Prinzip von Wireguard und IP Routing jedenfalls nicht verstanden.

Möchtest du mir das kurz erklären?
Ich muss zugeben, ich habe die werte nur so übernommen. Wobei ich heute beim Probieren selbst die Frage gestellt habe, was es mit den Bereichen auf sich hat und ob vielleicht dort sogar der Fehler liegt.
 
Die Address Bereiche von Wireguard sollten sinnvoll gewählt werden und nicht größer, als man sie tatsächlich braucht. Viele Anleitungen setzen die Subnetzmaske hinterm Address Eintrag auf /32, was auf Client Seite mehr als sinnvoll ist, auf dem Server kann man über /24 nachdenken, wobei /32 auch problemlos funktioniert. Denn welche IPs über VPN erreicht werden, entscheidet ja später die Allowed IPs Variable. Mit einem /12 Netz kannst du über 1 Million VPN Clients mit Adressen versorgen, das ist wohl kaum ein Anwendungsfall für dich.

Unabhängig davon werden die Adressen aus der Address Zeile im System gesetzt, d.h. in diesem Fall, eine 172er Adresse mit einer /12 Maske. Das erzeugt auf mindestens 50% aller Windows Rechner einen Routing Konflikt, denn 172er Netze werden von Windows bevorzugt für Hyper-V, WSL usw. benutzt. Sobald man nur ein Feature unter Windows aktiviert, das ein virtuelles Netzwerk braucht, hat man verloren, und davon gibt es viele.

Also: Address Zeilen und Allowed IPs sinnvoll und dem Anwendungsfall angemessen so klein wie möglich konfigurieren, und natürlich in Netzbereichen, die nicht schon anderweitig im System in Benutzung sind. Das reduziert die Wahrscheinlichkeit von IP Konflikten. Wenn aber eine Anleitung veröffentlicht wurde, die derartig grundlegende Fehler enthält, dann kann man sich vorstellen, wie vertrauenswürdig sie generell ist. Wer an einer Stelle so kapitale Böcke schießt, wird es an anderer Stelle wohl auch tun.

Es zeigt ein weiteres Mal die Probleme, die diese "Silbertablett" Anleitungen mit sich bringen. Auf den ersten Blick schön einfach für den unerfahrenen Nutzer geben sie alles vor, was man einstellen muss, man braucht es nur abtippen. Dass das aber in vielen Fällen nicht funktioniert, fällt erst später auf. Eine wirklich gute Anleitung würde hier nichts vorgeben, sondern lediglich den Nutzer darauf aufmerksam machen, einen für seine Anwendung geeigneten Adressbereich auszuwählen. Ja, das stellt den Nutzer vor die Herausforderung, sich mit der Thematik zu befassen und eine sinnvolle Auswahl zu treffen, aber das muss er eh am Ende, da er verstehen muss, was da eigentlich vorgeht.

Und genau das ist jetzt auch dein Job.
 
Zurück
Oben