[Problem] FritzBox Wireguard Verbindung aufbauen

[Insti]

Ab der Zeile „sed -i '/net.ipv6.conf.all.forwarding=1/s/^#//g' /etc/sysctl.conf“

https://neutrinobox.de/wireguard.sh

 

[KunterBunter]

es gab schon mal einige Zeichen bzw Zeichenfolgen

In diesem Fall ist es die Zeichenfolge "perl"

iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE 
iptables -A FORWARD -i wg0 -o $(arp -n -H ether | perle -ne 'print $1 if /(\S+\n)$/' | sort | uniq -c | grep -v Iface | sort -n | tail -1 | perle -pe 's/.* //') -m state --state RELATED,ESTABLISHED -j ACCEPT 
iptables -A FORWARD -i $(arp -n -H ether | perle -ne 'print $1 if /(\S+\n)$/' | sort | uniq -c | grep -v Iface | sort -n | tail -1 | perle -pe 's/.* //') -o wg0 -j ACCEPT

 

[ültje]

Danke @Insti für deine Mühe mit dem Code. Das hätte ich mir nicht so schnell "aneignen" können...

Habe die Befehle ausgeführt, noch iptables-persistent installiert. Pi mal neugestartet. Keine Änderung. Verbindung wird mit grüner Lampe als aktiv gekennzeichnet, aber mein Client ist dann offline. Ich glaub ich schmeiß das Handtuch und bleibe bei Tailscale. Ich steig nicht durch, wie auch, das ist ja super komplex ohne jegliche Netzwerk-Vorerfahrung...

 

[Insti]

Am Pi mal mit

curl -6 ifconfig.co

überprüfen ob es die gleiche ip ist wie du als subdomain bei freedns erstellt hast.

 

[ültje]

Ja, ist die gleiche IP. Das ist wohl das einzige was ich hinbekommen habe.

Welche IP würdest du denn vom Client aus anpingen, wenn du die Verbindung testen willst?

 

[frank_m24]

Die Frage ist, warum? Ich dachte, du willst auf die Festplatte zugreifen, und nicht dein ganzes Heimnetz über den VPN Server im Internet surfen lassen. Bedenke, dass dann aller Internetverkehr durch den Upload des anderen Anschlusses muss. Ist das wirklich dein Ziel?

Falls nicht, sollten wir über diese iptables Regeln noch mal sehr genau nachdenken. Dann sind die nämlich nicht das, was du brauchst.

Also: Was konkret ist das Ziel? Oben steht, Haushalt B soll auf die Festplatte zugreifen. Wenn die Festplatte am Pi hängt, braucht man dafür keine iptables Regeln, und wenn die Festplatte im Heimnetz A woanders hängt, braucht man andere Regeln. Da steht nicht, Haushalt B soll über das Internet von Haushalt A surfen, und nur dafür wären die aktuellen Regeln gut. Den Zugriff auf die Festplatte können sie vielleicht sogar verhindern.

 

[Insti]

Welche IP würdest du denn vom Client aus anpingen,

Ich würde versuchen per ssh (putty o.ähnliches) auf die wg ip vom pi zu kommen. Ist doch bei dir die 10.7.0.1 ?

 

[ültje]

@frank_m24 Ich mag, wie strukturiert du denkst

Du hast absolut Recht. Ich möchte NICHT, dass mein Client über das Internet von Haushalt A surft. Ich möchte lediglich auf den entfernten Pi und dessen USB-Festplatte.

Dass ich versuche zu pingen und während der aktiven WG-Verbindung versuche zu surfen, sehe ich vorrangig als Test der Verbindung. Das grüne Licht bringt mich ja so noch nicht weiter.

 

[frank_m24]

Ok, dann lasse die iptables Regeln erst mal komplett weg. Sorge erst mal dafür, dass der VPN Tunnel steht und du aus deinem Heimnetz von Baushalt B die IP des Pis im Transportnetz von Haushalt A pingen kannst.

Und damit sind wir wieder bei #31, letzter Absatz. Das ist dafür erforderlich. Alles, was danach kam, war ein schöner Ausflug in die Welt der Bash-Scripte und Regular Expressions, hilft uns aber keinen Schritt weiter.

 

[H´Sishi]

Wenn ich VPN richtig verstehe, wird bei einer Standard-VPN-Verbindung der komplette Netzwerkverkehr des Clients über den Tunnel geschickt, d.h. "Haushalt B" als Tunnel-Ersteller surft über den Tunnelendpunkt (hier der Pi aus Haushalt A), was aber mangels Routingfähigkeit des Pi scheitert.

