Hilfe bei 6tunnel auf VPS benötigt

mbo77

Morgen schaue ich noch mal im Detail.

Aber schau dir die Szenarien noch mal an.

Du kannst eingehend via IPv4 (VPS) auf eine IPv6 (öffentlich) umsetzen. Da das Ziel nicht über das wg Interface geroutet wird, ist wg nicht beteiligt

mbo77

Zitat von jbb

Kein Output bei Kontaktversuch von außen

-v vergessen.

jbb

Code

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.

mbo77

Was mir einfällt und was du als erstes prüfen solltest.

Die meisten Distributionen sind mittlerweile auf nftables gewechselt.

Nutzt du Ubuntu und ist ufw aktiv?

Code

systemctl status ufw.service

jbb

Debian 12

Code

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

mbo77

Was sagt denn da hier?

Code

sudo nft list ruleset

Bzw. auch das hier?

Code

systemctl status firewalld.service

jbb

Code

sudo nft list ruleset
sudo: nft: command not found
root@e307a73b-2c19-4f0d-8c73-xxx:~# systemctl status firewalld.service
Unit firewalld.service could not be found.

mbo77

Zitat von jbb

Code

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.

Ein erfolgreicher Kontakt sollte so aussehen:

Code

6tunnel -d -v 80 a.b.c.d 80
resolving a.b.c.d
resolved to 2003:xxx
resolving local address default
resolved to 0.0.0.0
local: default,80; remote: a.b.c.d,80; source: default
<4> connection from 91.x.y.z,60383
<4> connected to a.b.c.d,80

Dass das bei dir nicht passiert, dass es folgende Fehler geben könnte:

1) Externer Kontakt kann den Namen des VPS nicht korrekt auflösen
2) Firewall beim Hoster arbeitet nicht korrekt für den gewünschten TCP-Port
3) Firewall auf dem OS verhindert den Aufbau

Aus Spaß an der Freude kannst du auch einen Versuch mit "socat" unternehmen:

Code

sudo socat TCP4-LISTEN:80,reuseaddr,fork TCP6:a.b.c.d:80

mbo77

Noch ein Hinweis. Wenn du mit 6tunnel oder socat auf ein "natives" IPv6-Ziel gehst, nutzt du keinen Wireguard-Tunnel.

Du kommst per IPv4 am VPS an und 6tunnel verbindet sich per IPv6 zu deinem Zielsystem.

Bitte daher, falls nicht geschehen, die Tests ohne Wireguard fortführen.

jbb

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

Code

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.

frank_m

Aber wir haben doch oben im tcpdump eindeutig Verbindungsanfragen von extern auf IPv4 gesehen.

Code

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

Warum sollte das jetzt nicht mehr klappen?

mbo77

Deswegen mein Gedanke, dass die Firewall den Traffic blockiert. Dann käme das Paket an, wird aber im Kernel verworfen. Und die Applikation bekommt nix mit.

mbo77

Ich habe das in Ubuntu nachgestellt. Wenn die Firewall ein Paket mittels DENY blockt, sieht es im tcpdump exakt so aus, wie bei jbb.

Der Client sendet immer wieder Anfragen, aber keine Antwort der Applikation, da 6tunnel das Paket nicht bekommt.

Was noch zu prüfen ist:

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.

frank_m

Zitat von mbo77

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

Ja, genau. Da stimme ich zu. Die Policy ist Accept, und eine blockierende Regel gibt es nicht. Das sollte funktionieren ...

jbb

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.

Code

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

Soll ich hier noch etwas anderes prüfen?

mbo77

Mir bleibt es aktuell rätselhaft, wodurch die Kommunikation mit der Applikation blockiert wird.

Code

sudo apt install nftables
sudo nft list ruleset

Eigentlich müsste man die Regeln, falls vorhanden, auch mittels

Code

sudo iptables -L -v

sehen.

Hast du mit

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.

jbb

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.

Code: wg0.conf

[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

Alles anzeigen

AllowedIPs = 10.99.99.2/32,192.168.1.0/24

Ergibt dies

Code

 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

Code

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

Alles anzeigen

frank_m

Ich bin noch nicht vollends überzeugt, aber das Ergebnis des Tests wird interessant. Die Frage ist, ob die finale IPv4-Antwort vom 6tunnel an den Client durch die Default-Route beeinflusst wird, oder ob das Tracking der vorhandenen Verbindung dafür sorgt, dass das Antwort-Paket auf jeden Fall über die Internetverbindung direkt rausgeht.

mbo77

Zitat von jbb

[#] 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

Hier legt wg eine neue Routing-Tabelle an und schickt Pakete über die entsprechende Tabelle. Weshalb das den Verbindungsaufbau unterbindet, erschließt sich mir momentan auch noch nicht. Da müsste ich das vielleicht mal nachstellen.

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.

jbb

Das kann ich noch nachliefern

Code

 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
        }
}

Alles anzeigen