Beiträge von frank_m

Das einzige, worüber du dich aufregst, ist doch im Grunde, dass der Kunde den Provider darüber informieren muss, dass er einen eigenen Router verwenden will, oder? Denn beim Provider-Router ist es egal, solange der am Ende funktioniert. Und sobald jemand den kundeneigenen Router nutzen will, bekommt er auch die Daten.

Ja, genau. AVM macht in seinen Anleitungen auch explizit darauf aufmerksam.

WireGuard-VPN zwischen FRITZ!Box und anderem Router einrichten | AVM Deutschland

Zitat

Tragen Sie beim Erstellen der WireGuard-Verbindung für die FRITZ!Box keine IP-Adresse aus einem Transfernetz (Intermediate-Adresse), sondern die lokale IP-Adresse der FRITZ!Box ein (z.B. 192.168.20.1, Subnetzmaske 255.255.255.0).

Das Verhalten ist ein Stück weit eine Sonderlocke von AVM. Man muss es auf dem Schirm haben bei Einrichtungen zu Fritzboxen, da es schon ein wenig anders ist, als bei anderen Wireguard Gegenstellen.

Lies noch mal #45. Mehr ist dazu nicht zu sagen. In die andere Richtung gilt das natürlich auch: Der Provider kann die Routen Ping-optimal einrichten, aber wenn die Kapazität an den Peering-Knoten nicht stimmt, gibt es trotz gutem Ping Probleme auf Applikationsebene.

Beides ist wirklich komplett unabhängig voneinander.

Wie ich schon mal an anderer Stelle geschrieben habe, bin ich ein Freund davon, die Subnetze in den Adress-Zeilen so weit wie möglich einzuschränken (/32), um Routing Konflikte zu vermeiden. In den Allowed IPs Zeilen kann man dann den Bereich bei Bedarf auf /24 erweitern für die Geräte, für die es Sinn macht. Das ist allerdings Klagen auf relativ hohem Niveau. In dem beschriebenen Szenario werden die Zeilen so funktionieren.

Zitat von mbo77

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.

Das liegt daran, dass die Fritzbox Proxy ARP auch für die VPN Clients macht. Ich will die Vor- und Nachteile hier nicht im Detail auseinandernehmen, aber die Folge ist, dass man dort in der Adress-Zeile tatsächlich 192.168.178.1/24 eingeben muss: Hier auch unbedingt mit /24, und nicht mit /32, wie oben, da in diesem Fall die Adresszeile darüber entscheidet, auf welche Geräte die Fritzbox die VPN Clients drauf lässt.

Wenn wir jetzt den Gipfel der Klugscheißerei erklimmen wollen, dann könnten wir oben in der VPS Konfiguration die "PersistentKeepalive = 25" Zeilen hinterfragen. Wie du in der Folge richtig beschreibst, sparst du dir auch den Listen Port, da der Verbindungsaufbau nicht pro-aktiv vom VPS ausgeht. Der Raspi bzw. der mobile Client ist dafür verantwortlich, die Verbindung am Leben zu halten, da in Abhängigkeit vom NAT der VPS gar nicht weiß, wo er die Keep-Alive Pakete hinschicken soll (und zwar immer gerade dann, wenn er sie am nötigsten bräuchte). In der Praxis werden die Zeilen nur unnötigen Datenverkehr erzeugen, aber für die Verbindungsstabilität keinen Beitrag liefern. Schaden tun sie aber auch nicht.

In letzter Zeit häufen sich die Probleme zwischen Apple und AVM Geräten, die auf PMF und die dynamischen MAC Adressen der Apple Geräte zurückzuführen sind. Am besten beides deaktivieren (für die Deaktivierung von PMF muss man auf WPA2 zurück).

Zitat von mbo77

Peering und Routing gehören unzertrennlich zusammen.

Nein. Ein Provider kann ein hervorragendes Peering haben, und den Traffic von Düsseldorf nach Frankfurt trotzdem über Amsterdam leiten. Das hat nun wirklich gar nichts miteinander zu tun.

Hat aber absolut gar nichts mit dem Peering zu tun, sondern mit dem Routing des Providers.

Ein paar Tests mit mehreren anderen parallel arbeitenden Gegenstellen und einem Live Linux wären jetzt noch wünschenswert, um PC und Speedtest als Ursache auszuschließen.

