Suche Erfahrung mit ISP-Netzwerken: Wie, was, wo, warum?

[mabra]

Hi !

Naja, so merkwürdig ist das bei Kabel BW nicht

Oh, hatte deine Antwort verpaßt. Aber ich hatte deinen ersten Beitrag dazu ja gelesen und verstanden.
Wills aber nicht probieren
VG++Manfred

[mat6937]

Ich habe in iptables versucht alles zu blocken, was nicht vom zugewiesenen Netzwerk stammt,

BTW: Auch mit der "richtigen" broadcast-Adresse, würde dein "border device" an einem KabelBW-Anschluss, die broadcast-Pakete (DHCP und arp) an seinem WAN-Interface immer sehen.

Ich habe z. B. eine externe statische (d. h. nicht per DHCP zugewiesen) IPv4-Adresse von KabelBW (UM) und das WAN-Interface hat die "richtige" broadcast-Adresse. Die broadcast-Pakete (DHCP + arp) sehe ich trotzdem am WAN-Interface.
Auch mit:

Code: Alles auswählen

net.ipv4.conf.all.log_martians = 0

Diese sind ja auch für ff:ff:ff:ff:ff:ff bzw. für 255.255.255.255 bestimmt.

Z. B.:

Code: Alles auswählen

21:08:05.960954 ##:##:##:79:72:## > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    10.217.252.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, hops 1, xid 0x2be95d6b, Flags [Broadcast] (0x8000)
	  Client-IP 95.##.##.##
	  Server-IP 85.216.127.10
	  Gateway-IP 10.217.252.1
	  Client-Ethernet-Address c8:0a:a9:##:##:##
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Server-ID Option 54, length 4: 10.217.252.1
	    Subnet-Mask Option 1, length 4: 255.255.252.0
	    Default-Gateway Option 3, length 4: 95.###.##.1
	    Domain-Name-Server Option 6, length 8: 82.212.62.40,78.42.43.40
	    Router-Discovery Option 31, length 1: Y
	    END Option 255, length 0
	    PAD Option 0, length 0, occurs 25

oder

Code: Alles auswählen

21:15:10.837818 ##:##:##:79:72:## > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 95.###.##.### tell 95.###.##.1, length 46

Lästig ist, dass ein Teil dieser Pakete, dem RX-Traffic (counter) des WAN-Interfaces zugeordnet werden.

[BenutzerGa4gooPh]

@dufty2: Muss man das - oder KANN man das - mit den 3 Angaben, von denen eine redundant und somit fehlerbehaftet ist? Was passiert bei Widersprüchen bezüglich Netzmaske/Broadcastadresse am DHCP-Client wirklich, am DHCP-Client getestet/ausgelesen?

Nachfolgendes ist jetzt nicht völlig ernst gemeint: Ihr mit eurem ollen Debian! Ich habe Cisco und Lancom konfiguriert und nie eine Broadcast-Adresse angeben müssen. Es wäre konfigurierbar gewesen. IP-Adresse des Router-Interfaces und Netzmaske für alles daraus Folgendes war jedoch völlig ausreichend. Widersprüche habe ich selbst nie getestet. Mit meinem Debian Stable bin ich sehr vorsichtig, will nichts wegen Tests für andere kaputtbasten. Wen es interessiert, kann selbst probieren. Cisco ist 10J. her, Lancom allerdings nur 1J.

dufty2, ich denke, du verstehst mich auch ohne Smileys. Na gut, eines:

--------------
Ach und weil ich heute lustig bin - speziell für Manfred: Mache dich schon mal mit den Begriffen "paranoid" und "Aluhut" vertraut. Diese Termini werden im hiesigen Forum meist nicht böse benutzt, eher ironisch, von Vielen auch selbstironisch verwendet. Ich benutze Kopftuch aus Alufolie.
Hast du mal probiert, einen anderen DHCP-Client direkt an das Kabelmodem anzuhängen, z. B. Windows-PC aus LAN? Man wüsste so, ob der Provider wirklich was falsch macht ... . Ansonsten immer die Spekulationen ... .

