Müsste man sich näher ansehen, von der Konfiguration über Logs und Traces, was da genau passiert. Im Moment kann es vom Heimnetz bis zum Server alles sein.
Beiträge von frank_m
-
-
Heute nochmal Werksreset des Routers neu verbunden und leider der gleiche Effekt.
Dabei hast du hoffentlich kein Backup einer vorhandenen Konfiguration eingespielt? Beim Wechsel der Anschlussart muss man die Box einmal frisch einrichten.
Grundsätzlich: Die 7490 wird nicht mehr mit Updates versorgt, auch nicht mit Sicherheitsupdates. Das ist vielleicht nicht die Ursache für deine Probleme, ausschließen kann man es aber auch nicht. So oder so ist es nicht mehr empfehlenswert, die Box als Haupt-Router einzusetzen, schon aus Sicherheitsgründen.
Zeige bitte mal Screenshots vom Online-Monitor der Fritzbox und vom Ereignis-Log, am besten aus einer funktionierenden und dann aus der nicht funktionierenden Phase.
-
Der Trace geht aber von DG zu Telekom, und nicht von Telekom zu DG. Das kann durchaus ein Unterschied sein.
twelve99 gehört schon nicht mehr zum DG Netz, sondern zu Telia. Die Verbindung zwischen Telia und Telekom ist schon öfter Gegenstand von Diskussionen gewesen. Schau dich mal um bezüglich der Peering Politik der Telekom, hier im Forum, oder auch sonst im Internet.
Ich wage es zu bezweifeln, dass es was bringt, sich an einen der Anbieter zu wenden. Willst du eine pragmatische Lösung? Such die einen kleinen VServer, der von beiden Anschlüssen aus gut zu erreichen ist, und nimm den als VPN Gateway.
-
Solche Informationen gibt es häufig nicht. Was hilft es dir, wenn da steht, im Nachbar-Ort muss die Anbindung ans Back-Bone erfolgen, aber keinerlei Informationen darüber, wann die Tiefbau-Mannschaft und wann die Techniker da Zeit für haben? Und genau das wird häufig nur recht kurzfristig geplant, da ggf. an anderer Stelle Dinge noch nicht fertig sind oder aus was für Gründen auch immer, kommt dann recht spontan ein Team vorbei. Genauso kann es woanders Störungen geben, und das geplante Team ist wieder weg. Bevor sie da alle drei tage reinschreiben "Machen wir nächste Woche, ach nee, doch nicht, dafür übernächste Woche schon mal was anderes, ach nee, wird auch nix, jetzt doch wieder das erste, ..." steht da halt Netzausbau, und wenn es fertig ist, ist es fertig.
-
Es ist natürlich denkbar, dass die Paketverluste durch eine defekte Komponente im PoP ausgelöst werden. Da ist dann auch die Frage, wie schnell kann Ersatz beschafft werden.
-
Erfahrung anderer hilft dir da nicht weiter, denn wie du hier im Forum sehr häufig nachlesen kannst, läuft es in jedem Anschlussbereich anders ab. Irgendwas zwischen 2 Wochen und 24 Monaten ist möglich.
Viele Faktoren tragen dazu bei, wann ein Netz aktiv gehen kann. Angefangen bei der Verfügbarkeit der Netzwerk-Technik über Dokumentation der Anschlüsse bis hin zur Bereitstellung des Backbones, wofür möglicherweise weit entfernt auch noch Tiefbau-Arbeiten stattfinden müssen. Das sind Abläufe, die siehst du nicht, sie sind aber trotzdem erforderlich. Deshalb erweckt es den Anschein, als ob nichts passiert.
-
Bei v6: mtr: Packet Type unsupported: Operation not supported
Das deutet darauf hin, dass dein Betriebssystem keine IPv6 Adresse hat.
v4:
Code
Alles anzeigenHOST: linux Loss% Snt Last Avg Best Wrst StDev 1. AS??? 192.168.178.1 0.0% 100 1.4 1.0 0.7 1.5 0.2 2. AS??? 100.124.1.14 0.0% 100 7.1 265.1 5.8 5114. 675.4 3. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 4. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 5. AS??? 80.81.192.132 0.0% 100 10.6 411.6 10.1 3099. 697.8 6. AS12306 82.98.102.7 0.0% 100 1069. 331.2 10.3 2097. 543.8 82.98.102.71 AS12306 82.98.102.71 7. AS12306 212.19.61.13 0.0% 100 10.2 175.8 10.0 3086. 478.1 8. AS12306 193.99.144.80 0.0% 100 3013. 713.0 10.4 9015. 1642.5Und das ist ein Trace ohne Paketverlust. Da sind zwar teilweise sehr lange Delays drin, aber keine Verluste.
-
Ja, da sieht man Paketverluste, aber es ist auch nur WinMTR und damit nur ICMP. Wenn die 20% Paketverlust sich aber auch auf TCP Anwendungen auswirken, dann wird vermutlich keine Webseite mehr geladen.
-
Ob die Probleme bei den Nachbarn irgendwie mit deinen zusammenhängen, darüber kann man von außen nur spekulieren. Fakt ist, dass es im Moment eben keine Beweise für einen Fehler des Providers gibt, da sowohl die Namensauflösung als auch die grundsätzliche IP-Übertragung für IPv4 und IPv6 funktioniert. Viel mehr muss der Provider eigentlich nicht machen: Was über die IP Pakete übertragen wird, ist Sache des Anwenders, und da sollte sich der Provider möglichst wenig einmischen.
Paketverluste wären eine Möglichkeit, die noch auf Providerseite liegt. Die können verschiedene Ursachen haben, wie z.B. Engpässe und Überlastung in der Infrastruktur. Verhältnismäßig kleine ICMP Pakete, wie sie von tracroute oder mtr auf die Reise geschickt werden, können dabei das Ergebnis verfälschen, und traceroute schickt auch nur 3 Pakete auf die Reise, das hat dann nur eine sehr eingeschränkte Aussagekraft. Aber vielleicht kann man mit einem mtr mit 100 Paketen was sehen.
Versuche es mal mit
mtr -eznb4Tw -c 100 ct.de
bzw.
mtr -eznb6Tw -c 100 ct.de
Das Kommando wird längere Zeit nichts ausgeben. Das ist normal. Irgendwann nach einigen Minuten kommt dann die Auswertung.
-
Die traces sind beide in Ordnung. Ein "*" irgendwo in der Mitte ist vollkommen egal. Bei dir funktioniert offensichtlich die Namensauflösung und auch die grundlegende Kommunikation über IPv4 und IPv6. Man könnte jetzt noch versuchen, herauszufinden, ob es ungewöhnlich viele Paketverluste gibt, das ist nur aus diesem Trace nicht zu erkennen. Tools wie mtr oder trippy zeigen da mehr.
Jedenfalls wird die Luft dünner für ein Problem bei der DG. Im Moment neige ich eher zu einem Problem in deinem Heimnetz oder auf den Endgeräten.
-
Irgendwie ist immer noch nicht klar, was eigentlich das Problem ist. Das einzige, was du gezeigt hast, sind Screenshots von funktionierenden IPv6 Traces. Dazu schilderst du, dass irgendwelche DoT DNS Server nicht funktionieren, aber was du konkret dagegen getan hast und welche Auswirkungen das hatte, schreibst du ebenfalls nicht. Wenn du nur einen DNS Server entfernst, heißt das ja nicht, dass in der Folge eine gültige DNS Konfiguration vorliegt.
Deshalb würde ich empfehlen, zeige noch mal Screenshots der Konfiguration des Internetzugangs deiner Fritzbox, dazu die Verbindungsdetails des Online Monitors, der DNS Server Einrichtung und der erweiterten Netzwerkeinstellungen im Heimnetz. Neben den Traces auf Google (IPv4 und IPv6) wären einige nslookup Ausgaben interessant, vor allem auch mit explizit anderen DNS Servern.
-
Das Limit an sich bezweifle ich ja nicht. Aber TCP und UDP nutzen ihre Ports unabhängig voneinander und haben beide 65000 Ports, deshalb gibt es das Limit pro Protokoll.
-
Die Aussage war 1000 pro Kunde.
Aber das macht doch gar keinen Sinn. Man hat 65000 Ports jeweils bei TCP und UDP, wobei TCP üblicherweise deutlich intensiver genutzt werden dürfte.
Und 1000 bei UDP wäre noch in weiter ferne, bis mein Spiel dagegen läuft.
Und genau deshalb hab ich von Anfang an ein Port Limit Problem für unwahrscheinlich gehalten.
-
Moment, das 1000 Port Limit macht nur Sinn pro Protokoll. Also 1000 für TCP und 1000 für UDP. ICMP nutzt gar keine Portnummern.
-
Nur wie lösche ich das bzw. stelle es um
Das solltest du eigentlich am besten wissen, es ist dein Router. Wir können dir sagen, was du machen musst, aber wie du es machen musst, solltest du mit Hilfe der Dokumentation des Routers dann herausfinden können.
Du solltest alle Optionen zeigen, das ist nicht vollständig. Hast du mal die Suche bemüht? Unify Geräte an DG sind hier schon öfter diskutiert worden. Da finden sich die Einstellungen bestimmt schon. Auf jeden Fall brauchst du RAs, so viel ist auch aus diesem kleinen Screenshot erkennbar.
-
Dann solltest du als Erstes die LAN Konfiguration deines Routers überprüfen, ob da auch alles so eingestellt ist, dass es das Prefix von der DG für die Heimnetzgeräte richtig verteilt. Bitte entsprechend die Screenshots hier einstellen. Und wenn du schon dabei bist: bitte auch Screenshots von der aktiven Netzwerkkonfiguration deiner Endgeräte (ifconfig / ipconfig Ausgaben je nach Betriebssystem).
-
Ich bin zwar online, bekomme aber nur einen gekürzte IPv6 ist wohl wegen Rapid Commit.
Was ist denn eine "gekürzte" IPv6? Jedenfalls hat Rapid Commit nichts damit zu tun, das kürzt lediglich den Verbindungshandshake, aber nicht die Adressen.
Das ist deinem Screenshot ist definitiv eine öffentliche IPv6 von der DG.
Was genau funktioniert denn nicht? Das, was wir bislang sehen können, sieht alles richtig aus. Geht was im Heimnetz nicht?
-
Na ja, was zaehlt ist weniger was Opnsense als aktive Verbindungen zaehlt, sondern was der AFTR der DG da macht... und wenn die sehr lange TimeOuts hat dann mag das relevante Limit erreicht sein, selbst wenn der eigene NAT router noch Luft nach oben andeutet.
Wie gesagt, die UDP NAT Timeouts bei der DG sind sehr kurz, deutlich unter 30 Sekunden. Mit 30 Sekunden Keep Alive in VoIP Clients verliert man regelmäßig die Port-Zuordnung und eingehende Anrufe kommen nicht an. Mit 20 Sekunden geht es sicher, vielleicht auch mit 25, das hab ich nicht getestet.
hier z.b.
Das ist zum einen TCP, und auch der Thread führte am Ende nicht zu dem Ergebnis, dass das Port-Limit was mit dem Problem zu tun hat.
Du kannst die games nicht zwingen v6 zu verwenden, wenn die destination eine v4 adresse ist, dann kannst Du mit v6 da auch nichts machen.
Die Spiele, die du genannt hast, bieten aber IPv6 Zugänge an. Da ist dann die Frage: Warum werden die nicht genutzt?
-
Hab ja nicht nur ich, ich habe schon andere Beiträge in diesem Form gesehen, wo screenshoot mit genau diesem icmp auf Verbindungsaufbau beantwortet werden.
Wo? Bitte verlinke die mal.
Das ICMP Paket kommt von einer DG IP ADresse, das hat mit meinem Netz nicht das geringste zu tun.
Es muss mit deinem Heimnetz zu tun haben. Warum sonst sollte der Router die Nachricht rausschicken? Selbst wenn du recht hast mit dem Port-Limit von 1000: dann gibt es 1000 offene UDP Verbindungen aus deinem Heimnetz.
Wie wäre es, wenn du erst mal alles sauber auf IPv6 umstellst und damit die Spieler schon mal aus deinen NAT Tabellen raus holst. Damit sind deren Verbindungsprobleme schon mal Geschichte, und irgendein Port-Limit spielt an deinem Anschluss garantiert keine Rolle mehr. Dann schau, was von den VPN Problemen noch übrig ist.
-
Unklar. Warum sollte ein Betreiber eines VPNs exta Limmzuege machen um die Fehler inkompetenter ISPs auszugleichen?
Beschäftige dich bitte mit ISAKMP und der Problematik "Quellport UDP 500". Wie gesagt, Quell-Port, nicht Ziel-Port. Es ist enorm problematisch, mehrere ISAKMP Verbindungen über einen NAT Router zu leiten. Selbst wenn er eine öffentliche IP hätte, aber zwei Endgeräte zu Hause, die beide einen VPN Tunnel zum AG aufbauen wollen (Handy und Notebook), hätte er das Problem. Es betrifft auch praktisch jede Mobilfunkverbindung. Klar, die größere Anzahl an Kunden hinter einem CG-NAT Router erhöht die Wahrscheinlichkeit von Kollisionen, ändert aber nichts an der grundlegenden Problematik. ISAKMP stammt aus einer Zeit, als noch niemand an NAT Router dachte, und wenn man es trotzdem nutzen will und nicht ein moderneres Protokoll einsetzen will, dann muss man eben halt Maßnahmen ergreifen (NAT-T). Unsere Firma ist deshalb von IPSec auf OpenVPN gewechselt, weil es mit wachsender Anzahl Kollegen aus Kabel-Netzen und Mobilfunkverbindungen am Ende nicht mehr darstellbar war.
