Hilfe bei 6tunnel auf VPS benötigt

    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

    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.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    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
  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    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.
    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

    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.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    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.

    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?

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    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.

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

    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?

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    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.

    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.


    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

    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.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    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.

    Das kann ich noch nachliefern