Beiträge von jbb

Zitat von mbo77

Code

ip rule add sport <freizugebenderport> lookup main

ip rule show
0:      from all lookup local
32763:  from all sport <freizugebenderport> lookup main
32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main
32767:  from all lookup default

Super, jetzt funktioniert es!

Vielen Dank für euere Geduld und Expertise. Habe viel gelernt! Und ja, die Sache mit dem IPv6 Traffic heben wir für ein anderes Mal auf.

Zitat von mbo77

Was immer gehen sollte: Clients per IPv6 zur FB verbinden und nur die Ausnahmen inbound auf IPv4 über den VPS abwickeln.

Die Tage schaue ich mir das Verhalten genauer an, vielleicht ergibt sich dann der Ursprung des Problems.

So lange AllowedIPs nicht 0.0.0.0./0 enthält, funktioniert 6tunnel, dafür wird nicht der gesamte Traffic über den Wireguard Tunnel geleitet (in mein Heimnetz komme ich problemlos).

Trotz vieler Versuche komme ich einfach nicht weiter.

Zitat von mbo77

Es wäre schon ganz gut gewesen, wenn du diese entscheidende Änderung gleich zu Beginn benannt hättest.

Da hast du völlig recht! Ich habe mich erst wieder daran erinnert, als ich WG abwechselnd an und abgeschaltet habe. Sorry für die unnötige Arbeit!

Das Einfügen 0.0.0.0/0 hat offensichtlich die problematischen Routings getriggert. Obwohl ich nicht verstehe, warum davon überhaupt der nicht-Wireguard-Traffic berührt wird.

Gibt es denn evtl eine elegantere Möglichkeit, das Ziel zu erreichen, nämlich den gesamten Verkehr der WG-Clients über das Heimnetz zu routen?

So sieht es aus, wenn Wireguard beim Routing mitmischt:

 sudo ip rule show
0:      from all lookup local
32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main
32767:  from all lookup default

Zitat von mbo77

Du kannst das im Übrigen auch selbst steuern und im Server mit "Table = off" verhindern, dass Routing-Tabellen angefasst werden. Die notwendigen Routen musst dann selbst setzen.

Aber dann muss ich ja Routen manuell erstellen für die einzelnen Wireguard Clients, oder?

Das kann ich noch nachliefern

 sudo nft list ruleset
table ip filter {
        chain INPUT {
                type filter hook input priority filter; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority filter; policy drop;
                iifname "wg0" oifname "wg0" counter packets 27578 bytes 14472878 accept
        }

        chain OUTPUT {
                type filter hook output priority filter; policy accept;
        }
}
table ip raw {
        chain PREROUTING {
                type filter hook prerouting priority raw; policy accept;
        }
}
table ip mangle {
        chain POSTROUTING {
                type filter hook postrouting priority mangle; policy accept;
        }

        chain PREROUTING {
                type filter hook prerouting priority mangle; policy accept;
        }
}
table ip wg-quick-wg0 {
        chain preraw {
                type filter hook prerouting priority raw; policy accept;
                iifname != "wg0" ip daddr 10.99.99.1 fib saddr type != local drop
        }

        chain premangle {
                type filter hook prerouting priority mangle; policy accept;
                meta l4proto udp meta mark set ct mark
        }

        chain postmangle {
                type filter hook postrouting priority mangle; policy accept;
                meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark
        }
}

Zitat von mbo77

Code

wg-quick down <config>

mal zur Laufzeit den Tunnel gestoppt?

Aber mehr fällt mir gerade nicht ein.

Danach könntest du einen Versuch mit einem aktuellen Ubuntu-Image starten.
Für den Test IPv4->6tunnel->IPv6 kannst du dir das Wireguard-Setup sparen.

Das war der entscheidende Hinweis, ich glaube ich weiß wo mein Fehler liegt.

Mit zur Laufzeit gestopptem Wireguard hat 6tunnel problemlos funkioniert. Daraufhin habe ich mich nochmal mit meiner wg0.conf befasst und mir ist aufgefallen, was ich damals bei der Einrichtung geändert habe: Ich wollte den gesamten Traffic der Clients über das VPN routen und habe ein 0.0.0.0/0 bei AllowedIPs hinzugefügt.

