Zugriffe von Kunde zu Kunde

Zitat von kbr

muß das Gateway hier doch eine Art proxy-arp machen. Da kann man sich schon fragen, warum und wozu?

Ja, so sieht es aus.

Es ist aber irgendwo auch unerheblich:

Wenn du einen Nachbar-Router an einem anderen Kundenanschluss (= Punkt-zu-Punkt-Verbindung zwischen Kundenrouter und BNG) am selben BNG, an dem auch dein Router hängt, erreichen willst, muss dein Router das IP-Paket in einen Ethernet-Frame mit der MAC-Zieladresse des Gateways verpacken. Die Proxy-ARP-Funktion erspart deinem Router dabei die Arbeit, zuvor noch die MAC-Adresse des Gateways aus dessen IP-Gateway-Adresse aufzulösen (sofern nicht im ARP-Cache) - ist insofern sogar von Vorteil.

Nachtrag:

Sorry - hier die bessere Antwort: Dem Gateway bleibt auch nichts anderes üblich, als Proxy-ARP zu machen, wenn es die WAN-Adresse mit der Netzmaske /20 zuweist und so die Illusion erzeugt, man befände sich mit seinem WAN-Anschluss im Netz 100.123.96.0/20 (100.123.96.1-100.123.111.254). Somit interpretiert jeder Router einen Nachbar-Router im selben "Netz" so, als könne er ihn direkt erreichen. Er wird dann nur einen ARP-Request für die Nachbaradresse absetzen, den der Nachbarrouter aber nicht beantworten kann, da er de facto eben doch nicht "benachbart" (also via Ethernet-Broadcast), sondern nur über das Gateway erreichbar ist. Deshalb muss das Gateway den ARP-Request via Proxy-ARP mit seiner MAC-Adresse beantworten.

Nachtrag2:

Zur (naheliegenden) Frage: Wieso wird eine Netzmaske /20 vegeben?

Meine Antwort: Formell und der physischen Realität von Punkt-zu-Punkt-Verbindungen zwischen Kundenrouter und Gateway entsprechend, müsste das Gateway die IPv4-WAN-Adresse mit der Maske /31 zu weisen. Die jeweils zweite Adresse würde dann das Gateway selbst innerhalb dieser Punkt-zu-Punkt-Verbindung adressieren. Das wäre aber eine riesige Adressverschwendung, denn dann könnte man nur den halben 100.64.0.0/10-Adress-Space für Kundenrouter nutzen, die andere Hälfte ginge für die Adressierung der Gateways drauf.

Indem man hier einen /20 zuweist, braucht man für alle Kundenrouter in diesem Präfix (hier: 100.123.96.0/20) hingegen nur eine Gateway-Adresse (hier: 100.123.96.1)

Ergibt doch Sinn, oder?

Zitat von kbr

Da kann man sich schon fragen, warum und wozu?

Um das hier zu verhindern:

Das wird halt besonders gefährlich, wenn man hier von einigen "Experten" liest, dass sie ein Netzwerk-Kabel vom LAN Anschluss ihres Routers zum Modem vor dem Router ziehen, um Diagnose-Daten auszulesen. Damit stellt man nämlich eine Verbindung auf Schicht 2 zum Provider her. Würde der das dann nicht blocken, passiert das, was im Heise Artikel beschrieben ist.

Unabhängig davon landen die Daten im Netz des Providers. Das würde ich auch nicht wollen.

Übrigens: Es gibt Anbieter, die öffentliche IP-Adressen im DG Netz anbieten. Technisch machen die nichts anderes, als die Daten der öffentlichen IP auf die CGNAT IP des Kunden zu routen.

Er müsste die Anfrage aber auf dem L2 forwarden, was wohl von den OLTs blockiert werden würde.

Dann würde aber auch die Kommunikation zwischen den Anschlüssen nicht mehr funktionieren - auch nicht mit öffentlichen IPv6 Adressen. Das dürfte kaum im Interesse der DG Kunden sein.

