Hallo zusammen,
ist der 1. Fehler nicht das gleiche, was wir früher bei IPv4 und Lancom hatten? Access Point bekommt via DHCP die DNS Adresse eines zentralen, über VPN erreichbaren Servers. Über den WLC-DNS Namen soll der Access Point mit seinem zentralen WLC Kontakt aufnehmen. Dies ging im Default-Zustand eine ganze Zeit nicht, weil die Lancom Access Points ihre Blockrouten für private Netzwerke hatten und somit den DNS / WLC nicht erreichen konnten ohne Eingriff durch den Admin.
Jetzt könnte man sagen, wieso ist das damals niemanden aufgefallen? Genau, vermutlich weil kaum jemand genau dieses Szenario einsetzt. Genauso wird es jetzt bei APs + IPv6 sein, wo ein via ULA erreichbarer DNS existiert. Gerade bei größeren Firmen wird sowas zum Einsatz kommen. Allerdings ist zumindest meiner Erfahrung nach bei dem Segment immer noch zum Großteil v6 deaktiviert. Passiert. Normales Ticket beim Hersteller aufmachen und entsprechend deiner vertraglich vereinbarten SLAs bekommst du einen Fix. Wieso muss man hier dann so ein Theater veranstalten?
Ich kenne jetzt die entsprechende RFC nicht für den v6 zu v4 Fallback. Aber sollten sich interne Dienste im LCOS fehlerhaft verhalten, wird dir auch hier ein Case beim Hersteller helfen. Gleiches ist z.B. im Callmanager passiert.
Das Forum hier ist ein Austauschort für Administratoren / Endanwendern, die Fragen zu Konfigurationen und Problemen haben. Softwarefixe wirst du hier maximal durch Zufall bekommen.
Gruß Dr.Einstein
DNSv6-Server ULA = alles kaputt?
Moderator: Lancom-Systems Moderatoren
-
- Beiträge: 2928
- Registriert: 12 Jan 2010, 14:10
Re: DNSv6-Server ULA = alles kaputt?
Das ist nicht unverschämt und auch kein Theater sondern ein Software-Bug über den man reden sollte. Und ich weiß nicht, warum ich hier als Endkunde niedergemacht werde. Es war viel Arbeit diesen Software-Bug zu analysieren. Der Fehler ist so arg, dass ich erstmal drüber reden wollte, bevor ich den beim Support eintüte. Vielleicht hat sich Lancom was bei gedacht. Vielleicht übersehe ich was.
Das Problem ist nämlich, dass der schlaue Admin, wenn er es dann analysiert (und gefunden) hat, einfach die Regel löscht. Wenn er nicht einfach wieder IPv6 auf dem Lancom-Gerät ausschaltet. Warum sollte solch ein Admin (und warum sollte eigentlich ich) mir die Mühe machen, dass (alles) im Support zu melden. Ich habe das Problem für mich bereits gelöst. Ich habe schon den Fix. Bin super happy, dass da nicht mehr im Verborgenen liegt, das ich eben nicht hätte kontrollieren können. Ein Kreuzchen an der richtigen Stelle drücken. Fertig.
Nur bedeutet dieser Fehler, dass sich z.B. Wireless-Access-Points nicht automatisch aktualisieren – und keiner merkt es bis man es überprüft. Das kann sicherheitsrelevant sein (siehe letzt die WLAN-Updates). Welche Motivation habe ich, sowas zu melden?
Ich hatte das Problem, dass mein Wireless-Access-Point kein Software-Update schob. Und ich habe mich hingesetzt, und das analysiert. Und ich habe die für mich vermeintliche Lösung gefunden – man beachte die Anführungszeichen im original Post. Aber die Ursache war irgendwie unvorstellbar. Daher dieser Thread.
Das Problem ist nämlich, dass der schlaue Admin, wenn er es dann analysiert (und gefunden) hat, einfach die Regel löscht. Wenn er nicht einfach wieder IPv6 auf dem Lancom-Gerät ausschaltet. Warum sollte solch ein Admin (und warum sollte eigentlich ich) mir die Mühe machen, dass (alles) im Support zu melden. Ich habe das Problem für mich bereits gelöst. Ich habe schon den Fix. Bin super happy, dass da nicht mehr im Verborgenen liegt, das ich eben nicht hätte kontrollieren können. Ein Kreuzchen an der richtigen Stelle drücken. Fertig.
Nur bedeutet dieser Fehler, dass sich z.B. Wireless-Access-Points nicht automatisch aktualisieren – und keiner merkt es bis man es überprüft. Das kann sicherheitsrelevant sein (siehe letzt die WLAN-Updates). Welche Motivation habe ich, sowas zu melden?
Nein, ich musste schlauer sein als Lancom. Nein, ich musste Deine Workarounds verstehen und nachtesten. Nein, ich musste schlauer sein als Du. Es ist nämlich eins, etwas zu erkennen, eins etwas zu beschreiben, und eins etwas zu erklären. Bleiben wir doch mal in dem Bild mit den 90+% dummen Usern. In dem Bild kannst Du Dir jetzt vorstellen, wo ich stehe, mit wem Du hier kommunizierst. Und ich habe mir wirklich Mühe gegeben, Dir das zu erklären. Besser geht es nicht. Hier liegt offenbar ein Software-Bug vor. Happens. Hier liegt offenbar eine fachliche Überforderung vor. Auch normal in der Informatik heutzutage. Aber dann bitte nicht das Szenario kleinreden. Dass mein Software-Bug nahezu irrelevant sei, interessiert niemand. Warum nicht lernwillig zeigen?
Ich hatte das Problem, dass mein Wireless-Access-Point kein Software-Update schob. Und ich habe mich hingesetzt, und das analysiert. Und ich habe die für mich vermeintliche Lösung gefunden – man beachte die Anführungszeichen im original Post. Aber die Ursache war irgendwie unvorstellbar. Daher dieser Thread.
Hatte ich auch nicht vor. Nur wollte ich wissen, ob meine Analyse so stimmt. Beim Support nämlich, muss ich wieder schlauer sein, damit ich dort überhaupt durchkomme. Und der Fehler ist nicht so easy-peasy. Wenn man unbedingt vermeiden will, dass falsch programmierte Host-Geräte ihre ULA nach draußen posaunen – und ja, davon habe ich hier einige – wenn man also dieses Ziel weiterverfolgen will und es trotzdem richtig machen will, dann wird das richtig viel Arbeit. Aber der Fehler zeigt auch, dass irgendwas in der Test-Abteilung schief geht. IPv6 ist eine riesige Herausforderung auch weil so viele Adress-Klassen existieren. Dann noch Dual-Stack. Wenn ich als Endkunde bei einem über Jahrzehnte gewachsenen System noch solche Fehler finde … Schluck. Dann aber bitte nicht kleinreden. Dann aber bitte lernwillig zeigen. Solche Fehler werden noch haufenweise im Feld auftauchen. Da muss man demütig bleiben.Dr.Einstein hat geschrieben: ↑07 Jul 2021, 18:27 Softwarefixe wirst du hier maximal durch Zufall bekommen.
Re: DNSv6-Server ULA = alles kaputt?
Das scheint aber bei der 10.70 nur für die erste Gegenstelle zu funktionieren.backslash hat geschrieben: ↑25 Mai 2021, 18:47 zusammen mit dem DPS wurde auch der fehlende Part in der IPv6-Firewall implementiert, so daß der DNS-Forwarder im IPv6 jetzt tatsächlich auch am Router "vorbei" laufen kann. Ich hab das mal für die nächets 10.50 (>= 10.50.0109) eingebaut. Damit sollten es dann auch mit den ULA-Sperr-Routen funktionieren...
Ich bin gerade dabei einen Kabel-Internet Zugang via Kaskade zu einer FritzBox Cable, zusätzlich zum schon bestehenden DSL Anschluss der Telekom zu konfigurieren. (Nicht wirklich optimal, aber leider ist die Routerfreiheit im Kabel-Internet Bereich auf Grund fehlender Verfügbarkeit von Euro-DOSCSIS 3.1 Cable-Modems Makulatur. Anderes Thema...)
Der Lancom bekommt von der Fritte eine ULA für den IPv6-DNS. Wenn ich den Lancom bei bestehender Verbindung zur Fritte neu starte wird mir diese als erste WAN-Verbindung im LAN-Monitor angezeigt und die ULA ist erreichbar. Die T-DSL Gegenstelle braucht halt etwas länger für die Aushandlung und erscheint in diesem Fall in der Auflistung als zweite WAN-Verbindung.
Boote ich den Lancom aber mit unterbrochener Verbindung zur Fritte und warte mit dem Anstöpseln bis die Aushandlung auf der T-DSL Schnittstelle abgeschlossen ist, wird die Fritte als zweite WAN-Verbindung im LAN-Monitor angezeigt und die ULA ist nicht mehr erreichbar. Erst ein Abschalten der 'fc00::/7' Sperroute macht diese wieder erreichbar.
Re: DNSv6-Server ULA = alles kaputt?
Hi geppi,
seit der Änderung in der 10.50 geht der DNS-Forwader definitiv am Router "vorbei" - solange das Weiterleitungsziel eine dedizierte Gegenstelle ist oder die Gegenstelle, auf die die Defaultroute zeigt. Wichtig ist nur, daß der Gegenstelle auch ein DNS-Server zugewiesen wurde - entweder per DHCP oder per PPP oder per VPN-Config-Mode oder manuell in der IP- bzw. IPv6-Parameterliste. Das kannst du im CLI über "show ipv6-interfaces" bzw. "show ipv6-interfaces" prüfen.
Um Probleme bei der DNS-Auflösung zu untersuchen hilft ansonsten der DNS-Trace (im CLI mit "trace # dns" starten)
BTW: aktuelle ist eine 10.72...
Gruß
Backslash
seit der Änderung in der 10.50 geht der DNS-Forwader definitiv am Router "vorbei" - solange das Weiterleitungsziel eine dedizierte Gegenstelle ist oder die Gegenstelle, auf die die Defaultroute zeigt. Wichtig ist nur, daß der Gegenstelle auch ein DNS-Server zugewiesen wurde - entweder per DHCP oder per PPP oder per VPN-Config-Mode oder manuell in der IP- bzw. IPv6-Parameterliste. Das kannst du im CLI über "show ipv6-interfaces" bzw. "show ipv6-interfaces" prüfen.
Um Probleme bei der DNS-Auflösung zu untersuchen hilft ansonsten der DNS-Trace (im CLI mit "trace # dns" starten)
BTW: aktuelle ist eine 10.72...
Gruß
Backslash
Re: DNSv6-Server ULA = alles kaputt?
Das ist allerdings seltsam. Ich habe LAN-4 als DSL-1 mit IPoE eingerichtet und den Lancom auf der Fritte als exposed host eingetragen.
Auf der Fritte ist DHCPv4 abgeschaltet und DHCPv6 für die Präfix Delegation konfiguriert.
Was ich im LAN-Monitor unter 'WAN-Verbindungen--->DSL Kanal 1--->Protokoll: Transparent--->Netzwerkprotokoll: IPv6--->IPv6-DNS Server' sehe sollte ja dem entsprechen was mir die CLI mit dem Befehl 'show ipv6-interfaces' anzeigt, oder?
Da stand definitiv die ULA der Fritte mit 'fd00::a4f2
45b6:f17a' weil diese sich selbst als DNS Server per DHCP anpreist.
Ich konnte von einem PC im Netz erfolgreich externe IPv6-Adressen anpingen aber keine Namensauflösung machen.
Der DNS Trace zeigte, dass keine Antwort vom DNS forwarder kam.
Wenn ich die Sperroute entfernt habe funktionierte auch die Namensauflösung.
Ich bin mir ziemlich sicher, dass ich dieses Verhalten nicht hatte, als die IPoE WAN-Verbindung an erster Stelle im LAN-Monitor stand.
Da funktionierte wie von Dir beschrieben die Namensauflösung auch mit der Sperroute, also wohl wie Du sagst "am Router vorbei".
Wenn die VDSL WAN-Verbindung allerdings an erster Stelle im LAN-Monitor steht hatte ich das von mir oben beschriebene Problem.
Ich kann und will das jetzt nicht mehr nachstellen, da ich einfach die öffentlichen IPv6-Adressen der DNS Server vom Kabelprovider in die DHCPv6 Client Konfiguration für die Gegenstelle eingetragen habe. Vielleicht schaut ja trotzdem nochmal einer Eurer Entwickler in den LCOS Code ob diese "am Router vorbei" Konfiguration irgendwie davon abhängen könnte in welcher Reihenfolge die WAN Interfaces verfügbar werden.
Auf der Fritte ist DHCPv4 abgeschaltet und DHCPv6 für die Präfix Delegation konfiguriert.
Was ich im LAN-Monitor unter 'WAN-Verbindungen--->DSL Kanal 1--->Protokoll: Transparent--->Netzwerkprotokoll: IPv6--->IPv6-DNS Server' sehe sollte ja dem entsprechen was mir die CLI mit dem Befehl 'show ipv6-interfaces' anzeigt, oder?
Da stand definitiv die ULA der Fritte mit 'fd00::a4f2
Ich konnte von einem PC im Netz erfolgreich externe IPv6-Adressen anpingen aber keine Namensauflösung machen.
Der DNS Trace zeigte, dass keine Antwort vom DNS forwarder kam.
Wenn ich die Sperroute entfernt habe funktionierte auch die Namensauflösung.
Ich bin mir ziemlich sicher, dass ich dieses Verhalten nicht hatte, als die IPoE WAN-Verbindung an erster Stelle im LAN-Monitor stand.
Da funktionierte wie von Dir beschrieben die Namensauflösung auch mit der Sperroute, also wohl wie Du sagst "am Router vorbei".
Wenn die VDSL WAN-Verbindung allerdings an erster Stelle im LAN-Monitor steht hatte ich das von mir oben beschriebene Problem.
Ich kann und will das jetzt nicht mehr nachstellen, da ich einfach die öffentlichen IPv6-Adressen der DNS Server vom Kabelprovider in die DHCPv6 Client Konfiguration für die Gegenstelle eingetragen habe. Vielleicht schaut ja trotzdem nochmal einer Eurer Entwickler in den LCOS Code ob diese "am Router vorbei" Konfiguration irgendwie davon abhängen könnte in welcher Reihenfolge die WAN Interfaces verfügbar werden.