[Interface]
PrivateKey = <geheim>
Address = 10.99.99.1/24
ListenPort = 123
MTU = 1420

# Fritzbox
[Peer]
PublicKey = <geheim>
AllowedIPs = 10.99.99.2/32,192.168.1.0/24,0.0.0.0/0
PersistentKeepalive = 25

[Peer]
PublicKey = <geheim>
AllowedIPs = 10.99.99.3/32
PersistentKeepalive = 25


[Peer]
PublicKey = <geheim>
AllowedIPs = 10.99.99.4/32
PersistentKeepalive = 25

AllowedIPs = 10.99.99.2/32,192.168.1.0/24

Ergibt dies

 wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.99.99.1/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 192.168.1.0/24 dev wg0
root@e307a73b-2c19-4f0d-8c73-xxx:/etc/wireguard# wg-quick down wg0
[#] ip link delete dev wg0

AllowedIPs = 10.99.99.2/32,192.168.1.0/24,0.0.0.0/0

Führt hierzu

root@e307a73b-2c19-4f0d-8c73-xxx:/etc/wireguard# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.99.99.1/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 192.168.1.0/24 dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n

Zitat von mbo77

Code

sudo apt install ufw
sudo ufw status

Man müsste dann aber etwas in iptables sehen. Es bleibt unklar, warum das Paket die Applikation nicht erreicht.

 sudo apt install ufw
sudo ufw status
Reading package lists... Done
....
Status: inactive

Soll ich hier noch etwas anderes prüfen?

Den Wireguard-Tunnel zur Fritzbox habe ich gekappt, reicht das?

sudo socat TCP4-LISTEN:4430,reuseaddr,fork TCP6:2a00:6020:5022:c700:9209:xxxxx:49681

Auch mit socat klappt es nicht, bzw. nur dann, wenn ich die Verbindung vom VPS aus initiiere.

Habe es nochmals mit anderen Einstellungen bzw. anderem Port bei Hoster-Firewall versucht, ohne Erfolg. Wireguard und SSH kommen da ja auch problemlos durch (mit Custom-Ports, s.o.).

Falls wir jetzt überhaupt nicht mehr weiterkommen, werde testweise einen neuen VPS aufsetzen und nochmals von null anfangen, vielleicht lässt sich das Problem so eingrenzen.

Debian 12

systemctl status ufw.service
Unit ufw.service could not be found.

sudo 6tunnel -d -v 4430 nas6.xxxxx.de 49681
resolving nas6.xxxxx.de
resolved to 2a00:6020:5022:c700:xxxxx
resolving local address default
resolved to 0.0.0.0
local: default,4430; remote: nas6.xxxxx.de,49681; source: default

Nur das, keine Änderung beim Kontaktversuch von außen.

Zitat von mbo77

Morgen schaue ich noch mal im Detail.

Vielen Dank erstmal für deine Mühe. Lass uns morgen nochmal schauen.

 sudo 6tunnel -d 4430 nas6.xxx.de 49681

Kein Output bei Kontaktversuch von außen

Zitat von mbo77

Nur zum Verständnis: Wenn du 6tunnel auf ein IPv6-Ziel richtest, ist der gesamte Wireguard-Tunnel ohne Funktion.

Sollte das so sein? Mein Wireguard-Setup terminiert in der Fritzbox und funktioniert noch. Ich komme mit meinem Smartphone (nicht im WLAN) weiterhin via WG über den VPS in mein eigenes Netz. Und seltsamerweise funktioniert dann auch die Tunnelung: Hinter Port 49681 lauscht ein Webserver auf dem NAS, diesen erreiche ich vom Smartphone aus unter https://vps.xxxxx.de:4430

Ich bin verwirrt.

Zitat von mbo77

Und was kannst du beobachten, wenn du beim Verbindungsaufbau von außen netstat mitlaufen lässt?

Code

watch "sudo netstat -anp|grep 6tunnel"

Wenn ich von außen komme, gibt es keinen Kontakt. Vom VPS aus und wie ich gerade herausgefunden habe, wenn ich per Wireguard verbunden bin, funktioniert es problemlos und ich kann den Verbindungsaufbau beobachten.

Kann das doch ein Problem der externen Firewall bei Strato sein?

Zitat von mbo77

Hast du mal versucht, 6tunnel zum IPv4-Ziel im Heimnetz zu schicken?

Code

sudo 6tunnel 4430 192.168.1.4 49681

Identisch zu oben. Die Verbindung vom VPS zum NAS steht, alles von außen funktioniert nicht.

Also auf dem VPS scheint es zu funktionieren

 sudo 6tunnel  -v 4430 nas6.xxxxxx.de 49681
resolving nas6.xxxxxx.de
resolved to 2a00:6020:5022:c700:9209:xxxxxx
resolving local address default
resolved to 0.0.0.0
local: default,4430; remote: nas6.xxxxxx.de,49681; source: default
<4> connection from 217.160.xxx.xxx,35458
<4> connected to nas6.xxxxxx.de,49681
<4> connection closed
child process exited

Das ganze im zweiten Terminalfenster auf dem VPS

 nc -v -4 vps.xxxxxx.de 4430
Connection to vps.xxxxxx.de (217.160.xxx.xxx) 4430 port [tcp/*] succeeded!

Direkte Verbindung vom VPS auf da NAS per IPv6 funktioniert auch

nc -v ds6.xxxxxx.de 49681
Connection to ds6.xxxxxx.de (2a00:6020:5022:c700:9209:xxxxxx) 49681 port [tcp/*] succeeded!

 sudo tcpdump -v -i ens6 port 4430
tcpdump: listening on ens6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:35:13.106151 IP (tos 0x0, ttl 117, id 63923, offset 0, flags [DF], proto TCP (6), length 52)
    94.31.xxx.xxx.1727 > e307a73b-2c19-4f0d-8c73-xxxxxx.4430: Flags [S], cksum 0x5519 (correct), seq 4146232851, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
20:35:14.113649 IP (tos 0x0, ttl 117, id 63924, offset 0, flags [DF], proto TCP (6), length 52)
    94.31.xxx.xxx.1727 > e307a73b-2c19-4f0d-8c73-xxxxxx.4430: Flags [S], cksum 0x5519 (correct), seq 4146232851, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
20:35:16.114224 IP (tos 0x0, ttl 117, id 63925, offset 0, flags [DF], proto TCP (6), length 52)
    94.31.xxx.xxx.1727 > e307a73b-2c19-4f0d-8c73-xxxxxx.4430: Flags [S], cksum 0x5519 (correct), seq 4146232851, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
20:35:20.117807 IP (tos 0x0, ttl 117, id 63926, offset 0, flags [DF], proto TCP (6), length 52)
    94.31.xxx.xxx.1727 > e307a73b-2c19-4f0d-8c73-xxxxxx.4430: Flags [S], cksum 0x5519 (correct), seq 4146232851, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

Das ist die Reaktion auf ein ncat -v -4 vps.xxx.de 4430

Zitat von frank_m

Nein, im Gegenteil. Es reagiert nur auf IPv4 Traffic. Den leitet es per IPv6 weiter zum Ziel.

Äh, ja klar. So dachte ich das auch, hab dann irgendwie was anderes geschrieben...

Der IPv6 Traffic wird also direkt abgelehnt (siehe oben), IPv4 verschwindet in den Untiefen?

Zitat von frank_m

Hier sieht man keine IP, wie beim IPv6 Versuch. Funktioniert die Namensauflösung? Was passiert, wenn du direkt auf die IP zugreifst?

Namensauflösung funktioniert. Direkter Zugriff auf die IPv4 bringt ebenfalls nur einen timeout.

Ist es nicht so, dass 6tunnel nur auf IPv6 Traffic reagiert?

Hallo in die Runde,

bin seit Jahren hauptsächlich Mitleser, habe jetzt aber eine Frage, die ich nicht durch die Suche beantworten konnte.

Ich nutze seit 2019 einen Anschluss der Deutschen Glasfaser. Seit etlichen Jahren verwende ich mehrere Portmapper von feste-ip.net um auf meine Synology-NAS zuzugreifen. Hierbei wird diese vor allem als OpenVPN-Server benutzt. Dies funktioniert weitesgehend zuverlässig. Da ich auf aus Performance-Gründen auf Wireguard umsteigen wollte, habe ich mir nach der hervorragenden Anleitung von mbo77 einen VPS bei Strato aufgesetzt. Dieser läuft mittlerweile problemlos und ich komme von verschiedenen Clients in mein Netz.

Zusätzlich würde ich gerne noch 6tunnel installieren um z.B. als Backup die OpenVPN-Verbindung zu tunneln oder bestimmte Dienste des NAS direkt zu erreichen (um den Portmapper von feste-ip komplett zu ersetzen). Auch hier bin ich nach der Anleitung vorgegangen, bekomme es aber nicht zum laufen. Sowohl die Variante über das Wireguard-Netz (IPv4), als auch direkt über die IPv6 bzw. denn Domainnamen funktionieren nicht.

• Die öffentliche IP des VPS ist sinnvoll im DNS registriert

  vps.xxxxx.de

• Die WireGuard-Verbindung zwischen VPS und Heimnetz funktioniert

  Ja, siehe oben

• Firewall des Hosters ist konfiguriert und auch verstanden

  

  Ja, der eingehende Port (4430) ist für TCP für IPv4 und IPv6 freigegeben.

• Wenn konfiguriert, muss die Paket-Firewall des VPS eingehende Verbindungen zum weiterzuleitenden Port akzeptieren

  Hier liegt vermutlich das Problem. Ich habe iptables nach der Anleitung konfiguriert

sudo iptables --policy FORWARD DROP
sudo iptables -A FORWARD -i wg0 -o wg0 -j ACCEPT
sudo apt install iptables-persistent
sudo iptables-save >/etc/iptables/rules.v4

Hier habe ich einfach zu wenig Ahnung, muss da eine weitere Freigabe konfiguriert werden?

Was funktioniert:

Das NAS ist per IPv6 aus dem Internet erreichbar: nas6.xxxxx.de, Notwendige Ports z.B. 49681 sind in der Fritzbox freigegeben.

Das NAS ist per IPv4 im internen Netz und vom VPS bei bestehender Wireguard-Verbindung unter 192.168.1.4 erreichbar

nc -v -4 192.168.1.4 49681
Connection to 192.168.1.4 49681 port [tcp/*] succeeded!
nc -v nas6.xxxxx.de 49681
Connection to nas6.xxxxx.de (2a00:6020:5022:c700:xxx) 49681 port [tcp/*] succeeded!

6tunnel ist auf dem VPS installiert.

sudo 6tunnel 4430 nas6.xxxxx.de 49681

netstat -anp|grep 6tunnel
tcp        0      0 0.0.0.0:4430            0.0.0.0:*               LISTEN      594/6tunnel

nc -v vps.xxxxx.de 4430
nc: connect to vps.xxxxx.de (2a01:239:37xxxx) port 4430 (tcp) failed: Connection refused
Connection to vps.xxxxx.de (217.160.xx) 4430 port [tcp/*] succeeded!

Vom VPS aus scheint 6tunnel zu funktionieren.

Aber von außerhalb bekomme ich keine Verbindung zusammen. Habe es z.B. von meinem Windows-Rechner mittels ncat versucht

C:\Windows\System32>ncat -v vps.xxxx.de 4430
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connection to 2a01:239:xxx failed: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte. .
Ncat: Trying next address...
Ncat: TIMEOUT.

C:\Windows\System32>ncat -v -4 vps.xxxxx.de 4430
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: TIMEOUT.

Ich komme hier trotzdem ich viel gelesen und selbst ChatGPT und Gemini um Hilfe gebeten habe, nicht mehr weiter.

Es wäre toll, wenn mir jemand ein paar Tipps geben könnte.

Vielen Dank!

Johannes