[Problem] FritzBox Wireguard Verbindung aufbauen

es gab schon mal einige Zeichen bzw Zeichenfolgen
In diesem Fall ist es die Zeichenfolge "perl"
Code:
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
 
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...
 
Am Pi mal mit
Code:
curl -6 ifconfig.co
überprüfen ob es die gleiche ip ist wie du als subdomain bei freedns erstellt hast.
 
  • Like
Reaktionen: ü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?
 
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.
 
@frank_m24 Ich mag, wie strukturiert du denkst :D

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.
 
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.
 
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.
 
Standart wird der gesamte Traffic über den Tunnel geschickt wenn in der [Peer] Sektion
Code:
 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
Code:
AllowedIPs = 192.168.178.0/24, fd00::/64
 

Anhänge

  • IMG_6879.jpeg
    IMG_6879.jpeg
    754 KB · Aufrufe: 9
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.
 
Zuletzt bearbeitet:
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
Code:
sudo rm /etc/iptables/rules.v4
sudo rm /etc/iptables/rules.v6


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

Danke für eure Geduld und Hilfe.
 
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. :mad:

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):
Code:
[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):
Code:
[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.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.