Hilfe bei 6tunnel auf VPS benötigt

  • So sieht es aus, wenn Wireguard beim Routing mitmischt:

    Code
     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


    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?

  • AllowedIPs hat zwei Funktionen:

    - Erstellen des Routings

    - Ob ein Paket auf dem Interface überhaupt angefasst wird

    Schau dir die erstellten Routen an.

    Sowas wie 0.0.0.0/0 triggert anderen Konfigurationen.

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

  • 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. :S 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?

    2 Mal editiert, zuletzt von jbb (28. Januar 2025 um 20:01)

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

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

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Ich habe mir das mal angeschaut und nachgestellt. Ich denke, ich habe eine Lösung gefunden.

    Wenn der gesamte Traffic 0.0.0.0/0 über wg geroutet werden soll, baut es folgende Konstruktion auf:

    Code
    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
    
    ip route show table 51820
    default dev wg0 scope link

    Damit soll ausgehender Traffic über das Device wg0 geroutet werden. Die Details der Regel verstehe ich noch nicht, aber das muss ich jetzt noch nicht.

    Stattdessen müssen wir dem IP-Stack beibringen, dass diese Regel nicht für alle gilt, diese Idee hatte frank_m im vorherigen Post.

    Statt aber die Applikation die Pakete markieren zu lassen, behandeln wir Pakete mit bestimmten Ports anders. Im Paket ist mein Ziel (z.B. der Port 23456 für OpenVPN) auf dem System die Quelle, daher muss eine Regel für diesen Source-Port (sport) gesetzt werden:

    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

    Der Verbindungsaufbau extern sollte nun funktionieren. In meinem Beispiel ist das ein per socat getunnelter Aufbau zu meinem IPv6-Ziel im Heimnetz:

    Code
    telnet vps.meinefabelhaftedomain.de <freizugebenderport>
    Connected to vps.meinefabelhaftedomain.de

    Alles andere wird wie gewünscht über das Heimnetz geroutet (sollte für die verbundenen wg-Clients ebenso gelten):

    Code
    traceroute -4 www.heise.de
    traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets
     1  10.99.99.2 (10.99.99.2)  9.983 ms  10.345 ms  10.308 ms

    Den Rest des traceroutes spare ich uns, aber die 10.99.99.2 ist der wg-Endpunkt im Heimnetz.

  • Dazu aber noch folgende Ergänzung.

    Dies behandelt natürlich nur IPv4-Traffic. Ein mobiler Client wie z.B. ein Handy wird aber in der Regel auch eine IPv6-Verbindung haben.

    Dieser Traffic wird nicht über Wireguard und dem Heimrouter getunnelt.

    Wir können die Komplexität steigern und auch noch eine IPv6-Konfiguration über Wireguard realisieren. Aber das vielleicht mal zu einer anderen Zeit.

  • 32765: not from all fwmark 0xca6c lookup 51820

    Die Regel besagt, dass aller Datenverkehr, der mit 0xca6c markiert ist, NICHT in Tabelle 51820 behandelt werden soll. Das "not" vorn bezieht sich auf die ganze restliche Regel, das macht es schwierig zu lesen.

    Wireguard markiert seinen Traffic mit 0xca6c. Genau dieser Traffic wird von der Regel ausgeschlossen. Das heißt, aller Traffic ohne diese Markierung wird von der Regel bearbeitet. Die Regel sorgt also dafür, dass aller Traffic über Wireguard geleitet wird - außer der Wireguard Traffic.

    Deshalb die Idee, den 6tunnel Traffic zu markieren, damit der ebenfalls nicht durch die Regel geht. Natürlich ist eine Filterung auf Basis des Ports auch möglich.

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