[mabra]

Hi !

BTW: Auch mit der "richtigen" broadcast-Adresse, würde dein "border device" an einem KabelBW-Anschluss, die broadcast-Pakete (DHCP und arp) an seinem WAN-Interface immer sehen.

Das habe ich in zwanzig Jahren Firmennetzwerk nie gesehen! Der Router ist verpflichtet, solche Broadcasts nicht
weiterzuleiten. Daher stammt auch meine "Vermutung" mit der "großen Bridge". DHCP ist ein Broadcast für LAN. Wir
hatten in der Firma > 50 Standorte in Deutschland - wenn deine Aussage zuträfe, wären wir verreckt ..

Zitat Wikipedia:
Limited Broadcast
Als Ziel wird die IP-Adresse 255.255.255.255 angegeben. Dieses Ziel liegt immer im eigenen lokalen Netz und wird direkt in einen Ethernet-Broadcast umgesetzt. Ein limited broadcast wird von einem Router nicht weitergeleitet.

( https://de.wikipedia.org/wiki/Broadcast )
VG++Manfred

[mat6937]

Der Router ist verpflichtet, solche Broadcasts nicht weiterzuleiten.

Ja schon, aber welcher Router? Entweder es gibt diesen Router bei KabelBW (UM) nicht oder dieser Router ist nicht richtig konfiguriert.

Daher stammt auch meine "Vermutung" mit der "großen Bridge".

Ja, genau so wird es sein.

[mabra]

Hi !
Den Aluhut setze ich mir schon gerne auf. Wer "in the day after" (Snowden) nicht aufpaßt, hat's nicht verstanden - und
das sehe ich leider täglich. Früher war ich auch so ein naiver IT'ler ... In diesem Jobbereich ist die emotionale Dimension
immens - das Wegschauen rettet. Wenn ich also sehe, das Entwickler (Web und andere) schonmal empfehlen, den
Kraken 8.8.8.8 in ihrer Netzwerkkonfiguration zu verwenden, weiß ich wo ich dran bin

@dufty2: Muss man das - oder KANN man das - mit den 3 Angaben, von denen eine redundant und somit fehlerbehaftet ist? Was passiert bei Widersprüchen bezüglich Netzmaske/Broadcastadresse am DHCP-Client wirklich, am DHCP-Client getestet/ausgelesen?

Keine Ahnung - alle mir bekannten Netzwerkstacks machen das auch ohne die Angabe richtig.

Deinen Aussagen zu Desktop-Firewall's (kürzlich) will ich wiedersprechen. Im Wikipedia-Artikel zu "Personal Firewall"
( https://de.wikipedia.org/wiki/Personal_Firewall%20 ) kann man einen Teil (!!) der Infektionsquellen sehen.
iptables sieht NICHT, was im HTTP-Datenstrom oder in den DNS-Request/Response Daten wirklich drinsteckt.
Deswegen ist der verlinkte Artikel leider völlig unzureichend - hat aber ein schickes Bild
Und dann sind wir bei Application-Level-Firewall (wie Squid&Co) - was ein Komplement zum "Desktop-Firewall" sein
sollte, denn beide sind unvollständig. Weiter geht es dann mit den Plattenzugriffen des DNS-Spions, usw. usf.
Applikation-Isolation ist da einwirksames Mittel - zum Glück kommt das nun auch bald in modernere
Paketierungsverfahren in die frei Welt, z.B. "Flatpak", auch heute in heise.de:
( http://www.heise.de/newsticker/meldung/ ... 46482.html )
So wird ein Schuh 'draus.
VG++Manfred

[mabra]

Hi !

Danke für deine Beiträge.
Genau das war aber die Ursache für mein "Unbehagen". Als ich meinen Debian-Router eingerichtet hatte,
hatte ich wenig Ahnung von Debian und noch weniger von Firewalls. Aber ORKs (guter Ätzbegriff für ARPs)
und DHCPs kommen niemals auf meiner LAN-Seite heraus - automatisch !

Viele Grüße,
Manfred

[dufty2]

@dufty2: Muss man das - oder KANN man das - mit den 3 Angaben, von denen eine redundant und somit fehlerbehaftet ist? Was passiert bei Widersprüchen bezüglich Netzmaske/Broadcastadresse am DHCP-Client wirklich, am DHCP-Client getestet/ausgelesen?

Nachfolgendes ist jetzt nicht völlig ernst gemeint: Ihr mit eurem ollen Debian!

Also dieses olle Debian wieder! Macht so komische Broadcast-Sachen! Allerhand das Ganze!


Entgegen dem weit verbreiteten Glauben gibt es tatsächlich Netze welche ohne Broadcast sind, z. B. bei Loopbacks (/32) oder auch Point-to-Points (/31).
Es gibt aber auch Point-to-Points mit /30 oder /29 und bei letzterem kann man dann tatsächlich alle 8 Adressen nutzen.
Sieht man auch an der "lokalen Routing-Tabelle"

# ip route show table local

am Fehlen der 2 entsprechenden broadcast-Einträge ("10.0.0.0" und "10.0.0.255").

Will man aber den "normalen" Broadcast, jenen aber selbst nicht berechnen, geht auch

Code: Alles auswählen

ip addr add 10.0.0.1/24 brd + dev eth0

als Abkürzung für

Code: Alles auswählen

ip addr add 10.0.0.1/24 brd 10.0.0.255 dev eth0

EDIT:
Es geht "brd -" auch, dann ist der Broadcast die 10.0.0.0 (also die untere Grenze).
Hab' ich aber selbst noch nicht benützt

[BenutzerGa4gooPh]

Danke dufty2 für die Erklärungen! Oller Debianer, oller! Duck und abgetaucht.

[mat6937]

Als ich meinen Debian-Router eingerichtet hatte, ...

Der DHCP-Server von KabelBW (UM) sendet ja stündlich in seinem "LAN" per broadcast (d. h. an 255.255.255.255/ff:ff:ff:ff:ff:ff) für jeden DHCP-Client, einen "nicht angeforderten" DHCP-ACK.
Wie geht dein Debian-Router (als DHCP-Client) mit diesem DHCP-ACK um bzw. wie "verwertet" dein Debian-Router (als DHCP-Client), diesen für ihn bestimmten stündlichen DHCP-ACK?

[mabra]

Hi !

Sorry, kann ich dir leider nicht sagen.
Offenbar verwirft mein dhclient die überflüssigen Pakete. Ich habe ihn um einen
Eventhandler erweitert, sodaß immer der letzte Request in einer Textdatei landet.
Der dhclient bei mir sendet in seiner Anforderung auch nicht die Standardproperties:
MTU habe ich z. B. (irgendwann mal) auskommentiert, weil ich immer eine MTU von 576 (!!)
bekam.
Der Erneuerungsinterval, der in den bei ankommenden Paketen steckt, beträgt 50min.
Als ich deine Frage las (~23:30) habe ich schnell mal 'n Tcpdump gestartet und den nun
insgesamt ~30min. laufen lassen. In der Zeit sind 143 Pakete angekommen ... also etwa
4.7 Pakete/m [von s zu m geändert -sorry] !!!!!! Mein Client hat in der Zeit genau zwei Pakete
weggeschickt. Ich habe Tcpdump praktisch nur zählen lassen (nirgend 'reingeschaut).

.......
Wie geht dein Debian-Router (als DHCP-Client) mit diesem DHCP-ACK um bzw. wie "verwertet" dein Debian-Router (als DHCP-Client), diesen für ihn bestimmten stündlichen DHCP-ACK?

Da muss ich passen - es funktioniert scheinbar alles einwandfrei.
Ich habe mal in etwa 24h ~100.000 DHCP Pakete gespeichert - da kommen die
ganzen Geräten mit ihren Firmwareversion und update-urls ...
VG++Manfred