Beiträge von mbo77

Das waren doch die mit der professionellen Homepage, oder?

Hä?

'Die Produkte seien "durchweg zu vorteilhaften Preisen im Handel verfügbar" gewesen.'

Für wen vorteilhaft?

Ich habe in Erinnerung, dass eine Verbesserung von XG(S)-PON gegenüber GPON die Latenz im System ist. Aber ich weiß aktuell nicht mehr, wo ich das gelesen habe.

Daher dachte ich zunächst, dass du technisch bereits auf XGS-PON migriert wurdest und davon profitierst. Aber offenbar war die Latenz schon ziemlich gut.

Hast du mal verschiedene Server geprüft?

Ah, umso besser: Ist der Tarif bei dir noch per GPON oder schon per XGS-PON realisiert?

Wie war denn die Idle-Latenz bisher? Auch schon so niedrig? Oder ist die auch weiter gesunken im neuen Tarif?

Zitat von millen

Heute morgen auch gewechselt. Download-Ping von 29ms auf 9ms.

Das ist spannend. Welches Endgerät nutzt du? Gf-Modem 2?

Waipu und Magenta TV liefern zudem Fernbedienungen mit Ziffern.

Ab davon sehe ich, dass unsere Senioren durchaus in der Lage sind, damit umzugehen.

Zitat von Elemir

Wenn sie auf der Fernbedienung einfach nur die Nummer des Programm eintippen wollen

Dann tun sie das einfach.

Zitat von Bracew

Keine Ahnung, ich nutze TeamSpeak nicht.

Ich meinte nat20

Also wenn der PC auf dem Port einen Gbit-Link aushandelt, ist der Port am ONT in Ordnung.

Aber wenn du den ONT an der Fritzbox auf einen der drei anderen LAN-Ports steckst, dann zeigt diese nur 100 Mbps an? Und diese Ports sind alle auf 1 Gbit/s in der Fritzbox konfiguriert?

Zitat von Viconia DeVir

Auch bei einer direkten Verbindung PC-ONT komme ich nicht über die 90-95 hinaus.
Also muss wohl tatsächlich irgendwas an dem ONT defekt sein. Obwohl die Verbindung auch hier eine 1Gbit-Verbindung war.

Jetzt verwirrst du mich: Hat der Link am PC nun 1 Gbps angezeigt oder war der dort auch nur 100 Mbps?

Unter Windows sähe das in etwa so aus:

Und wie greifst du auf Team Speak zu?

Einleitung

Die Erreichbarkeit seines Heimnetzes via IPv4 zu ermöglichen, ist für viele keine Neuigkeit und in vielen Variationen gelebte Praxis.

Da es aber immer wahrscheinlicher wird, dass der ISP nur noch eingeschränkte Konnektivität zum IPv4-Teil des Internets anbietet, drängt sich die Frage nach Lösungen auf.

Hier möchte ich einen Lösungsansatz zeigen, wie man einzelne Systeme (Server, NAS oder andere Arten von Appliances) im Heimnetz von außen via IPv6 erreichbar macht.

DynDNS

Da man als Privatperson in der Regel keine feste IP-Adresse bekommt, sondern diese dynamisch durch den ISP zugewiesen werden, besteht auch bei IPv6 die Notwendigkeit, den eigenen Server unter einem klar definierten Namen erreichbar zu machen.

Im Unterschied zu IPv4 ist es bei IPv6 aber so, dass nicht der Router (z.B. die Fritzbox) die einzige öffentliche Adresse hält, sondern jedes Gerät dahinter über eine eigene öffentliche IPv6-Adresse verfügt. Der bisherige Ansatz, dass der Router die öffentliche IP-Adresse bei einem DynDNS-Service registriert und die eingehenden Verbindungen an ein Ziel weiterleitet (via DNAT und PNAT), ist unter IPv6 nicht nötig.