Peering hat nur dann Einfluss auf die Paketlaufzeit, wenn die Knoten überlastet sind. Aber wenn das der Fall ist, machen sich weit früher andere Probleme bemerkbar, wie Paketverluste und Geschwindigkeitseinbußen.

Aus der Paketlaufzeit allein kann man nicht aufs Peering zu schließen, das ist nicht aussagekräftig.

Gut, bei GPON muss man onboarden. Das ist tausendfach auch hier im Forum nachzulesen und deshalb nicht wirklich eine Überraschung. Mich wundert, dass du Workarounds wie Werksreset im Netz findest, aber keinen Hinweis aufs Onboarding.

Ebenfalls auch hier im Forum die dringende Empfehlung, den Anschluss immer mit dem vom Provider empfohlenen Equipment in Betrieb zu nehmen. Du hast jetzt Glück gehabt, aber hätte es an deinem Anschluss eine Störung gegeben, hättest du Monate darauf warten können, dass sich jemand darum kümmert, weil es immer alle auf deine nicht unterstützte Box geschoben hätten. Danach kann man dann auf sein bevorzugtes Equipment wechseln, weil dann auch Technologien etc. klar sind, und sich Fragen nach entsprechenden SFP Modulen gar nicht mehr stellen.

Im Grunde bist du in Anbetracht der Umstände sehr problemlos an deinen Anschluss gekommen. Vor allem der Umstand, dass seitens des Providers zurückgerufen wurde, ist vorbildlich. Darüber würden andere sich freuen.

Zitat von LarsR

... Provider im Hintergrund offenbar 1&1, in Kooperation mit Telekom (deshalb 0800-330....).

Woher weißt du das mit 1&1 und der Telekom?

Genau. Frag mal die Leute, die EA Online Games zocken wollen, zur Peering Politik der Telekom. Achte aber auf genug Sicherheitsabstand.

Gerade das Peering ist doch das größte Argument gegen einen Telekom Anschluss.

Führt das Vorhandensein von Provider Extensions immer zu einer neuen Artikelnummer?

Meines Wissens ist die Möglichkeit, manuell Software-Updates zu installieren, nicht gegeben.

Zitat von ssdnvv

Hilft leider nicht, nach nur wenigen Minuten funktionieren auch mit dieser Einstellung die Anrufe nicht mehr

Dann liegt das Problem im Turris Omnia Router. Hast du da irgendwelche ALGs oder sowas aktiv?

Zitat von mbo77

Ich kenne auch nur ONTs, die per Patchkabel verbunden werden.

Ich kenne keinen Einzigen. Wenn man sich z.B. Fibertwist Installationen ansieht, wo aktive oder passive Aufsätze auf die Bodenplatte geschraubt werden und wie dort die Glasfaser eingeführt ist: Das ist ausschließlich für die Wandmontage geeignet. Alles andere hätte den sofortigen Tod der Faser zur Folge.

Ich würde es nicht machen, gerade nicht bei diesen dünnen gelben Kabeln. Einmal falsch angeditscht, und das wars.

Ja, die Faser ist das Problem. Für die Verbindung vom HÜP zum ONT sieht der Provider ja keine Patchkabel vor, wie sie z.B. einer Fritzbox beiliegen, wie sich auf den Fotos ja einfach verifizieren lässt. Die ist nicht für den "mobilen" Einsatz ausgelegt, und wird im ONT ja häufig auch nicht gesteckt, sondern ist gespleißt. Wenn die im Schrank liegt, in den Bücher, BlueRays und sonstwas rein und rausgeschoben werden und die bekommt jedes Mal einen Stoß mit, dann ist die im Handumdrehen abgeknickt.

Die Frage ist nicht ernst gemeint, oder? Da führt ein Glasfaserkabel rein. Lebenserwartung im Schrank kleiner 1 Minute.

Zitat

In Gebieten mit sehr viel Glasfaser nehme die Telekom Linecards für die Kupferanschlüsse außer Betrieb, was auch Strom spare.

Was nicht so wirklich klar wird: Machen sie das nur in Gebieten, wo sie selber Glasfaser anbieten, oder auch in Gebieten, wo andere Provider ausgebaut haben?