Beiträge von mbo77

  • Kann Vermieter Ausbau verweigern?

    Interessant. Wenn deine These gültig wäre, gälte sie auch für andere Provider.

    Die Ergebnisse sind recht klar. Die Telekom hat ein hervorragendes Peering, sogar leicht besser als Vodafone. Und zum Teil deutlich besser als so manch neuer oder alter Provider im FTTH-Umfeld.
    Sonst würde man das z.B. in den Laufzeiten erkennen können.

    Und was soll überhaupt "In dem Fall hier" sein?

  • IPv4-Erreichbarkeit via VPS und VPN (WireGuard)

    Variation mit WireGuard auf der FritzBox

    Es ist natürlich auch möglich, dass man diese Verbindung ohne einen Raspberry Pi etabliert. Dafür übernimmt die FritzBox selbst die Rolle des WireGuard-Clients.

    Die Idee ist, dass die FritzBox die Konfiguration importiert, die wir für den Raspberry Pi vorbereitet haben.

    Da wir auf der FritzBox nicht die gleichen Möglichkeiten haben, dass System zu einzustellen, ist eine kleine Anpassung notwendig.

    Code
    [Interface]
PrivateKey = <key_rpi>
Address = 192.168.178.1/24

[Peer]
PublicKey = <key_vps.pub>
Endpoint = <VPSIP>:52823
AllowedIPs = 10.99.99.0/24
PersistentKeepalive = 25

    Die Anpassung besteht darin, dass das WireGuard-Interface seine eigene LAN-Adresse hält. Ansonsten gibt es mit dem Routing zum Heimnetz und zurück ein Problem, was ich ohne weiteren Zugriff nicht eingrenzen kann. Ich vermute ein Problem, dass zum/vom LAN (unvollständig/falsch) genattet wird.

    Die Konfiguration kann man nun Internet->Freigaben->VPN(WireGuard) hinzufügen.

    Im Dialog wählt man "Netzwerke koppeln oder spezielle Verbindungen herstellen" und in der nächsten Maske beantwortet man die Frage "Wurde diese WireGuard®-Verbindung bereits auf der Gegenstelle erstellt?" mit "Ja".

    Man gibt dem Kind einen Namen und wählt die vorbereitete Datei aus. Die erweiterten Einstellungen helfen uns nicht weiter, sodass wir keine davon aktivieren müssen.

    Sollte man aber SMB/CIFS über die Verbindung nutzen wollen, ist die Option "NetBIOS über diese Verbindung zulassen" zu aktivieren.

    Danach sollte alles wie zuvor beschrieben funktionieren:

    Code
    ping -c 2 192.168.178.110
PING 192.168.178.110 (192.168.178.110) 56(84) bytes of data.
64 bytes from 192.168.178.110: icmp_seq=1 ttl=62 time=12.3 ms
64 bytes from 192.168.178.110: icmp_seq=2 ttl=62 time=10.8 ms

