Beiträge von alfalfa

    Welchen Stecker die Fritzbox 5530 braucht, steht in den technischen Daten: LC/APC.


    Welcher Stecker in den HÜP gesteckt wird, müsste der Provider eigentlich in einer Schnittstellenbeschreibung veröffentlichen, aber ich habe keine gefunden. Üblich ist an der Stelle LC/APC. Den verwendet die Deutsche Glasfaser, zu der Inexio ja gehört. Wenn der Stecker grün ist, ist es APC (Schrägschliff). Ein (U)PC Stecker (nicht schräg geschliffen) wäre blau. Wenn der Stecker ungefähr so breit wie ein RJ45-Ethernet-Stecker ist, ist es SC. Ein LC-Stecker ist halb so breit.

    Mach nicht die 5530 für mangelnde Prozesse bei den Glasfaseranbietern verantwortlich, fremde Router in ihr Netz zu lassen.

    Die Aktivierung von anderen Endgeräten ist an GPON-Anschlüssen komplizierter als an AON-Anschlüssen. Das geht auch dann manchmal schief, wenn die Hardware vom Provider selbst stammt. Darum ging es am Anfang des Themas, aber das ist ja offensichtlich nicht mehr das Problem. Grundsätzlich läuft der Anschluss nämlich.


    Die Fritzbox 5530 ist allerdings relativ neu auf dem Markt. Da muss man mit Kinderkrankheiten rechnen. Wenn sich die Netzwerkqualität durch einen einfachen Neustart des Routers drastisch verbessert, ist der Router zumindest ein heißer Kandidat bei der Fehlersuche, auch wenn das andere Ursachen nicht ausschließt. Ich würde deswegen nicht gleich zu einem anderen Router und einem externen ONT wechseln wollen, aber wenn die Fehler wieder auftreten, wäre das eine denkbare Möglichkeit, die Zeit zu überbrücken, bis AVM und der Provider die Ursache finden. Aber wenn man Pech hat, ist die Fritzbox nicht die Ursache und die Probleme treten auch mit einem externen ONT auf.

    Bisher habe ich VPNcilla auf dem Android-Smartphone genutzt und habe die MyFritz-Verbindungsdaten genommen.

    VPNcilla kann wohl kein IPv6

    Die kurze Antwort ist, dass es mit der Fritzbox alleine als VPN-Endpunkt im Heimnetz an einem DG-Privatkundenanschluss nicht möglich ist.


    Portmapper setzen IPv4-Verbindungen auf IPv6-Verbindungen um, machen also IPv6-Dienste für IPv4-Clients zugänglich. Die Fritzbox stellt aber keinen VPN-Dienst per IPv6 zur Verfügung. Die Fritzbox beherrscht nur IPSec über IPv4.


    Solange sich AVM nicht dazu durchringt, die VPN-Unterstützung der Fritzboxen zu modernisieren, und die Deutsche Glasfaser ihren Kunden auch gegen Aufpreis keine öffentlichen IPv4-Adressen anbietet, ist also eine andere Lösung nötig. Wenn dem Client IPv6 zur Verfügung steht, was inzwischen in allen Mobilfunknetzen in Deutschland ggf. nach kleinen Einstellungsanpassungen der Fall sein sollte, dann wird kein Dienst zur Umsetzung von IPv4 auf IPv6 benötigt. Es wird lediglich ein VPN-Server im LAN mit einem geeigneten VPN-Protokoll gebraucht. Wireguard ist leicht einzurichten und wird gut unterstützt. Wenn das aber über IPv4 mit einem Portmapper genutzt werden soll, braucht es einen, der UDP unterstützt, was i.d.R. nicht der Fall ist. Für TCP wäre OpenVPN das naheliegende VPN-Protokoll. Mit der Unterscheidung ist das Protokoll gemeint, das das VPN verwendet. Innerhalb des VPN sind natürlich beide Protokolle nutzbar. Wenn es im LAN schon einen dauernd laufenden Server gibt, kann der möglicherweise als VPN-Endpunkt verwendet werden. Ansonsten eignen sich OpenWRT-Router oder auch ein Raspberry Pi gut für diese Aufgabe. Für letztere gibt es vorbereitete Systemimages, mit denen ein VPN-Server für Wireguard oder OpenVPN schnell eingerichtet ist.

    Das verlinkte SFP-Modul und auch das Kit sind nicht für den Anschluss geeignet. Du brauchst ein 1000BASE-BX10-U SFP-Modul und ein passendes Kabel (Simplex Single-Mode mit einem grünen LC/APC Stecker für die Anschlussdose und wahrscheinlich einem blauen LC/PC-Stecker für das SFP-Modul). Das BX steht für bidirektionale Übertragung: Beide Übertragungsrichtungen verwenden ein und dieselbe Faser auf verschiedenen Wellenlängen. Das Modul, das du verlinkt hast, ist ein LX-Modul und benutzt für jede Übertragungsrichtung eine eigene Faser. Für die bidirektionale Übertragung muss das Modul auf der Kundenseite die entgegengesetzten Wellenlängen vom Modul auf der ISP-Seite verwenden. Das kundenseitige Modul kennzeichnet man mit dem U (für Upstream) am Ende der Typbezeichnung. Das ISP-Modul hat da ein D (für Downstream). Die genauen Wellenlängen hat dir dein Provider schon mitgeteilt. Danach kannst du das Modul auch ohne -U oder -D aussuchen. Dieses wäre passend.

    Wie lange könnte diese "Mangelwirtschaft" ;) noch dauern?

    Das ist regional unterschiedlich, aber meiner Einschätzung nach wird IPv4 noch viele Jahre unverzichtbar sein. Durch CGNAT wird das Netz in Server und Clients geteilt (was aber auch aus anderen Gründen stattfindet). Immer mehr Protokolle nutzen HTTP(S) als Unterbau, was mit sehr wenigen Adressen auskommen kann. Den aktuellen Zustand kann man also technisch noch sehr lange beibehalten, ohne dass es letztendlich wirklich zu wenige Adressen gibt, um die Dienste, die die meisten Nutzer benötigen, mit IPv4 zu betreiben. Durch Umverteilung von Clients zu Servern kann man diese Zweiteilung noch weiter treiben und das Ende von IPv4 noch weiter hinausschieben.


    Weil es für Server in Rechenzentren immer noch genug Adressen gibt, ist zu beobachten, dass unzählige Dienste immer noch nur über IPv4 in vollem Umfang erreichbar sind. Es gibt die Seite IPv6.watch, wo auch viele große und bekannte Dienste kein Grün für volle Nutzbarkeit rein über IPv6 bekommen. Zu den Diensten, die nur über IPv4 genutzt werden können, gehören zur Zeit z.B. Amazon, eBay und GitHub. Aber auch die Deutsche Glasfaser hat keine über IPv6 erreichbare Homepage und deren Telefonie funktioniert ebenfalls ausschließlich mit IPv4. Du kannst dir mal den Spaß machen, einen Computer nur für IPv6 zu konfigurieren, und dann ausprobieren, was noch geht. Spoiler: Nicht viel. Google weist für Deutschland zwar über 50% IPv6-Unterstützung aus, aber der Prozentsatz, der ganz ohne IPv4 zurecht käme, ist 0%,


    Auch heute werden noch viele Geräte verkauft, die IPv6 überhaupt nicht unterstützen. Für noch mehr Geräte gilt, dass die IPv6-Unterstützung gefährlich oder unpraktikabel lückenhaft ist. Für einen vollständigen Umstieg auf IPv6 müssten diese Geräte ausrangiert werden. Vorher wird es deshalb wahrscheinlich eine Zeit lang noch IPv4 Inselnetze geben, die über Tunnel miteinander verbunden sind. Ganz ähnlich gab es lange Zeit IPv6 Inselnetze, die über IPv4 Tunnel verbunden waren, bzw. gibt es die noch immer. Solche Tunnel bietet z.B. Hurricane Electric kostenlos an, und der Bedarf dafür ist immer noch da. Es gibt nämlich immer noch ISPs, die IPv6 nicht anbieten, obwohl schon lange nur noch dann neue IPv4-Adressen vergeben wurden, wenn auch IPv6 Zuteilungen aktiv genutzt wurden. Im Mobilfunk hat der letzte Netzbetreiber in Deutschland erst dieses Jahr den Zugang über IPv6 ermöglicht. Man sieht also, dass der Umstieg sehr langsam abläuft.


    Wenn du mit bestimmten Regionen in der Welt in Kontakt bleiben musst, wirst du noch deutlich länger auf IPv4 angewiesen sein. Die IPv6-Verbreitung in Afrika ist z.B. minimal. Auch in einigen europäischen Ländern ist IPv6 noch Neuland. Für vieles ist ausreichend, wenn du über CGNAT IPv4-Server erreichen kannst. Aber wenn du selbst Dienste anbieten willst, ist das natürlich nicht genug.


    Die Zeit der selbstverständlichen technischen Unterstützung von IPv6 hat m.M.n. noch nicht einmal begonnen. IPv6 merkt man an, dass sich niemand darauf verlässt. Vieles ist noch eine Baustelle: von den Standards über die Geräte und Firmware bis zu den Anwendungen.

    Du brauchst keine Zugangsdaten und, wenn dein Anschluss offiziell für einen kundeneigenen Router konfiguriert ist, auch keine speziellen VLANs. Für IPv4 bekommt der Router per DHCPv4 eine Adresse. Für IPv6 wird DHCPv6 verwendet und darüber bekommt der Router je nach Konfiguration eine Adresse und/oder ein /56 Präfix (im Normalfall beides: eine Adresse für den Router und das Präfix für die Geräte im LAN).


    Geschwindigkeitsangaben sind ggf. für QoS nötig (z.B. für Priorisierung von VoIP). Kommt dann darauf an, was für QoS der Router macht.


    Bei der VoIP-Konfiguration ist zu beachten, dass die Telefonie von der DG nur IPv4 verwendet und deshalb von Seiten des IP-Telefons Keep-Alives nötig sind, um die NAT-Assoziation dauerhaft zu halten. Je nach eingesetzten Geräten ist VoIP erheblich einfacher, wenn es der Router macht und kein nachgelagertes Gerät.

    Neuere Anschlüsse können automatisch konfiguriert werden. Die Telekom-Technik hält die Anschlüsse auseinander und kann dem Router die nötigen Anmeldedaten übermitteln. Das nennt sich "EasySupport". Die 7590 kann das, aber die 4040 anscheinend noch nicht. In dem Fall muss man sich von der Telekom die Zugangsdaten für eine manuelle Konfiguration besorgen.

    Der typischer Aufbau eines Telekom-FTTH-Anschlusses beinhaltet nach wie vor einen vom Router getrennten ONT. Der Speedport 3 Smart hat kein eingebautes "Glasfaser-Modem". Ein Wechsel auf einen Router mit Glasfaserschnittstelle ist nicht nötig und ohne ein gewisses Maß an Vorkenntnissen auch nicht ratsam.


    Ein Router mit eingebautem Modem wird nicht benötigt. Eine Fritzbox 4040 kann direkt am ONT eines Telekom-FTTH-Anschlusses betrieben werden.

    HAL2001 befindet sich in einer ungünstigen Situation, weil weder die Arbeitgeber-IT noch die Deutsche Glasfaser erwarten lassen, dass sie zu individuellen Änderungen bereit sind. Dass fehlendes IPv6 ein Unterschied ist, halte ich für denkbar, und das ist ja auch schon an Anschlüssen der DG spontan verschwunden. Das sollte man also nachschauen.


    Ansonsten glaube ich nach der Beschreibung nicht an ein Konfigurationsproblem des Anschlusses. Erstens ist das Problem plötzlich aufgetreten, ohne dass bewusst irgendwas geändert wurde. Zweitens ist der Anschluss schon überprüft und der Router neu konfiguriert worden, und abgesehen vom VPN funktioniert alles. IPSEC gilt aber völlig zu Recht als schwer zu kontrollierende Diva und Unternehmens-IT-Abteilungen sind dann schnell dabei, einfach eine öffentliche IPv4 zu fordern, anstatt die einmal funktionierende Konfiguration anzufassen.

    HubeBube: Unterschiede in der Anschlusskonfiguration sind eine Möglichkeit, aber nicht unbedingt die wahrscheinlichste. Das VPN wird mit dem in Windows integrierten Client aufgebaut (erkennbar an der charakteristischen Fehlermeldung) und ist sehr wahrscheinlich L2TP über IPSEC. Dieser Client ist normalerweise nicht für NAT auf beiden Seiten konfiguriert. Für NAT-Traversal ist eine Änderung in der Registry nötig. IPSEC verwendet ein eigenes Protokoll mit dem Namen ESP. Das ist nicht TCP und nicht UDP. Anders als diese beiden Protokolle hat ESP keine Ports. Ein NAT-Router kann die Pakete also nicht am Tupel (Absenderadresse, Absenderport, Zieladresse, Zielport) unterscheiden sondern bestenfalls am Tupel (Absenderadresse, Zieladresse) und für eine bestimmte Zieladresse höchstens an der Absenderadresse. Es ist also sehr leicht möglich, dass sich verschiedene IPSEC-Nutzer hinter einem NAT-Router in die Quere kommen. Das ist ein durchaus möglicher Unterschied zwischen der Netzumgebung bei den Freunden und zu Hause. Wie schon vorher geklärt funktioniert der Anschuss ansonsten einwandfrei, so dass eine grundlegende Fehlkonfiguration von NT oder Router unwahrscheinlich ist. Der Router wurde auch schon zurückgesetzt und händisch neu konfiguriert.

    Kalle: Die Gegenstelle ist der Windows 10 Laptop, der von der Arbeitgeber-IT verwaltet wird. Der VPN-Router soll nicht die Verbindung zum Arbeitgeber aufbauen, sondern per Tunnel eine öffentliche IPv4-Adresse aus einem entfernten Netz (bei einem Server-Hoster) heranholen, so dass es für den Laptop-Computer so aussieht, als wäre das kein CGNAT-Internetanschluss. Auf diese Weise wird zwar immer noch NAT benutzt, aber nicht mehr geteilt mit anderen DG-Kunden. Wenn man dem Laptop eine öffentliche IPv4-Adresse geben wollte, ginge das damit im Prinzip auch, aber das wird nicht nötig sein, weil es auch an anderen Internetanschlüssen nicht üblich ist.


    Bevor man das eine oder das andere macht, sollte man aber erst herausfinden, woran es liegt.

    Im Internet gibt es so Seiten wie „Zeige mir meine IP“. Ist sowas zu empfehlen ? Wird da die IP richtig angezeigt ? Ist das die IP, die meiner Frau, bei der Nutzung von VPN zum Arbeitgeber, womöglich Probleme macht, oder ist das auch wieder nur ein Dummy?


    Wo kann man denn sonst noch „seine“ öffentliche IP sehen ? Ich habe hier schon gelernt, dass die IP, die die FRITZ!Box anzeigt, auch „nur“ eine interne IP ist und mit unserem Problem nichts zu tun hat.

    Ja, um die Adresse, die dort angezeigt wird, geht es. Das ist die Adresse, die auch der Arbeitgeber an seinem VPN Konzentrator sieht. Diese Adresse wird von mehreren DG-Kunden genutzt, so wie die IP-Adresse der Fritzbox von mehreren Geräten in eurem Netz gemeinsam genutzt wird.


    Eine sehr schön einfache URL, wo man die im Internet sichtbare IPv4 Adresse ohne das übliche Werbedrumherum angezeigt bekommt, ist:

    https://api.ipify.org

    Die Hauptseite mit Erklärungen ist https://www.ipify.org/.


    Aber das hat nur informativen Wert. Ändern kannst du mit der Kenntnis der IP Adresse nichts. Das CGNAT kannst du nicht beeinflussen, nur mit einem eigenen Tunnel umgehen.

    Nein das wird maximal nach den 24 Monaten Vertragslaufzeit funktionieren.

    Ich habe es anders verstanden. sturm hat einen Preisnachlass mit Vertragsverlängerung angeboten bekommen, anstatt ein Downgrade ohne Vertragsverlängerung durchzuführen, das im Rahmen der Wechselgarantie im zwölften Monat möglich gewesen wäre.


    Ich rechne damit, dass man solche Angebote in Zukunft häufiger sehen wird, weil die automatische Verlängerung um ein Jahr vom Gesetz her wegfallen wird. Den Netzbetreibern wird also einiges daran liegen, Kunden auf freiwilliger Basis länger zu binden.

    Komische iPerf3 Versionen habt ihr da. Warum zeigen die die Gesamtzahl der Pakete nicht an? So sieht das bei mir aus:


    [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams

    [ 5] 0.00-1.00 sec 4.31 MBytes 36.2 Mbits/sec 0.381 ms 0/3121 (0%)

    [ 5] 1.00-2.00 sec 4.77 MBytes 40.0 Mbits/sec 0.349 ms 0/3455 (0%)

    [ 5] 2.00-3.00 sec 4.77 MBytes 40.0 Mbits/sec 0.365 ms 0/3453 (0%)

    [ 5] 3.00-4.00 sec 4.77 MBytes 40.0 Mbits/sec 0.368 ms 0/3451 (0%)

    [ 5] 4.00-5.00 sec 4.77 MBytes 40.0 Mbits/sec 0.348 ms 0/3455 (0%)

    [ 5] 5.00-6.00 sec 4.77 MBytes 40.0 Mbits/sec 0.337 ms 0/3454 (0%)

    [ 5] 6.00-7.00 sec 4.76 MBytes 40.0 Mbits/sec 0.385 ms 0/3450 (0%)

    [ 5] 7.00-8.00 sec 4.77 MBytes 40.0 Mbits/sec 0.363 ms 0/3455 (0%)

    [ 5] 8.00-9.00 sec 4.77 MBytes 40.0 Mbits/sec 0.375 ms 0/3452 (0%)

    [ 5] 9.00-10.00 sec 4.77 MBytes 40.0 Mbits/sec 0.384 ms 0/3453 (0%)

    - - - - - - - - - - - - - - - - - - - - - - - - -

    [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams

    [ 5] 0.00-10.00 sec 47.7 MBytes 40.0 Mbits/sec 0.000 ms 0/34199 (0%) sender

    [ 5] 0.00-10.00 sec 47.2 MBytes 39.6 Mbits/sec 0.384 ms 0/34199 (0%) receiver

    Mit einem Paketverlust von 2-3% selbst bei geringer Last müsste der Anschluss nahezu unbrauchbar sein. Du kannst mal versuchen, ob du nachvollziehbare Werte mit iPerf3 messen kannst. Es gibt ein paar wenige öffentliche UDP-Gegenstellen für iPerf3. Mit folgendem Aufruf testest du die Downstream-Richtung mit UDP und einer Bandbreite von 40Mbit/s. Das scheint die ungefähre Zieldatenrate des Streams zu sein. Wenn möglich, dann mach die Messung mit einem Linux-System, das per Kabel am Router angeschlossen ist.


    iperf3 -c ping.online.net -p 5208 -R -u -b 40M


    iPerf3 gibt dir nach 10 Sekunden eine Zusammenfassung mit der übertragenen Datenmenge, Jitter und verlorenen Paketen. Ich bekomme da 0% Packet Loss und 0,5ms Jitter an einem DG-Anschluss.

    Ich würde wirklich erst nach dem Registry Key schauen, denn sonst stochert man im Dunkeln.


    Natürlich kann man versuchen, eine möglichst "Telekom"-ähnliche Netzsituation herzustellen, also Dualstack ohne CGNAT, aber soweit mir bekannt ist, ist das mit der DG nicht so einfach. Wenn dir tatsächlich eine öffentliche IPv4-Adresse angeboten worden ist, dann hat sich vielleicht etwas geändert und dann sollte man diesen Weg gehen. Wenn es sich aber nur um das Angebot des Kooperationspartners EDV Kossmann handelt, dann nützt das nichts. Da ist NAT in einer Art und Weise im Spiel, mit der das VPN nicht funktionieren wird. Die DG müsste die IPv4 Adresse schon direkt auf dem Anschluss zur Verfügung stellen. In den Business-Tarifen ist das der Fall, aber die kosteten ab 250€/Monat, bevor die Preise mit der Umstellung zu Privat-DG und Business-Inexio von der Webseite verschwunden sind.


    Wenn ich das für mich an allen Beteiligten vorbei lösen müsste, würde ich das mit einem gemieteten (virtuellen) Server und einem kleinen zusätzlichen Router machen. Darüber würde ich dem Arbeitslaptop einen eigenen virtuellen Internetanschluss mit einer öffentlichen IP-Adresse bauen, ähnlich wie frank_m das angedeutet hat, aber von SOCKS und TOR würde ich die Finger lassen. Auf dem Notebook wären dazu keine Veränderungen nötig. Es gibt Dienstleister, die so etwas anbieten, aber ob diese Lösungen mit der konkreten Anwendung wirklich kompatibel sind, müsste man mit dem jeweiligen Dienstleister klären.