Warum in der Antwort Bezug auf die 5590 genommen wird ist mir völlig unklar
Vermutlich weil die 07.29 bislang nur mit der 5590 bei der DG in der Testdatenbank auftaucht. Die 07.30 offenbar noch mit keiner Box.
Beiträge von frank_m
-
-
Das hört sich wirklich so an, als ob an euren Anschlüssen dann wirklich nur noch die 5530 07.26 funktioniert. Da kommen mir zwei Fragen:
- Welche 07.26 habt ihr drauf? Die alte oder die neue? (siehe: RE: FritzBox 5530 und Deutsche Glasfaser)
- War bei der Aktivierung eurer 5530 damals der Support im Boot? Also "händische" Unterstützung?
-
Da muss man jetzt differenzieren.
Bei IPv6 wird sehr viel Signalisierung über ICMP Nachrichten gemacht, das sind aber keine Pings. Deshalb ist es wichtig, dass ICMP Nachrichten bei IPv6 fließen können, um den vollen Funktionsumfang zu haben (ein schönes Suchbeispiel bei Google ist "mss clamping"): Fehlendes ICMPv6 kann viel Ärger bereiten.
Das heißt aber nicht, dass man Pings von außen zulassen muss. Das kann man machen, dramatisch ist die Sicherheitslücke nach heutigem Wissensstand nicht, aber sowas kann sich schnell ändern.
Deshalb: Wenn dein Service wie vorgesehen funktioniert, würde ich Pings von außen nur zulassen, wenn du es wirklich brauchst. Einfach für Spaß eher nicht. Testweise kannst du es natürlich immer mal freischalten. Wie alfala geschrieben hat, braucht es dafür eine entsprechende Firewall-Regel.
-
Ich glaube, dass sich beim Wechsel von einer 5530 auf die 5590 (u.a.) die gpon_serial ändert. Aber da ändert sich noch erheblich mehr. Was lässt dich glauben, dass ausgerechnet die gpon_serial dazu führt, dass die Box nicht mehr aus dem Training kommt?
Ich denke, eine gerätespezifische Option ist nicht dafür verantwortlich, ob das Training erfolgreich ist, oder nicht. Das wird eine Information sein, die den Gerätetyp klassifiziert, aber nicht das einzelne Gerät. Die DG entscheidet, ob eine 5530 oder 5590 oder ein Nokia ONT synct. Sie entscheidet aber nicht, ob es die 5590 mit gpon_serial 12345 ist. Jedenfalls nicht, solange es um den Aktivierungsmodus geht. Beim Zutritt zum regulären Internetzugang kann die gpon_serial durchaus überprüft werden, weil da ja eine kundenspezifische Option herangezogen werden muss.
-
Moment, vielleicht verstehe ich dein Problem nicht. Die Nextcloud läuft und ist intern wie extern problemlos erreichbar. Nur der Ping funktioniert nicht. Da ist die Frage: Warum brauchst du den Ping, wenn alles andere läuft?
-
Wäre mal interessant ob sich die 'gpon_serial' beim Update von 7.26 auf 7.29/30 irgendwie ändert. Das führt auf jeden Fall dazu dass die Box im Training hängen bleibt.
Das würde mich wundern, denn dann dürfte eine fabrikneue Box niemals über das Training hinauskommen.
-
P.S: Den ONT habe ich hier noch liegen, aber nach Aktivierung der FB nicht mehr auf Funktion getestet.
Das wäre in dem Zusammenhang aber sehr interessant.
-
Wäre die Frage im OpenSense Forum nicht besser aufgehoben?
Aber blöde Frage: Der eigentliche Dienst läuft, warum dann noch Ping? Im Grunde öffnest du nur ein weiteres Einfallstor. Hast du einen konkreten Anwendungsfall dafür? Sonst würde ich es weglassen. Es ist nicht ohne Grund standardmäßig im Nextcloud gesperrt.
-
Für die Output Chain steht aber die Policy auf ACCEPT, das heißt doch wenn sonst keine Regel vorhanden ist, dann sollte doch alles akzeptiert werden, oder?
Wenn klar ist, wie man da hinkommt, dann kann das sein.
Und mangle und nat sollten doch meines Erachtens auch keine Pakete wegfiltern... oder?
Naja, wer weiß, was dan in den Pre- und Postrouting Regeln so angestellt wird? Auf jeden Fall müssen da die NAT Regeln fürs LAN rein. Bedenke; Für den Router sind die Forwarding Regeln wichtiger, als In- und Out Regeln. IP Forwarding an sich ist ja an?
Mit "tcpdump -i any" schließe ich ja auch das Interface mit ein mit dem ich meinen PC verbunden habe und es zeigt so unendlich viel Traffic an, dass ich überhaupts nichts mehr finde...
Da musst du halt filtern. Entweder filterst du die Paketbomben raus (z.B. "not port 22" um SSH auszuschließen), oder du filterst präzise auf das, was du suchst (icmp oder udp oder was auch immer).
(wobei es am Ende ja das gleiche ist, nur dass ich an dem RJ45 Port über DHCP meine Daten vom ONT bekomme, statt an dem SFP+ Port direkt über die Glasfaser)
Das weiß ich eben nicht, ob das für die UDM das gleiche ist. Das musst du selber herausfinden, ob sie den SFP Port wie jeden anderen WAN Port behandelt.
-
das Problem ist ja, dass meine pings und traceroutes im tcpdump gar nicht erscheinen!
Woran könnte das denn liegen?
Zum Beispiel an der Firewall. Die Pakete werden nicht zum externen Interface durchgelassen, z.B., weil die Absenderadresse nicht passt, oder weil die Firewall es nicht zulässt. Du kannst auch mal mit "tcpdump -i any" schauen, ob die Pakete auf einem anderen Interface auftauchen. Auch das kann ein Hinweis auf fehlerhaftes Routing sein.
Firewall Regeln habe ich keine eingestellt, ich habe die UDM wie gesagt auf Werkseinstellungen zurückgesetzt und gehe davon aus, dass die Standardeinstellungen passen sollten, oder?
Oh nein, davon gehe ich nicht aus. Das passt ja schon bei Heimroutern nicht, viel weniger bei professionellen Geräten. Du wirst präzise einstellen müssen, was auf deinen Interfaces erlaubt ist und welcher Traffic rein und rauskommt. Im Speziellen die NAT Regeln musst du selber setzen. In deine Ausgabe sieht man, dass für die Output Chain einfach gar nichts vorhanden ist, und für WAN sind sowohl eingehend als auch ausgehend nur DROP Regeln zu sehen.
Ich hatte sie auch schon mal gepostet, kann man damit was anfangen?
Das sind aber auch nur die aus der "filter" Table. Die aus den anderen Tables, z.B. nat oder mangle, fehlen.
-
Na und mein traceroute -i eth9 8.8.8.8 sollte ja auch ohne DNS funktionieren...
Versuche es mal ohne das -i eth9. Hast du mit tcpdump untersucht, welche Absender-Adresse der traceroute bzw. der ping nimmt? Gibt es entsprechende Firewall Regeln, die den Traffic erlauben und NAT für die privaten Adressen machen?
-
Das sieht sehr gut aus. IP, Gateway und DNS Server sind da. Das Gateway liegt auch im lokalen Subnetz, also alles gut.
Jetzt musst du die UDM nur noch davon überzeugen, die Informationen aus der DHCP Antwort auch ins System zu übernehmen, Sprich: Adresse, Subnetzmaske, Gateway und DNS Server setzen. Dabei die Lease Time nicht aus den Augen verlieren, um rechtzeitig eine Verlängerung zu beantragen.
-
(Ich meine gelesen zu haben, dass man dies bei einem Glasfaseranschluss der Telekom so machen muss oder täusche ich mich da?)
Du verwechselst AON und GPON.
-
Ich nehme mal an, dein Anschluss läuft im Modus "kundeneigener Router"? (Kannst du im Kundencenter nachsehen). Falls ja: Dann musst du lediglich die VLAN ID 362 auf der Internetverbindung aktivieren. Alles andere bleibt genau so, wie es ist. Der ONT filtert lediglich diese VLAN ID raus, und ist ansonsten transparent.
-
Wenn es AON ist, ist die Wahrscheinlichkeit recht hoch. Dazu gibt es auch schon Beispiele im Forum. Ggf. kann die DHCP und IPv6 Konfiguration ein wenig tricky werden, aber üblicherweise bekommt man es hin. Wobei, ich bin mir gerade nicht sicher, ob es OpenSense oder irgendwas von Ubiqity war, was den Ärger bei IPv6 machte. Aber wie gesagt: Einfach mal ein wenig suchen.
-
Und warum du das loopback Interface hinzuziehst, wird auch nicht klar. Warum machst du das?
Ist das Gateway denn richtig? Um das herauszufinden, musst du die DHCP Antwort vom Provider auswerten, das geht u. a. auch mit tcpdump. Natürlich musst du in der Lage sein, den zu sniffen, d. h.: UDM rebooten ohne Glasfaserverbindung, sicherstellen, dass es keine IPs auf eth9 gibt, tcpdump starten und dann das Kabel anstöpseln. tcpdump könntest du mit -vv starten, um mehr zu sehen. Oder noch besser: schreibe mit -w dump.pcap die Paketaufzeichnung weg und schaue es dir später mit Wireshark am PC an.
Wie dem auch sei, die UDM sollte selber in der Lage sein, nach einer DHCP Antwort seitens des Providers die Routen und DNS-Server selbständig einzurichten. Da musst du dir also noch mal die Anleitung hernehmen und die Internetkonfiguration glattziehen. Da stimmt noch was Größeres nicht.
-
Die ARP Requests sind ein gutes Zeichen, denn das sind ankommende Pakete. Dein Interface funktioniert augenscheinlich korrekt. Jedenfalls kommen Pakete aus dem Internet an. Du versuchst nur nicht, welche zu senden.
Du hast vergessen, die Routen zu zeigen. Arbeite besser mit ip anstatt mit den alten ifconfig Tools. Ich vermute ein größeres Problem bei den Routen.
-
VPN wäre für meine privaten Dienste auf jeden Fall eine Option.
Storj und Myst fallen dann aber wieder raus.
Nein, warum? Die Dienste werden ja nicht im VPN angeboten, lediglich der Port wird auf eine öffentliche IP gemappt.
-
Wäre ein VPS nicht genau die Lösung über 6tunnel oder ist das nochmal eine andere Option?
Nee, ich dachte da an eine VPN Lösung, wegen UDP. Ein Wireguard- oder OpenVPN Tunnel über IPv6, und eine Portweiterleitung auf IPv4 auf dem VPS, der auf eine interne IPv4 bei dir mapt. Klappt hervorragend, einige Beispiele haben wir schon hier im Forum (u.a. meine).
Es geht um tausende private Haushalte auf der ganzen Welt (Storj v3 oder Myst).
Das ist dann aber deren Problem, oder? Stell auf IPv6 um, und dann können sie ja sehen, wie sie es realisieren. Möglichkeiten gibts ja genug. Wenn du willst, kannst du ja sogar noch eine Anleitung geben.
Blöde Frage: Bei "tausenden Nutzern" auf aller Welt macht es wirklich noch Sinn, einen Server im Heimnetz zu hosten? Strom, Latenzen, Sicherheit?
-
Zwei weitere Lösungen fallen mir noch ein:
- ein kleiner VPS mit öffentlicher IP (1-2 EUR pro Monat)
- Versorgung der reinen IPv4 Anschlüsse mit einer IPv6 Adresse, z.B. über einen Tunnelbroker (kostenlos).
Meinen Unraid Server bzw. die Docker kann ich nicht mit einer IPv6 Adresse ausstatten.
Das ist dann aber eher "nicht wollen" als "nicht können", oder? Weil technisch ist das absolut kein Problem.