nc -v 192.168.178.110 443
Connection to 192.168.178.110 443 port [tcp/https] succeeded!

  • Kann Vermieter Ausbau verweigern?

    Da bin ich aus Erfahrung aber ganz anderer Meinung.

    Und das findet sich ja hier zu Hauf auch in den Erfahrungen der Nutzer.

    Schlechte Latenz ist oft schlechtem Peering geschuldet.

    Und da ist VDSL oft schneller als so mancher neuer FTTH-Anbieter.

    Und dann gibt es da noch Tests wie zum Beispiel durch das Magazin Connect.

    Aber da darf jeder gerne seine eigenen Erfahrungen machen.

  • Kann Vermieter Ausbau verweigern?

    Zitat von DLMttH

    Ich wüsste jetzt auch nicht, warum man sehnsüchtigst auf die Buchbarkeit eines Telekom-Tarifs warten sollte, wenn der Upload-stärkeren Vodafone-Tarife mit besserem Peering und gleichem oder günstigerem Preis von Anfang an verfügbar sind...

    Also darüber ließe sich doch etwas streiten.

    Gerade beim Thema Peering und Latenz..

  • IPv4-Erreichbarkeit via VPS und VPN (WireGuard)

    (Da Beiträge nur 10.000 Zeichen haben dürfen, der Rest hier.)

    Ausblick

    Mit dieser Konfiguration könnt ihr euch via IPv4 zu einem WireGuard-Netz verbinden und das dahinter liegende LAN im Heimnetz erreichen.

    Was in einem weiteren Schritt gemacht werden könnte, ist, den DNS der FritzBox oder einen anderen DNS-Server zu pushen. Damit würde der Client auch Ziele im Heimnetz via Name erreichen.

    Dies ist wie gesagt nur eine von mehreren Möglichkeiten, die Erreichbarkeit an einem eingeschränkten Anschluss zu realisieren.

    Wer Fehler findet oder sonstige Hinweise hat, dann bitte gerne in einem extra Thread. Ich möchte diesen hier so "sauber" wie möglich halten, um interessierte Leser nicht zu verwirren.

    Bei Bedarf editiere ich diesen Beitrag entsprechend.

  • IPv4-Erreichbarkeit via VPS und VPN (WireGuard)

    Einleitung

    Da es immer wieder Thema ist, möchte ich hier die Chance nutzen, Möglichkeiten aufzuzeigen, wie eine Erreichbarkeit via IPv4 erreicht werden kann, wenn man bei einem Provider ist, der einem keinen vollwertigen IPv4-Zugang mehr anbietet, sondern Techniken wie CG-NAT oder DS-Lite nutzt.

    Hintergrund

    Im ersten Beispiel greife ich eine Konfiguration auf, wie sie zuletzt diskutiert wurde. Dabei geht es darum, das Heimnetzwerk mithilfe eines VPS für IPv4-Clients verfügbar zu machen. Die Brücke zwischen den Welten bildet ein Netzwerk auf Basis von WireGuard. Wobei auch andere VPN-Lösungen grundsätzlich sehr ähnlich funktionieren.

    Andere Möglichkeiten werde ich in einem anderen Beitrag aufzeigen. Natürlich ist jeder gerne eingeladen, selbst was beizusteuern. ;)

    Es wäre schön, wenn hier im Thema nicht geantwortet würde, wenn etwas unklar sein sollte oder andere Ideen einfließen sollen. Zwecks Übersichtlichkeit bitte dann einen weiteren Thread aufmachen.

    Übersichtszeichnung

    Ein Bild sagt mehr als tausend Worte, daher erstmal eine Übersicht, was erreicht werden soll.


    Komponenten der Lösung

    Zu sehen ist also ein Heimnetzwerk (LAN) hinter einem Router, oftmals eine FritzBox. Diese hat einen eingeschränkten Zugang zum Internet, ist also nicht öffentlich erreichbar, sondern kann nur selbst Verbindungen zu Zielen aufbauen.

    In diesem Heimnetzwerk kommt zum Beispiel ein Raspberry Pi als Hilfe zum Einsatz. Diese Aufgabe kann auch die FritzBox selbst übernehmen. Diese Abwandlung werde ich zu einem anderen Zeitpunkt ergänzen.

    Darüber hinaus gibt es ein NAS, auf das ich zugreifen will, wenn ich nicht im Heimnetzwerk bin. Das können natürlich noch viele weitere andere Geräte zu Hause sein.

    Um die Erreichbarkeit zu implementieren, reicht ein sehr einfacher Linux-Server im Internet. Da gibt es viele Angebote bei sehr vielen Providern.

    Als Beispiel führe ich Strato mit günstigen Angeboten an: https://www.strato.de/server/linux-vserver/mini-vserver/

    Für diese Aufgabe reicht ein VC1-1, den es für 1€/Monat gibt. Bei den Angeboten darauf achten, dass der Server eine öffentliche IPv4-Adresse erhält. Es gibt auch IPv6-only-Angebote. In diesem Beispiel bietet Strato mittlerweile beides: IPv4/IPv6

    Um die Komponenten untereinander zu koppeln, kommt eine Tunneltechnik zum Einsatz. Hier konkret geht es um WireGuard (https://www.wireguard.com/).

    Der Raspberry Pi dient hier als Router zwischen den Teilnehmern in dem Transportnetz und dem LAN. Der VPS übernimmt die Aufgabe, sowohl den Raspberry Pi als auch externe Clients (zum Beispiel ein Smartphone in einem mobilen Netz) an das Transportnetz zu koppeln, denn dieser ist eingehend für alle Beteiligten erreichbar.

    Die Kommunikation in das Heimnetz kann dann auf die Adressen im LAN erfolgen. Das fabelhafte NAS, was man unterwegs erreichen möchte, ist für den mobilen WireGuard-Client also wie gewohnt unter 192.168.178.110 erreichbar. Natürlich kann die Konfiguration auch mit dem lokalen DNS der FritzBox oder jedem anderen DNS im LAN funktionieren, sodass man sich keine IP-Adressen merken muss.

    Konfiguration

    VPS

    Der Dreh- und Angelpunkt ist der VPS, zu dem sich alle verbinden. Der Raspberry Pi aus dem Heimnetz und externe Clients.

    Wenn der Provider eine externe Firewall anbietet, gilt es diese eingehend auf UDP auf den festzulegenden Port freizuschalten, in diesem Beispiel ist dies die 52823.

    Um die Erreichbarkeit zu vereinfachen, legen wir bei einem geeigneten Service einen DNS-Eintrag an:

    vps.meinefabelhaftedomain.de mit der öffentliche Adresse, im fiktiven Beispiel 80.90.100.110.

    Benötigt werden zudem die WireGuard-Tools. Das Paket installiert auch die Abhängigkeiten, z.B. via

    Code
    sudo apt install wireguard-tools
cd /etc/wireguard

    Jetzt gilt es, Keys für alle Beteiligten zu erzeugen:

    Code
    wg genkey|tee key_vps|wg pubkey >key_vps.pub
wg genkey|tee key_rpi|wg pubkey >key_rpi.pub
wg genkey|tee key_cl1|wg pubkey >key_cl1.pub

    Die Konfiguration könnte dann so aussehen:

    Hier wird zunächst festgelegt, auf welche IP-Adresse das lokale Interface antworten soll.

    Dann werden zwei Peers berechtigt: Der Raspberry Pi und exemplarisch ein Client. Die Keys entsprechend einsetzen.

    Der Punkt "AllowedIPs" legt fest, für welche IPs welcher Peer verantwortlich ist. Hier ist es ausreichend, den Host-Anteil selbst "/32" zu definieren. Der Peer am Raspberry Pi übernimmt noch zusätzlich das Heimnetz.

    Da ich selbst kein Fan davon bin, die iptables-Regeln via WireGuard zu steuern, nutze ich den Mechanismus, der sich um alle Regeln kümmert.

    Wir legen einmalig die Regeln an und speichern diese:

    Code
    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

    Der letzte Schritt ist nur notwendig, falls ihr verneint habt, die aktuellen Regeln zu speichern.

    Damit verhindern wir jeden FORWARD, außer von wg0 zu wg0, und das wollen wir ja.

    Damit der IP-Stack überhaupt Pakete weiterleitet, muss dies aktiviert werden:

    Code
    sudo echo "net.ipv4.ip_forward=1" >/etc/sysctl.d/50-forwarding.conf

    Im letzten Schritt sorgen wir für den Autostart der Interfaces:

    Code
    sudo systemctl enable wg-quick@wg0

    Dann ruhig mal neustarten, damit sowohl Regeln als auch Interface funktionieren.

    Hier sind wir fertig.

    Raspberry Pi

    Weiter geht es auf dem Raspberry Pi, der sich zum VPS verbinden soll.

    Die Voraussetzungen sind identisch, ich zeige direkt die Konfiguration des WireGuard-Interfaces:

    Code
    [Interface]
Address = 10.99.99.2/24
PrivateKey = <key_rpi>

[Peer]
PublicKey = <key_vps.pub>
Endpoint = vps.meinefabelhaftedomain.de:52823
AllowedIPs = 10.99.99.0/24
PersistentKeepalive = 25

    Wir können uns sparen, einen ListenPort zu setzen, der wird automatisch gewürfelt. Da wir hierhin nicht verbinden, benötigen wir das aber nicht.

    "AllowedIPs" wird pauschal auf 10.99.99.0/24 gesetzt, sodass der VPS aber auch die Kommunikation zu den Clients möglich wird.

    Die Regeln für iptables sehen etwas anders aus:

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

    Hier geht es darum, dass von und nach wg0 Pakete weitergeleitet werden dürfen. Damit sind Ziele im Heimnetz erreichbar.

    Im letzten Schritt sorgen wir für den Autostart der Interfaces:

    Code
    sudo systemctl enable wg-quick@wg0

    Auch der Raspberry Pi muss Pakete weiterleiten können:

    Code
    sudo echo "net.ipv4.ip_forward=1" >/etc/sysctl.d/50-forwarding.conf

    Dann ruhig mal neustarten, damit sowohl Regeln als auch Interface funktionieren.

    Danach sollte wir sehen, dass die Kommunikation zum VPS bereits funktioniert:

    Sieht soweit gut aus.

    Client 1

    Nun geht es an einen Client. Das hängt jetzt stark vom Betriebssystem ab, der Android-Client kann eine Config importieren. Das wird vermutlich sonst auch so sein.

    Hier ist die Konfiguration recht einfach:

    Code
    [Interface]
PrivateKey = <key_cl1>
Address = 10.99.99.3/24

[Peer]
PublicKey = <key_vps.pub>
AllowedIPs = 10.99.99.0/24,192.168.178.0/24
Endpoint = vps.meinefabelhaftedomain.de:52823
PersistentKeepalive = 25

    Router/FritzBox

    Damit auch andere Systeme im Heimnetz, z.B. das fabelhafte NAS, seinen Weg zurück zum Client findet, muss der Router darüber Bescheid wissen.

    Wenn jetzt alles korrekt ist, sollte der Client alles korrekt pingen können:

  • DGN: muss ONT an die Wand verschraubt werden

    Der Fibertwist ist genau der eine Sonderfall, der das ONT integrieren kann.

    Die üblichen Nokias und das ONT der Telekom werden alle mit Patchkabel angebunden.

    In Spanien habe ich in mindestens 5 Wohnungen auch nix anderes gesehen. Und da mussten die Patchkabel augenscheinlich schon einiges mitmachen.

    Du malst hier Gespenster an die Wand.

    belegdol

    Du kannst das ONT bedenkenlos in den Schrank packen. Wenn du doch das Patchkabel kaputt machen solltest, kaufst du für ein paar Taler ein neues.

  • Kann Vermieter Ausbau verweigern?

    TKG-Novelle: Was ändert sich jetzt für Vermieter und Verwalter?
    Die Telekom treibt ihren Glasfaserausbau voran und davon profitieren auch Telekom-Kunden mit klassischem Koax-Kabelanschluss.
    wohnungswirtschaft.telekom.de

    Hier noch ein interessanter Hinweis.

    Es geht um das Telekommunikationsmodernisierungsgesetz von 2021.

    Demnach darf der Vermieter/Verwalter das nicht mehr verbieten.

    Da bin ich jetzt aber zu sehr Laie. Das sagen unisono mindestens o2 und auch die Telekom so.

  • [gelöst]DS218 von außen erreichbar

    Zwei Ergänzungen:

    1) Die Policy der FORWARD-Chain muss auf DROP stehen, sonst ist die Regel zwar nett, aber ohne besondere Wirkung.

    Code
    Chain FORWARD (policy DROP 38 packets, 3192 bytes)

    2) Das ist zwar schon fast das Haar in der Suppe, aber wenn man so wenig Rechte wie notwendig vergeben möchte, kann man bei der FORWARD-Regel den Output auf dasselbe Interface beschränken.

    Code
    iptables -A FORWARD -i wg0 -o wg0 -j ACCEPT

    Damit kann die Regel nur Pakete vom Wireguard-Interface zum Wireguard-Interface weiterleiten.

    Und mehr muss der VPS auch nicht können.

  • Abschaltung Kupfernetz

    Eigentlich sagt er ja nur, dass man Linecards zurückbaut.

    Wenn der Bedarf sinkt, baut man natürlich Ressourcen zurück.

    Spannend wird es, wenn auch der letzte Kunde vom Kupfer runter soll.

    Da braucht es andere Strategien.