Im Client müßte also hinterlegt werden, daß nur der Verkehr zum angesprochene Pi über den Tunnel geht und der sonstige Internetverkehr am VPN-Tunnel vorbeiläuft.

Der Weg wäre dann, zunächst einen VPN-Tunnel zu konfigurieren, der den Pi als Endpunkt und Router nutzen würde.
Im 2. Schritt muß die Konfiguration auf dem Client angepaßt werden, um allen Internetverkehr außer dem zum Pi vom Tunnel fernzuhalten.

Wie genau die Konfiguration geändert werden muß hängt von der jeweiligen VPN-Software ab; ebenso ob dieser Mischbetrieb (Normales Surfen ohne VPN plus Traffic zu einem bestimmten Ziel über den Tunnel) mit der verwendeten VPN-Software überhaupt möglich ist.
Eventuell kann das sogar schon bei der Einrichtung eingestellt werden. Die Funktion müßte sinngemäß "Kompletten Verkehr über den Tunnel leiten" heißen.

 

[Insti]

Standart wird der gesamte Traffic über den Tunnel geschickt wenn in der [Peer] Sektion

 AllowedIPs = 0.0.0.0/0, ::/0

steht. Will man nur eine bestimmte ip oder bestimmtes Netz erreichen, dann auch dort ändern.
Bsp. es soll nur das Heimnetzwerk erreichbar über den Tunnel sein und das Internet über den eingenen ISP

AllowedIPs = 192.168.178.0/24, fd00::/64

 

[ültje]

Moin Leute.

Hier ist jetzt die Konfig des Servers:

[Interface]
Address = 10.7.0.1/24, fddd:2c4:2c4:2c4::1/64
PrivateKey = ...
ListenPort = 51820

# BEGIN_PEER mac
[Peer]
PublicKey = ...
PresharedKey = ...
AllowedIPs = 10.7.0.2/24, fddd:2c4:2c4:2c4::2/64
# END_PEER mac

Und das ist die Konfig des Clients:

[Interface]
PrivateKey = ...
Address = 10.7.0.2/24, fddd:2c4:2c4:2c4::2/64
DNS = 1.1.1.1, 1.0.0.1

[Peer]
PublicKey = ...
PresharedKey = ...
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = freednsdomain:51820
PersistentKeepalive = 25

Müssen jetzt beim Client die IPs vom Server 10.7.0.1/24, fddd:2c4:2c4:2c4::1/64 in die Allowed IPs?

Edit: Und wie mache ich die iptables-Geschichte am einfachsten wieder rückgängig?

Edit: Ich hab grad mal an den Keys meines Clients rumgefummelt und bewusst Stellen vertauscht. Danach kann ich immer noch eine "Verbindung aufbauen", die mit grünem Licht visualisiert wird. Das scheint also nicht viel Wert zu sein... ich glaub ich resette heute nochmal alles und probier es noch ein letztes Mal, basierend auf euren Nachrichten.

 

[Insti]

ich glaub ich resette heute nochmal alles und probier es noch ein letztes Mal,

Kannst das Script aus #41 auf dem Pi ausführen. Das erstellt dir den Wireguard Server und 5 Client Configs. Die Client Configs sind dann unter /opt zu finden. In der config müsstest dann beim Client nur den endpoint mit der freedns ipv6 subdomain ändern.
Wenn das funktioniert kannst du die
AllowedIPs nach wünschen anpassen und die iptables auch löschen

sudo rm /etc/iptables/rules.v4
sudo rm /etc/iptables/rules.v6

-

 

[ültje]

Es funktioniert weiterhin nicht. Ich habe jetzt soviel Zeit darein gesteckt und lass es bleiben. Schluss.

Danke für eure Geduld und Hilfe.

 

[frank_m24]

Kannst das Script aus #41 auf dem Pi ausführen.

Nein, kann er eben nicht. Das hilft ihm überhaupt nicht weiter. Das hatte ich aber auch oben schon geschrieben, dass das Script NICHT hilft. Der Raspi routet nicht, er ist selbst der Server. Der Zugriff erfolgt nur auf die Transport-Netz-IP, die NAT Regeln greifen überhaupt nicht. Grundlagen IP-Routing! Nicht einfach irgendein Script posten, weil es in irgendeiner Anleitung steht, die überhaupt nicht zum Anwendungsfall passt. Jetzt gibt er auf, und das nur, weil er schlecht beraten wurde.

