Beiträge von mbo77

  • Mal wieder: Kein IPv6 bei Deutsche Glasfaser

    Zitat von ::1

    Das würde ich trotz allem berechtigten Ärger über DG doch besser unterlassen, insbesondere dann, wenn DG dein Glasfaser-Monopolist ist. Vorschlag: Bestell dir den DG-Fritzbox-Mietrouter für eine minimale Laufzeit - dann ist DG in der Pflicht, dir IPv6 bereitzustellen (und kann sich nicht mit der Begründung "kundeneigener Router" herausreden) - und du hast dann m.E. einen deutlich wirkungsvolleren Hebel, im Falle der Nichterfüllung den Monatsbeitrag zu senken.

    Zum einen hat DG mittlerweile noch mindestens Vodafone auf dem Netz. Ist eine Prüfung wert. Die werden wohl L2BSA machen.

    Zum anderen liegt die Leitung und wenn es einen guten Fallback auf VDSL oder HFC gibt, sehe ich für die meisten Menschen kein Problem damit.

    Abstimmung mit den Füßen hilft oft erstaunlich gut. Dauert halt länger.

  • Endgerätewahlfreiheit - aktueller Bericht

    Zitat von arcade99

    Mir war damals die Wandmontage wichtig, die bei der 4060 nicht möglich ist und bei der 5590 super klappt. Würde die 5590 heute kaputt gehen und ich müsste etwas neues kaufen, dann wäre die Wandmontage für mich wichtig, so dass die 5690 Pro in jedem Fall aus dem Rennen wäre. Die fehlende Zukunftsfähigkeit würde das nur noch unterstützen. Da wäre mir eine ONT Variante zusammen mit einer GB im klassischen Design wichtiger.

    Und so hat jeder seine berechtigen Präferenzen. Die sich sogar ändern können, wenig überraschend.

    Daher ist es doch toll, dass der Endkunde die Wahlfreiheit hat. ONT vom ISP oder eine integrierte Lösung von AVM. Oder eine ganz andere Lösung auf Basis von Ubiquiti, OpenWrt etc.

  • Telekom liefert 2 GB/s in Pilotstädten Berlin und Gunzenhausen

    Zitat von millen

    Die Deutsche Giganetz schaltet z.B. den 2,5Gbit Tarif auch bei GPON, die setzen XGS-PON nicht vorraus.

    Ich bin ja sonst ein Fan davon, die Ressourcen ordentlich zu nutzen. Aber das halte ich doch für sehr gewagt.

    Selbst wenn sie es steuern können sollten, mit welchen anderen Anschlüssen der Port betrieben wird (z.B. nur ein Teilnehmer mit 2,5G im Split), ist das weit über die Kante genäht. Rein praktisch sind das auch nicht volle 2,5 Gbps, sondern nur 2,48 Gbps.

    Da sie aber nur 90% garantieren müssen ...

  • Hilfe bei 6tunnel auf VPS benötigt

    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.

  • Hilfe bei 6tunnel auf VPS benötigt

    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.

  • IPv4-Erreichbarkeit via Portfreigabe auf einem VPS

    Interessante Option. Beim Reverse Proxy sollte der paranoide Nutzer natürlich wissen, dass die Verbindung beim Provider terminiert und dort frisch zum Ziel aufgebaut wird.

    Vielleicht kannst du mal ein Erfahrungstutorial schreiben mit den Usecases, die du nutzt oder dich interessieren? Das würde ich dann als Option in den Metabeitrag aufnehmen. Dann aber bitte als Standalone-Beitrag.