In dem Beispiel nutze ich den Service von deSEC (https://desec.io). Dort kann ich nach Belieben Zonen einrichten und habe den weiteren Vorteil, dass Certbot ein natives Plugin dafür bereitstellt. Das wird gebraucht, um sich automatisiert Let's-Encrypt-Zertifikate ausstellen zu lassen. Das hat aber nur indirekt mit dem Thema zu tun und zeigt die Bandbreite der Möglichkeiten.

Sollte diese Domain zum Beispiel bei Strato gehostet sein, kann man dort die Delegation vornehmen, indem man die DNS-Server von deSEC setzt:

Das geht natürlich auch mit vielen anderen Anbietern.

DynDNS-Client

Jedes System muss sich selbst beim Service registrieren und seine öffentliche Adresse pflegen.

Linux-Systeme bieten dazu mehrere Möglichkeiten, ich gehe auf "ddclient" als Paket unter Ubuntu ein, das auf einem Raspberry Pi 4 läuft. Nennen wir ihn "rpi4".

Damit der Client berechtigt ist, Updates vorzunehmen, wird ein Acccess Token bei deSEC erstellt:

Jetzt wird der Client konfiguriert (Datei ist /etc/ddclient.conf):

protocol=dyndns2
# "use=cmd" and the curl command is one way of doing this; other ways exist
usev6=if, if=eth0
#use=cmd, cmd='curl https://checkipv6.dedyn.io/'
ssl=yes
server=update6.dedyn.io
login=rpi4.meinefabelhaftedomain.de
password='bxt8RkoBN7v4gqv8pF9QtTqFzxWB'
rpi4.meinefabelhaftedomain.de

Man kann die Adresse am Interface auslesen lassen oder eine Erkennung über ein Kommando realisieren. In dem Beispiel wird die Adresse am Interface eth0 ausgelesen.

Nun den Dienst aktivieren und kontrollieren:

systemctl enable ddclient.service
Synchronizing state of ddclient.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable ddclient
Crea
ted symlink /etc/systemd/system/multi-user.target.wants/ddclient.service → /lib/systemd/system/ddclient.service.

systemctl status ddclient.service
● ddclient.service - Update dynamic domain name service entries
     Loaded: loaded (/lib/systemd/system/ddclient.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2024-06-30 11:36:19 CEST; 12min ago
       Docs: man:ddclient(8)
    Process: 741097 ExecStart=/usr/sbin/ddclient -daemon $daemon_interval -syslog -pid /run/ddclient.pid (code=exited, status=0/SUCCESS)
   Main PID: 741184 (ddclient - slee)
      Tasks: 1 (limit: 2033)
     Memory: 14.7M
        CPU: 571ms
     CGroup: /system.slice/ddclient.service
             └─741184 "ddclient - sleeping for 180 seconds"

Jun 30 11:36:19 pi4 systemd[1]: Started Update dynamic domain name service entries.

Im Laufe der Zeit sollte die Adresse beim Service und allen anderen DNS-Servern ein Update erhalten haben:

nslookup rpi4.meinefabelhaftedomain.de ns1.desec.io
Server:         ns1.desec.io
Address:        2607:f740:e633:deec::2#53

Name:   rpi4.meinefabelhaftedomain.de
Address: 2003:a1:b1:c1:d1:e1:f1:1234

nslookup rpi4.meinefabelhaftedomain.de 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   rpi4.meinefabelhaftedomain.de
Address: 2003:a1:b1:c1:d1:e1:f1:1234

Firewall-Konfiguration

Der Router sollte in der Regel das delegierte IPv6-Prefix hinter einer Firewall schützen. Ich lasse die Firewall am System (rpi4 auf Ubuntu) hier außen vor, da es zu viele Variationen gibt.

Damit es nicht immer nur um Fritzboxen geht, hier ein Beispiel, wie eingehender Traffic zu Port 443 auf einem OpenWRT-Router akzeptiert wird:

Das Ziel, der rpi4, wird hier nur mit einem Host-Anteil und einem Prefix-Hinweis angelegt. Bei wechselnden Prefixes kann die OpenWRT-Firewall auch in Zukunft sicher feststellen, welches Ziel gemeint ist, auch wenn das Prefix sich geändert hat.

Ähnlich wird es auf einer Fritzbox gemacht. Wichtig zu verstehen ist, dass dabei weiter DNAT noch PNAT eine Rolle spielen.

Und so würde man "von außen" sehen, dass die Verbindung in Ordnung ist:

nc -v rpi4.meinefabelhaftedomain.de 443
Ncat: Version 7.95 ( https://nmap.org/ncat )
Ncat: Connected to [2003:a1:b1:c1:d1:e1:f1:1234]:443.

Ich habe mal zu dem Zwecke einen Meta-Beitrag erstellt, vielleicht hilft der weiter:

Thema

Meta-Beitrag zur Erreichbarkeit via IPv4/IPv6 in Heimnetzen

Da es immer wieder Fragen gibt, wie man sein Heimnetzwerk weiterhin "von außen" erreichen kann, wenn der Anschluss auf CG-NAT oder DS-Lite umgestellt wurde, sammele ich hier meine (und auch gerne andere Beiträge), die ich dafür mal erstellt habe.

Diese decken unterschiedliche Ansätze und Techniken ab und zielen darauf ab, praxisnahe Beispiele zu beschreiben, die natürlich keinen Anspruch auf Vollständigkeit haben.

• Erreichbarkeit durch ein WireGuard-VPN und VPS
  IPv4-Erreichbarkeit via VPS und VPN

…

mbo77

30. Juni 2024 um 10:58

Da es immer wieder Fragen gibt, wie man sein Heimnetzwerk weiterhin "von außen" erreichen kann, wenn der Anschluss auf CG-NAT oder DS-Lite umgestellt wurde, sammele ich hier meine (und auch gerne andere Beiträge), die ich dafür mal erstellt habe.

Diese decken unterschiedliche Ansätze und Techniken ab und zielen darauf ab, praxisnahe Beispiele zu beschreiben, die natürlich keinen Anspruch auf Vollständigkeit haben.

• Erreichbarkeit durch ein WireGuard-VPN und VPS
  
  Thema

  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…

  

  mbo77

  28. Oktober 2023 um 15:41

• Erreichbarkeit unter einer öffentlichen IPv4-Adresse durch Portweiterleitungen mit verschiedenen Optionen
  
  Thema

  IPv4-Erreichbarkeit via Portfreigabe auf einem VPS

  Einleitung

  Ergänzend zum Beitrag IPv4-Erreichbarkeit via VPS und VPN (WireGuard) möchte ich weitere Möglichkeiten aufzeigen, einzelne Dienste im Heimnetz erreichbar zu machen.
  
  

  Übersichtszeichnung

  Auch hier zunächst eine Übersicht, was erreicht werden soll:
  
  
  
  Auf den ersten Blick hat sich nicht viel getan. Es besteht weiterhin eine WireGuard-Verbindung zwischen einem VPS und dem Heimnetzwerk.
  
  Daher gehe ich hier nicht weiter auf diese Verbindung ein, bitte im anderen Thread nachlesen.
  
  Der…

  

  mbo77

  29. Oktober 2023 um 15:31

• DnyDNS mit IPv6-Systemen
  
  Thema

  Erreichbarkeit des Heimnetzes via IPv6

  Einleitung

  Die Erreichbarkeit seines Heimnetzes via IPv4 zu ermöglichen, ist für viele keine Neuigkeit und in vielen Variationen gelebte Praxis.
  
  Da es aber immer wahrscheinlicher wird, dass der ISP nur noch eingeschränkte Konnektivität zum IPv4-Teil des Internets anbietet, drängt sich die Frage nach Lösungen auf.
  
  Hier möchte ich einen Lösungsansatz zeigen, wie man einzelne Systeme (Server, NAS oder andere Arten von Appliances) im Heimnetz von außen via IPv6 erreichbar macht.
  
  

  DynDNS

  Da man als…

  

  mbo77

  30. Juni 2024 um 12:07

• Kommerzieller (für Privatanwender kostenfreie) Tailscale-Service
  
  Beitrag

  RE: Deutsche Glasfaser - Zugriff von außen

  Hallo nochmals,
  
  ich bin von einem Nutzer per PN aufgefordert worden zu Tailscale ein "...praxisnahes Beispiel beschreiben...".
  
  
  
  Anleitungen um Tailscale gibt es im Internet zu Hauf. Von Tailscale selbst zum Beispiel hier: https://tailscale.com/kb/1017/install
  
  Über die Suchmaschinen findet man weitere, auch deutsche, Anleitungen in Text oder Videoform.
  
  
  
  Es läuft darauf hinaus, sich
  
  a) bei Tailscale zu registrieren,
  
  b) auf einem (Linux, Windows, macOS, Raspberry Pi, Android, Synology, ... oder anders)…

  

  Bracew

  30. Juni 2024 um 17:40

• Mittels PCP an einem DS-Lite-Anschluss eine VPN-Verbindung herstellen
  
  Thema

  Wireguard via IPv4 an DS-Lite-Anschlüssen mittels PCP (providerabhängig)

  TL;DR: PCP ermöglicht trotz DS Lite am Anschluss zu Hause die WireGuard-Verbindung ohne Mehraufwand aus einem entfernten IPv4-only-Netz.
  
  
  
  In manchen Fällen kann eine Abneigung gegenüber DS Lite allein darin begründet sein, dass nicht jedes entfernte Netzwerk (Hotel-WLAN, Mobilfunknetz im Ausland, Netz eines in der Findungsphase befindlichen regionalen Providers) IPv6 beherrscht und somit ein Fernzugriff auf das Heimnetz via IPv6 nicht sichergestellt ist, wenn der eigene Internetanschluss DS…

  

  DLMttH

  10. Oktober 2024 um 11:41

• GRE als Tunnel-Protokoll und IPv4 von einem externen Anbieter wie NOEZ
  
  Thema

  Lösung für DS-Lite/CGNAT - Öffentliche IPv4 Adressen zuhause via GRE Tunnel

  Hier eine coole Lösung für Nutzer von OPNsense mittels GRE Tunnel, so kann man ebenfalls DS Lite oder auch CGNAT umgehen. Anstelle von IPv4 Endpunkten wird dann natürlich IPv6 verwendet. Ich z.B. habe dadurch ein bestimmtes VLAN welches allen Clients dahinter mittels DHCP direkt öffentliche IPv4 Adressen verteilt. Das ganze ohne NAT, als Anbieter für den GRE Tunnel verwende ich NOEZ.
  
  Falls es Fragen oder Probleme gibt, einfach raus damit.
  
  
  
  Schritt 1: GRE-Tunnel einrichten
  
  

  • Navigiere zu

  …

  

  kerneltask

  9. Oktober 2024 um 21:59

Ergänzende Beiträge bitte gerne per PN oder als Antwort hier posten.

Zitat von Crash Override

Aber lassen wir das ganze nun.

Ach so, wenn es dir nun darum geht, das letzte Wort zu haben, weil du nicht über deinen Tellerrand schauen willst, dann ist das hier natürlich überflüssig.

Der Admin darf hier daher gerne einmal feucht durchwischen.

Da es schwer ist, Hardware zu finden, die darauf nicht vorbereitet ist, ist das schon eine sehr begründete Vermutung.

Doch, vermutlich schon. Die Systeme sind modular und für mehrere Varianten ausgelegt.

Womit wir wieder am Anfang wären: Um das in Zukunft anbieten zu können, muss nichts Neues "gebaut" werden.

Ggf. sind es nur Lizenzen und Profile, die man einspielt/aktiviert. Und beim Kunden muss natürlich passende Hardware stehen.

Ja, aber auch die kaufen bei den üblichen Ausstattern ein. Der Markt gibt vor und dann werden auch die kleineren nachziehen. Da bin ich ganz optimistisch.