[Problem] 7580: Falsche IP- Zuweisung trotz versch. MAC?!?
- Ersteller M*I*B
- Erstellt am
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Ach, und warum befüllt mein AdAway die /system/etc/hosts mit unliebsamen DNS und lässt sie auf einen lokalen Webserver auflaufen ?
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Aus Sicht des Systems ?
Mal zählen...
/ # wc -l /system/etc/hosts
58745 /system/etc/hosts
...ne Menge.
Mal zählen...
/ # wc -l /system/etc/hosts
58745 /system/etc/hosts
...ne Menge.
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
DNS wird überbewertet, deswegen nutzt das Fritz!Box Webinterface auch keine DNS Links in der Übersichtsseite/Heimnetzübersicht/Netzwerk.
...die traut sich selber nicht übern Weg.
...und die Verwirrung würde noch gesteigert werden , wenn eine DNS eine IPv6 zurückliefern würde.
Zum Glück tut das die Box nur im Ereignislog, wenn in einer Dual Stack Umgebung die "fritz.box", "myfritz.box" oder "fritz.nas" aufgerufen wird.
...die traut sich selber nicht übern Weg.
...und die Verwirrung würde noch gesteigert werden , wenn eine DNS eine IPv6 zurückliefern würde.
Zum Glück tut das die Box nur im Ereignislog, wenn in einer Dual Stack Umgebung die "fritz.box", "myfritz.box" oder "fritz.nas" aufgerufen wird.
Die FB zeigt IPv6 IPs an in den Geräten wenn man diese bearbeitet, nicht nur beim einloggen im Log.
Ändert aber nichts am OT mittlerweile.
Ändert aber nichts am OT mittlerweile.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,283
- Punkte für Reaktionen
- 1,755
- Punkte
- 113
Welchen professionellen(!) Sinn ergibt ein System, welches mit zwei NICs in demselben Segment unterwegs ist? Port-Trunking (bzw. "link aggregation") oder Failover ist ja eher unwahrscheinlich ... dafür fehlt dann wieder das (wirklich professionelle) Equipment in Form von Switches, die so etwas unterstützen. Das reklamiert eine FRITZ!Box ja nicht mal im Ansatz für sich, weder mit mehreren NICs noch mit einem einzelnen (VLAN).
Mir fehlt da etwas die Phantasie ... obwohl ich selbst genug "multi-homed systems" betreibe. Für "ein Adapter, mehrere Adressen" ist das mit den "use cases" kein Problem ... alles andere (bis hin zur Freigabe bestimmter Dienste nur unter einer definierten Adresse) würde ich eher anders lösen und wenn dieser weitere NIC irgendwie einer VM exklusiv zugewiesen wäre, würde er ja vom "bare metal server" eher nicht mehr benutzt.
Aber vielleicht wäre das ja auch nicht professionell genug, was ich da an Alternativen im Sinn hätte ... ich bin halt nur generell etwas skeptisch, wenn jemand eine Funktion benutzen will, die sich so nicht realisieren läßt - und dann ist das Ergebnis, daß das Gerät "nicht professionell genug" ist und nicht nur die Idee dahinter eher ungewöhnlich bis seltsam (kommt ja auch auf den eigenen Blickwinkel auf den "use case" an).
Wobei ... auch diesen Anspruch der "Professionalität" erhebt die FRITZ!Box ja eher nicht, schon die Positionierung im Geschäftskundenbereich (von AVM auch eher selten zu lesen - oder kennt irgendjemand AVM-Artikel, gerne auch aus der KB, die explizit auf gewerblichen Einsatz der Boxen zielen?) ist eher fragwürdig.
Die wenigsten werden wohl bestreiten, daß das FRITZ!OS mit seiner eher einfach gehaltenen Oberfläche (was die Anzahl der Optionen und ihre "Abhängigkeiten" über JS-Skripting angeht) sich weniger an professionelle Router-Admins richtet als vielmehr an jemanden, der von der Materie nur beschränkt Ahnung hat. Damit bietet das GUI eben nur die Optionen an, die wirklich einer Mehrzahl von Kunden etwas bringen ... jede weitere konfigurierbare Einstellung bringt zusätzliche Komplexität in die Oberfläche und erhöht die Chancen für Fehler - sowohl bei der Programmierung als auch bei der Benutzung.
Wenn einem dann die zusätzlichen Möglichkeiten (vom Shell-Zugang (den man sich ja problemlos einrichten kann, erst recht als Profi) bis zum Editieren der Export-Datei) nicht ausreichen für die Realisierung des eigenen Vorhabens, ist eine FRITZ!Box eben auch der falsche Router ... wer sie dann trotzdem für die Nutzung auserkoren hat, läßt mich irgendwie auch an seiner eigenen Professionalität zweifeln (zumindest bei dieser Entscheidung).
Das läßt für mich eben auch den Satz:
Zumal hier auch wieder eine extreme "Selektion" betrieben wird, wofür die FRITZ!Box nun wieder zuständig sein soll ... den DHCP-Server darf sie nicht geben, aber gleichzeitig soll sie eine "Übersicht" im Netzwerk anbieten bzw. diese Übersicht behalten und die richtigen Freigaben statisch einrichten.
Das ist wieder das alte Problem ... zwar hat AVM inzwischen beim IP-Client wohl diese Netzwerk-Übersicht eingeschläfert, weil die Kunden eben L2 und L3 nicht auseinanderhalten können (und müssen, sie sind ja keine Profis) und dann von einem IP-Client trotzdem hellseherische Fähigkeiten zum umliegenden Netzwerk erwarten.
Aber vielleicht muß man auch noch konsequenter vorgehen und gemeinsam mit dem DHCP-Server in der FRITZ!Box dann auch alle Versuche beerdigen, die Topologie des (Ethernet-)Netzwerks irgendwie zu erraten (WLAN ist da einfacher, zumindest beim "Meshen"), solange dafür keine wirklich tauglichen Informationen vorhanden sind (z.B. eben Switches, die LLDP beherrschen). Wobei AVM wohl genau in die entgegengesetzte Richtung marschiert oder die Behandlung von LLDP ist in den "deviceinfod" gewandert ... jedenfalls gibt es den früher mal vorhandenen "lltpd" auch schon seit einigen Versionen nicht mehr.
Jedenfalls würde ich dann unter "professionellen Aspekten" auch eher mit einer dynamischen Portweiterleitung mittels PCP arbeiten auf den betroffenen LAN-Clients (das richtet die dann ein, wenn der Service auch tatsächlich bereit ist) und nicht mit einer statischen Freigabe im Edge-Router - das "entschärft" dann auch die Folgen der "Verwirrung" der FRITZ!Box ob der verschiedenen IP-Adressen ein und desselben Hosts mit mehr als einem NIC, der auch noch (permanent) mit ihr verbunden ist. Wobei AVM tatsächlich Mist gebaut hätte, wenn eine einmal eingerichtete Freigabe für ein "landevice" (wo ja dann eine konkrete Adresse im "ipv4forwardrules"-Eintrag steht in der "ar7.cfg") einfach so auf eine andere Adresse gesetzt wird ... aber das ist normalerweise auch eher ein Fehler der (noch neuen) PCP-Implementierung und der versuchten Reaktion darauf, daß so ein Client schon mal seine Adresse ändern könnte (gerade bei DHCP-basierter IP-Adressvergabe).
Was läuft eigentlich auf diesem Server für ein System? Ist tatsächlich 100% sicher, daß dort das System bei einer ARP-Abfrage für "192.168.1.11" niemals von der MAC-Adresse antwortet (nicht mit "mit der MAC-Adresse" verwechseln), die auf "98" endet? Je nach System kann so ein "table lookup" ja auch unterschiedlich ablaufen und da hier wohl beide NIC ein solches Broadcast-Paket erhalten, könnte es auch gut sein, daß beide antworten ... selbst wenn der Adapter mit der IP-Adresse "192.168.1.10" mit der korrekten MAC-Adresse für den "99"-Adapter antwortet (und sich damit an die "Spielregeln" hält, wie es auch bei Proxy-ARP der Fall wäre), kommt diese Antwort aus Sicht der FRITZ!Box dann eben vom Host mit der "98"-MAC und damit sieht das ja auch so aus, als würde dieser Host für den anderen mit der "192.168.1.10" als ARP-Proxy arbeiten, was eine "relay"-Funktion nahelegt (was die Box dann als "angeschlossen über ..." interpretieren müßte).
Wenn das System des Servers es unterstützt, würde ich hier jedenfalls mal kontrollieren, wie die ARP-Antworten wirklich aussehen und - wenn meine Vermutung zutrifft - mittels "ebtables" (o.ä.) dafür sorgen, daß ARP-Antworten für die entsprechende IP-Adresse auch nur jeweils vom richtigen NIC gesendet werden und nicht "über Kreuz" oder gar zweimal (eine pro NIC).
Mir fehlt da etwas die Phantasie ... obwohl ich selbst genug "multi-homed systems" betreibe. Für "ein Adapter, mehrere Adressen" ist das mit den "use cases" kein Problem ... alles andere (bis hin zur Freigabe bestimmter Dienste nur unter einer definierten Adresse) würde ich eher anders lösen und wenn dieser weitere NIC irgendwie einer VM exklusiv zugewiesen wäre, würde er ja vom "bare metal server" eher nicht mehr benutzt.
Aber vielleicht wäre das ja auch nicht professionell genug, was ich da an Alternativen im Sinn hätte ... ich bin halt nur generell etwas skeptisch, wenn jemand eine Funktion benutzen will, die sich so nicht realisieren läßt - und dann ist das Ergebnis, daß das Gerät "nicht professionell genug" ist und nicht nur die Idee dahinter eher ungewöhnlich bis seltsam (kommt ja auch auf den eigenen Blickwinkel auf den "use case" an).
Wobei ... auch diesen Anspruch der "Professionalität" erhebt die FRITZ!Box ja eher nicht, schon die Positionierung im Geschäftskundenbereich (von AVM auch eher selten zu lesen - oder kennt irgendjemand AVM-Artikel, gerne auch aus der KB, die explizit auf gewerblichen Einsatz der Boxen zielen?) ist eher fragwürdig.
Die wenigsten werden wohl bestreiten, daß das FRITZ!OS mit seiner eher einfach gehaltenen Oberfläche (was die Anzahl der Optionen und ihre "Abhängigkeiten" über JS-Skripting angeht) sich weniger an professionelle Router-Admins richtet als vielmehr an jemanden, der von der Materie nur beschränkt Ahnung hat. Damit bietet das GUI eben nur die Optionen an, die wirklich einer Mehrzahl von Kunden etwas bringen ... jede weitere konfigurierbare Einstellung bringt zusätzliche Komplexität in die Oberfläche und erhöht die Chancen für Fehler - sowohl bei der Programmierung als auch bei der Benutzung.
Wenn einem dann die zusätzlichen Möglichkeiten (vom Shell-Zugang (den man sich ja problemlos einrichten kann, erst recht als Profi) bis zum Editieren der Export-Datei) nicht ausreichen für die Realisierung des eigenen Vorhabens, ist eine FRITZ!Box eben auch der falsche Router ... wer sie dann trotzdem für die Nutzung auserkoren hat, läßt mich irgendwie auch an seiner eigenen Professionalität zweifeln (zumindest bei dieser Entscheidung).
Das läßt für mich eben auch den Satz:
eher als Mißverständnis erscheinen ... dieser Fall des Einbindens eines Systems in ein Netzwerk mit zwei verschiedenen Adaptern innerhalb eines Netzwerk-Segments ist - in meinen Augen jedenfalls - extrem exotisch und die "Reaktion" des AVM-GUI betrachte ich selbst gar nicht als Fehler - jedenfalls nicht, solange die wirkliche Ursache nicht abgeklärt ist.
Zumal hier auch wieder eine extreme "Selektion" betrieben wird, wofür die FRITZ!Box nun wieder zuständig sein soll ... den DHCP-Server darf sie nicht geben, aber gleichzeitig soll sie eine "Übersicht" im Netzwerk anbieten bzw. diese Übersicht behalten und die richtigen Freigaben statisch einrichten.
Das ist wieder das alte Problem ... zwar hat AVM inzwischen beim IP-Client wohl diese Netzwerk-Übersicht eingeschläfert, weil die Kunden eben L2 und L3 nicht auseinanderhalten können (und müssen, sie sind ja keine Profis) und dann von einem IP-Client trotzdem hellseherische Fähigkeiten zum umliegenden Netzwerk erwarten.
Aber vielleicht muß man auch noch konsequenter vorgehen und gemeinsam mit dem DHCP-Server in der FRITZ!Box dann auch alle Versuche beerdigen, die Topologie des (Ethernet-)Netzwerks irgendwie zu erraten (WLAN ist da einfacher, zumindest beim "Meshen"), solange dafür keine wirklich tauglichen Informationen vorhanden sind (z.B. eben Switches, die LLDP beherrschen). Wobei AVM wohl genau in die entgegengesetzte Richtung marschiert oder die Behandlung von LLDP ist in den "deviceinfod" gewandert ... jedenfalls gibt es den früher mal vorhandenen "lltpd" auch schon seit einigen Versionen nicht mehr.
Jedenfalls würde ich dann unter "professionellen Aspekten" auch eher mit einer dynamischen Portweiterleitung mittels PCP arbeiten auf den betroffenen LAN-Clients (das richtet die dann ein, wenn der Service auch tatsächlich bereit ist) und nicht mit einer statischen Freigabe im Edge-Router - das "entschärft" dann auch die Folgen der "Verwirrung" der FRITZ!Box ob der verschiedenen IP-Adressen ein und desselben Hosts mit mehr als einem NIC, der auch noch (permanent) mit ihr verbunden ist. Wobei AVM tatsächlich Mist gebaut hätte, wenn eine einmal eingerichtete Freigabe für ein "landevice" (wo ja dann eine konkrete Adresse im "ipv4forwardrules"-Eintrag steht in der "ar7.cfg") einfach so auf eine andere Adresse gesetzt wird ... aber das ist normalerweise auch eher ein Fehler der (noch neuen) PCP-Implementierung und der versuchten Reaktion darauf, daß so ein Client schon mal seine Adresse ändern könnte (gerade bei DHCP-basierter IP-Adressvergabe).
Was läuft eigentlich auf diesem Server für ein System? Ist tatsächlich 100% sicher, daß dort das System bei einer ARP-Abfrage für "192.168.1.11" niemals von der MAC-Adresse antwortet (nicht mit "mit der MAC-Adresse" verwechseln), die auf "98" endet? Je nach System kann so ein "table lookup" ja auch unterschiedlich ablaufen und da hier wohl beide NIC ein solches Broadcast-Paket erhalten, könnte es auch gut sein, daß beide antworten ... selbst wenn der Adapter mit der IP-Adresse "192.168.1.10" mit der korrekten MAC-Adresse für den "99"-Adapter antwortet (und sich damit an die "Spielregeln" hält, wie es auch bei Proxy-ARP der Fall wäre), kommt diese Antwort aus Sicht der FRITZ!Box dann eben vom Host mit der "98"-MAC und damit sieht das ja auch so aus, als würde dieser Host für den anderen mit der "192.168.1.10" als ARP-Proxy arbeiten, was eine "relay"-Funktion nahelegt (was die Box dann als "angeschlossen über ..." interpretieren müßte).
Wenn das System des Servers es unterstützt, würde ich hier jedenfalls mal kontrollieren, wie die ARP-Antworten wirklich aussehen und - wenn meine Vermutung zutrifft - mittels "ebtables" (o.ä.) dafür sorgen, daß ARP-Antworten für die entsprechende IP-Adresse auch nur jeweils vom richtigen NIC gesendet werden und nicht "über Kreuz" oder gar zweimal (eine pro NIC).
Zuletzt bearbeitet:
Es gibt Switch unter 50€ die auch VLAN oder Portbündelung anbieten für link aggregation ect., dieses läuft auch trotz einer FB ohne Probleme.
Selbst mit Windows in einer VM auf dem NAS, kein Problem, jede VM bekommt von FB eigene IP und wird angezeigt als sei es eigene Gerät im Netzwerk. Jede VM streut aber auch eigenen Hostnamen und MAC, daher alles kein Problem.
Was 2 Netzwerkkarten im selben Segment sollen, weiß ich auch nicht. Ich habe meine am NAS gebündelt und nutze so 2Gbit Anbindung.
Selbst mit Windows in einer VM auf dem NAS, kein Problem, jede VM bekommt von FB eigene IP und wird angezeigt als sei es eigene Gerät im Netzwerk. Jede VM streut aber auch eigenen Hostnamen und MAC, daher alles kein Problem.
Was 2 Netzwerkkarten im selben Segment sollen, weiß ich auch nicht. Ich habe meine am NAS gebündelt und nutze so 2Gbit Anbindung.
Die neuen System generieren eine UUID für die Netzkonfiguration. So wird z.B. beim DHCP diese UUID für die Namensvergabe verwendet, nicht die MAC_Adresse, wenn das Gerät sich einmal am Netz gemeldet hat.
Auch bei der IP-Vergabe beim IPv6 durch DHCP6 oder Router-Advertisement.
Nur wenn explizit konfiguriert wird, dass sich das Geräte alle x Stunden/Tage einen neue IP geben soll, wird das nicht darüber geregelt.
Auch bei der IP-Vergabe beim IPv6 durch DHCP6 oder Router-Advertisement.
Nur wenn explizit konfiguriert wird, dass sich das Geräte alle x Stunden/Tage einen neue IP geben soll, wird das nicht darüber geregelt.
Neueste Beiträge
-
Fritz!DECT 302 regelt nicht mehr- Letzte: stoney
-
Vodafone Kabel - Rufnummer als IP Nummer nutzen
- Letzte: stoney
-
FRITZ!Box 6820 v2 & v3 / FRITZ!OS 7.59 vom 28.11.2024
- Letzte: weberhan
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte
- Letzte: Erforderlich
-
[Sammlung] FRITZ!Smart Thermo 302 - Firmware 0.22 - 5.xx
- Letzte: stoney
-
AVM 6890 kein FW Update auf OS 8.0 ?
- Letzte: Furrore
-
CP600 - Punkte der Kontaktbearbeitung
- Letzte: anzah