Also: In Haushalt A steht ein Raspi, der ist VPN Server und hat gleichzeitig eine Festplatte. In Haushalt B steht eine Fritzbox, und der gesamte Haushalt soll auf diese Festplatte zugreifen können über das VPN. Das sind die resultierenden Konfigs:
Server (Raspi in Haushalt A):

[Interface]
Address = 10.7.0.1/32
PrivateKey = ...
ListenPort = 51820

# BEGIN_PEER mac
[Peer]
PublicKey = ...
PresharedKey = ...
AllowedIPs = 10.7.0.2/24, <Subnetz der Fritzbox in Haushalt B>
# END_PEER mac

Das Subnetz musst du noch selber eintragen, das kennen wir nicht.

Client (Fritzbox in Haushalt B):

[Interface]
PrivateKey = ...
Address = 10.7.0.2/32

[Peer]
PublicKey = ...
PresharedKey = ...
AllowedIPs = 10.7.0.1/24
Endpoint = freednsdomain:51820
PersistentKeepalive = 25

Nicht mehr und nicht weniger. Keine NAT Regeln, keine DNS Einträge, keine Defaultrouten. Der Raspi ist ab sofort von allen Geräten in Haushalt B erreichbar, über seine IP-Adresse 10.7.0.1. Der Internetzugang für die Geräte in Haushalt B erfolgt nach wie vor über die Fritzbox in Haushalt B, und nicht über den VPN Tunnel und Haushalt A.

Voraussetzungen:

1. Der Raspi hat eine IPv6 Adresse, die bei Freedns eingetragen ist (scheint der Fall zu sein)
2. Die Fritzbox von Haushalt B verfüg ebenfalls über eine IPv6 Adresse (Ist der Fall gemäß der Screenshots oben)
3. Das Subnetz der Fritzbox in Haushalt B ist nicht 10.7.0.0/24. Sonst finden die Clients den Raspi nicht.
4. Das Subnetz der Fritzbox in Haushalt A ist nicht 10.7.0.0/24. Sonst findet der Raspi das Netz in Haushalt B nicht.
5. Die Subnetze in Haushalt A und B sind nicht identisch. Sonst gibts Routing Kuddel Muddel.

 

[Insti]

Nein, kann er eben nicht.

Aha, du weißt was der User kann und was nicht?

Anleitung steht, die überhaupt nicht zum Anwendungsfall passt. Jetzt gibt er auf, und das nur, weil er schlecht beraten wurde.

Das Script passt zu 100%, weil es nämlich alles installiert was für den WG Server nötig ist. Wenn alles fertig ist kann das Netzwerk natürlich begrenzt werden und auch das wurde geschrieben.
Du kannst doch garnicht wissen ob alles am Pi schon installiert ist was zum WG benötigt wird oder?

@ültje
Hab es nur gut gemeint, da über 1200 User schon dieses Script erfolgreich installiert haben und so über Wireguard Standorte miteinander verbunden haben.
Wünsche dir noch viel Erfolg.
VG Insti

 

[frank_m24]

Aha, du weißt was der User kann und was nicht?

Ja. Aber du weißt leider nicht, was die von dir empfohlenen Scripte können. Das ist im Moment unser Problem. Dabei hätte einfach ein wenig Grundlagenwissen schon gereicht. Ich empfehle den Dieter Nuhr in solchen Situationen.

Das Script passt zu 100%, weil es nämlich alles installiert was für den WG Server nötig ist.

Zum einen tut es das nicht, zum anderen richtet es stattdessen irgenwelchen Unsinn ein, den kein Mensch braucht. Das ist das Problem mit diesen Scripten: sie funktionieren nur genau für den Anwendungsfall, für den sie gedacht sind. Will man nur eine Kleinigkeit anders machen, ist man anschließend länger damit beschäftigt, hinter dem Script aufzuräumen, als wenn man es direkt selbst gemacht hätte.

Hier wurde dem Anwender auch wieder sugerriert, dass es ein Rundum-Sorglos-Paket ist. Tja, ist es nicht. Am Ende muss man sich doch damit befassen, und es selber machen. Wäre das von Anfang an konsequent befolgt worden, würde das Setup längst laufen. Stattdessen schmeißt der Anwender nun seine Daten einer amerikanischen Datenkrake in den Rachen. Und das ist das eigentliche Drama.