Falls das nicht klar geworden ist: Die Kommunikationsmöglichkeit der Anschlüsse untereinander ist ein Feature, kein Bug. Spätestens mit öffentlichen IPv6 Adressen sollte das selbstverständlich sein. Bei CGNAT Adressen klappt das zwar nur DG-intern, aber warum sollte es da anders sein? Um auch das noch mal ganz deutlich zu sagen: CGNAT ist kein Sicherheits-Feature!

Zitat von frank_m

Dann würde aber auch die Kommunikation zwischen den Anschlüssen nicht mehr funktionieren - auch nicht mit öffentlichen IPv6 Adressen. Das dürfte kaum im Interesse der DG Kunden sein.

Falls das nicht klar geworden ist: Die Kommunikationsmöglichkeit der Anschlüsse untereinander ist ein Feature, kein Bug. Spätestens mit öffentlichen IPv6 Adressen sollte das selbstverständlich sein. Bei CGNAT Adressen klappt das zwar nur DG-intern, aber warum sollte es da anders sein? Um auch das noch mal ganz deutlich zu sagen: CGNAT ist kein Sicherheits-Feature!

Da musst du aber zwischen einer geswitchten und einer gerouteten Verbindung unterscheiden. Du bezahlst deinen ISP für eine L3 Verbindung in die Welt. Das schließt natürlich L3 Verbindungen zu anderen Kunden ein. Du bezahlst ihn nicht, dass du mit deinem Nachbarn in einem gemeinsamen L2 Segment sitzt.

Weiss nicht, solange ich nicht den L2 Traffic meiner Nachbarn vorsaetzlich umlenken/kapern kann, wo ist das Problem?

L2 Traffic zwischen den Teilnehmern ist ungewollt, von dem das damals ausging kann ich dir aber nicht sagen. Ob es da Vorgeben seitens BNetzA/BSI gab, unternehmenseigene Regeln, oder nur der Konsens unter den technischen Fachplanern war.

Also, wenn die Kundenrouter an einem BNG tatsächlich untereinander via L2 direkt erreichbar wären, gäbe es eine Fülle von Angriffsszenarien (eben via ARP-Spoofing genau das: "den L2 Traffic meiner Nachbarn vorsaetzlich umlenken/kapern" oder ein paar DHCP-Angiffe) - will man nicht.

Zitat von ::1

(eben via ARP-Spoofing genau das: "den L2 Traffic meiner Nachbarn vorsaetzlich umlenken/kapern" oder ein paar DHCP-Angiffe)

Ja, aber wenn das unterbunden ist, sehe ich jetzt kein Riesenproblem, aber ich akzeptiere auch, dass das ganze meist wenig sinnvoll waere und verstehe wenn man unter Fachplanern einig ist, dass so etwas zu vermeiden sei.

Zitat von pufferueberlauf

Ja, aber wenn das unterbunden ist,

Eben, man muss es aktiv unterbinden - gute Switches bieten dafür eine Reihe von Konfigurationsoptionen. Wäre doch aber Extra-Aufwand, der vermeidbar ist, indem man die L3-Trennung der einzelnen Kundenrouter-Anbindungen aufrecht erhält.

Wir lehnen uns in dieser Diskussion ohnehin weit aus dem Fenster, weil wir die Effekte dem beobachteten Augenschein nach versuchen zu erklären und zu bewerten. Wie so eine BNG-Implementierung bei DG genau aussieht, wissen wir nicht. Moderne Architekturen basieren heutzutage bspw. auf EVPN/VXLAN und so ein BNG wird vermutlich redundant als Cluster ausgelegt sein. Wir beobachten dabei nur das Verhalten des virtuellen "Overlays".

Die "neuen" BNGs bzw. Standorte der Telekom werden mit White-Label Hardware und SUSE-Linux und Micro-Service Architektur aufgebaut. Gleichzeitig findet eine Konzentration der Standorte statt. Dies hatte ich vor 1-2 Jahren schon mal geschrieben, hier nur nochmals als Erinnerung.

Wie die Implementierung bei DG vorgenommen ist, kann ich nicht sagen.