19
Raspi - Statische Routen mit dhcpcd fest eintragen
Hallo allerseits.
Ich stehe mit meinem Raspberry vor einer Herausforderung und bin bisher bei Google nicht wirklich fündig geworden.
Vorab ein kleines Diagramm:
Der Mikrotik ist der INet-Router und hängt mit einem Interface im INet (die IP-Adresse spielt keine Rolle), mit dem anderen im Transfernetz (IP-Adresse 172.23.254.1). Zudem ist er u.a. der DNS für alle Clients in den lokalen Netzen.
Der Core Switch routet den ganzen internen Kram (der Einfachheit halber mal nur als ein Netzwerk "Lokales Netz" dargestellt) und hängt ebenfalls mit einem Interface im Transfernetz (IP-Adresse 172.23.254.2).
Der Pi hängt als einziger Host mit im Transfernetz und macht dort u.a. den Upstrem-DNS (PiHole) für den Mikrotik (IP-Adresse 172.23.254.200)
Soweit so gut - das Routing funktioniert im Grunde, aber:
Der Pi hat als Default GW die IP des Core Switch. Damit ist er aus den lokalen Netzen erreichbar (das ist erforderlich!). Wenn aber Pakete ins INet gehen, sieht man z.B. bei einem Ping auf eine externe Adresse, dass die Pakete sinnloserweise umgeleitet werden.
Ist klar, dass das so ist. Ist aber doof.
Ist das Default GW die IP-Adresse des Mikrotik besteht das gleiche Problem, nur eben wenn ich einen Ping auf eine Adresse im lokalen Netz absetze. Zudem komme ich von innen nicht mehr auf den Pi.
Was gut zu funktionieren scheint, ist das Default GW auf die IP-Adresse des Mikrotik zu setzen und für die lokalen Netze auf dem Pi statische Routen anzulegen. Problem: Wie mache ich diese permanent, also so, dass sie auch nach einem Reboot wieder (oder noch) da sind?
System: Rasperry3, Debian 11 bullseye 32bit, IP-Adresse ist statisch konfiguriert und es wird dhcpcd genutzt.
Bin für jegliche Anregung dankbar.
VG mhard666
Ich stehe mit meinem Raspberry vor einer Herausforderung und bin bisher bei Google nicht wirklich fündig geworden.
Vorab ein kleines Diagramm:
Der Mikrotik ist der INet-Router und hängt mit einem Interface im INet (die IP-Adresse spielt keine Rolle), mit dem anderen im Transfernetz (IP-Adresse 172.23.254.1). Zudem ist er u.a. der DNS für alle Clients in den lokalen Netzen.
Der Core Switch routet den ganzen internen Kram (der Einfachheit halber mal nur als ein Netzwerk "Lokales Netz" dargestellt) und hängt ebenfalls mit einem Interface im Transfernetz (IP-Adresse 172.23.254.2).
Der Pi hängt als einziger Host mit im Transfernetz und macht dort u.a. den Upstrem-DNS (PiHole) für den Mikrotik (IP-Adresse 172.23.254.200)
Soweit so gut - das Routing funktioniert im Grunde, aber:
Der Pi hat als Default GW die IP des Core Switch. Damit ist er aus den lokalen Netzen erreichbar (das ist erforderlich!). Wenn aber Pakete ins INet gehen, sieht man z.B. bei einem Ping auf eine externe Adresse, dass die Pakete sinnloserweise umgeleitet werden.
pi@raspos01:~ $ ping google.de
PING google.de (142.250.181.195) 56(84) bytes of data.
From 172.23.254.2 (172.23.254.2) icmp_seq=1 Redirect Network(New nexthop: mtk-rb951g.mhard.home (172.23.254.1))
64 bytes from ham02s21-in-f3.1e100.net (142.250.181.195): icmp_seq=1 ttl=56 time=26.4 ms
64 bytes from ham02s21-in-f3.1e100.net (142.250.181.195): icmp_seq=2 ttl=56 time=25.1 ms
64 bytes from ham02s21-in-f3.1e100.net (142.250.181.195): icmp_seq=3 ttl=56 time=22.9 msIst klar, dass das so ist. Ist aber doof.
Ist das Default GW die IP-Adresse des Mikrotik besteht das gleiche Problem, nur eben wenn ich einen Ping auf eine Adresse im lokalen Netz absetze. Zudem komme ich von innen nicht mehr auf den Pi.
Was gut zu funktionieren scheint, ist das Default GW auf die IP-Adresse des Mikrotik zu setzen und für die lokalen Netze auf dem Pi statische Routen anzulegen. Problem: Wie mache ich diese permanent, also so, dass sie auch nach einem Reboot wieder (oder noch) da sind?
System: Rasperry3, Debian 11 bullseye 32bit, IP-Adresse ist statisch konfiguriert und es wird dhcpcd genutzt.
Bin für jegliche Anregung dankbar.
VG mhard666
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3033284509
Url: https://administrator.de/contentid/3033284509
Ausgedruckt am: 05.11.2024 um 11:11 Uhr
19 Kommentare
Neuester Kommentar
Die Lösung ist relativ einfach...
Lege dir mit dem nano Editor eine Datei dhcpcd.exit-hook an im Verzeichnis /etc
Dort konfigurierst du dann deine statischen Routen ala:
/usr/sbin/ip route add 10.1.1.0/24 via 192.168.2.100 dev eth0
/usr/sbin/ip route add 172.16.250.0/24 via 192.168.2.100 dev eth0
/usr/sbin/ip route add 192.168.88.0/24 via 192.168.2.100 dev eth0
Dann mit systemctl restart dhcpcd den DHCP Client neu starten und mit ip r kannst du dann deine neue Routing Tabelle checken.
Vermutlich liegt es aber an der falschen Routing Einrichtung.
Aber auch wenn du das Gateway des RasPi auf den Core legst sollte es sauber und auch ohne Umweg funktionieren.
Wichtig ist dafür eine korrekte ICMP Redirect (Typ 5) Konfig.
https://de.wikipedia.org/wiki/Internet_Control_Message_Protocol
Vermutlich erlaubt dein Core keine ICMP Redirects oder ist dort in dessen Konfig fälschlicherweise deaktiviert.
Das wäre dann in deinem Falles des RasPi Gateways auf den Core schlecht, denn in einem sauber gerouteten Netz würde der Core dem RasPi immer einen Redirect senden so das der dann direkt den MT anspricht OHNE Umweg.
Will sagen das mit der ICMP Konfig am Core etwas falsch ist. Oder ggf. auch die Redirects im RasPi deaktiviert sind. (Wird alles in der /etc/sysctl.conf definiert)
So oder so ist die Grundursache aber dein nicht ganz sauberes Routing im Netz.
Lege dir mit dem nano Editor eine Datei dhcpcd.exit-hook an im Verzeichnis /etc
Dort konfigurierst du dann deine statischen Routen ala:
/usr/sbin/ip route add 10.1.1.0/24 via 192.168.2.100 dev eth0
/usr/sbin/ip route add 172.16.250.0/24 via 192.168.2.100 dev eth0
/usr/sbin/ip route add 192.168.88.0/24 via 192.168.2.100 dev eth0
Dann mit systemctl restart dhcpcd den DHCP Client neu starten und mit ip r kannst du dann deine neue Routing Tabelle checken.
Vermutlich liegt es aber an der falschen Routing Einrichtung.
- Der Core Router hat nur eine einzige Default Route auf den MT
- Der MT routet alle lokalen LANs am Core mit einer Summary Route an den Core
- Der RasPi hat das Default Gateway auf den MT!!
Aber auch wenn du das Gateway des RasPi auf den Core legst sollte es sauber und auch ohne Umweg funktionieren.
Wichtig ist dafür eine korrekte ICMP Redirect (Typ 5) Konfig.
https://de.wikipedia.org/wiki/Internet_Control_Message_Protocol
Vermutlich erlaubt dein Core keine ICMP Redirects oder ist dort in dessen Konfig fälschlicherweise deaktiviert.
Das wäre dann in deinem Falles des RasPi Gateways auf den Core schlecht, denn in einem sauber gerouteten Netz würde der Core dem RasPi immer einen Redirect senden so das der dann direkt den MT anspricht OHNE Umweg.
Will sagen das mit der ICMP Konfig am Core etwas falsch ist. Oder ggf. auch die Redirects im RasPi deaktiviert sind. (Wird alles in der /etc/sysctl.conf definiert)
So oder so ist die Grundursache aber dein nicht ganz sauberes Routing im Netz.
2
Die sauberste Lösung wäre, für den Pi ein separates Netz vorzusehen. Das könntest du z.B. auf dem Mikrotik einrichten.
Damit hat der Pi nur noch ein Gateway und Routing-Einstellungen nimmst du auf den Netzwerkgeräten vor.
Ist dann auch für die Zukunft wartungsarmer, weil du hier keine einzelnen Hosts anpassen musst, sondern dich auf die Routinginstanzen in deinem Netz beschränken kannst.
Falls du es trotzdem mit Linuxmitteln lösen möchtest, könntest du in /etc/network/interfaces unter das entsprechende Interface up ip route add ZIELNETZ via NEXTHOP dev INTERFACEhinzufügen. Allerdings versteh ich nicht, was du mit
Damit hat der Pi nur noch ein Gateway und Routing-Einstellungen nimmst du auf den Netzwerkgeräten vor.
Ist dann auch für die Zukunft wartungsarmer, weil du hier keine einzelnen Hosts anpassen musst, sondern dich auf die Routinginstanzen in deinem Netz beschränken kannst.
Falls du es trotzdem mit Linuxmitteln lösen möchtest, könntest du in /etc/network/interfaces unter das entsprechende Interface up ip route add ZIELNETZ via NEXTHOP dev INTERFACEhinzufügen. Allerdings versteh ich nicht, was du mit
IP-Adresse ist statisch konfiguriert und es wird dhcpcd genutzt.
genau meinst. Ist die Adresse nun statisch konfiguriert, oder bekommt der Pi die Adresse per DHCP?
Nein, das ist Unsinn. Der RasPi kann dort problemlos bleiben wo er ist.
Da muss man ja nicht nachdenken. Nach 5 Min. ist Kollege @aqui eh schon zur Stelle!
Nachfrage @mhard666: Vielleicht verstehe ich das Konzept ja falsch, aber für mich sieht es nach "warum einfach, wenn es auch schwierig geht" aus. Warum lässt Du den Core-Switch routen? Ein Switch ist ein Switch und ein Router ist ein Router. Vom Layer3-VLAN-Setup mal abgesehen, vielleicht. Wenn Du das gesamte Routing im MT erledigst, stellt sich Dein Problem erst gar nicht.
Davon abgesehen könnte man auch bei Deiner Konfig m.E. die Routen für den Pi im MT anlegen. Ist zwar ein Hop mehr, dafür viel transparenter.
Viele Grüße, commodity
P.S.:
Ich stimme dem Kollegen @awesomenik prinzipiell zu. Bei dem aktuellen Setup hat der TO ein Routing-Dreieck, das ist prinzipiell keine saubere Lösung.
P.P.S:
Nachfrage @mhard666: Vielleicht verstehe ich das Konzept ja falsch, aber für mich sieht es nach "warum einfach, wenn es auch schwierig geht" aus. Warum lässt Du den Core-Switch routen? Ein Switch ist ein Switch und ein Router ist ein Router. Vom Layer3-VLAN-Setup mal abgesehen, vielleicht. Wenn Du das gesamte Routing im MT erledigst, stellt sich Dein Problem erst gar nicht.
Davon abgesehen könnte man auch bei Deiner Konfig m.E. die Routen für den Pi im MT anlegen. Ist zwar ein Hop mehr, dafür viel transparenter.
Viele Grüße, commodity
P.S.:
Ich stimme dem Kollegen @awesomenik prinzipiell zu. Bei dem aktuellen Setup hat der TO ein Routing-Dreieck, das ist prinzipiell keine saubere Lösung.
P.P.S:
Allerdings versteh ich nicht, was du mit
Das meint DHCP-ReservationIP-Adresse ist statisch konfiguriert und es wird dhcpcd genutzt.
genau meinst. Ist die Adresse nun statisch konfiguriert, oder bekommt der Pi die Adresse per DHCP?
Ist aber in seinem Falle bzw. Design kontraproduktiv, denn dann müssten beim Routing innerhalb der lokalen LANs alle lokalen LANs dann am Core "Switch" zum MT und wieder zurück, was den Traffic auf dem Link unnötig in die Höhe treibt und das Netz belastet (Performance).
Zudem entkoppelt er so den lokalen LAN Traffic vom Internet Routing auch ein gängiges und gutes Konzept was das Problem des Single Point of Failure reduziert.
Das was der TO da macht ist also ein klassisches L3 Konzept wie oben beschrieben und als Design auch Best Practise. Er hat also nichts falsch gemacht sondern muss nur sein Setup etwas "tunen" 😉
Zudem entkoppelt er so den lokalen LAN Traffic vom Internet Routing auch ein gängiges und gutes Konzept was das Problem des Single Point of Failure reduziert.
Das was der TO da macht ist also ein klassisches L3 Konzept wie oben beschrieben und als Design auch Best Practise. Er hat also nichts falsch gemacht sondern muss nur sein Setup etwas "tunen" 😉
Ja, danke Dir. Für VLANs verstehe ich das. Das geht aus der Zeichnung aber nicht hervor. Da sehe ich auch nur ein lokales Netz. Die Beschreibung lässt es vielleicht erahnen. Da steht ja was von "lokalen Netzen".
Auch dann stellt sich mir aber die Frage, warum der Pi nicht innerhalb des lokalen Netzwerkes steht. Ggf. in einem eigenen Segment.
Viele Grüße, commodity
Auch dann stellt sich mir aber die Frage, warum der Pi nicht innerhalb des lokalen Netzwerkes steht. Ggf. in einem eigenen Segment.
Viele Grüße, commodity
Das Transfernetz ist ja quasi auch ein lokales Netz wenn man es nüchtern betrachtet. Das ist sicher nicht der Punkt.
Die eigentliche Frage ist warum das Gateway so gewählt wurde und warum vermutlich ICMP Redirects totgelegt wurden in dem Netz was da natürlich kontraproduktiv ist.
Sieht so ein bisschen danach das der RasPi hier einen PiHole oder Adguard DNS Filter beherbergt. In dem Falle macht das Transfernetz als Position dann durchaus Sinn.
Letztlich kann das alles aber wohl nur der TO selber beantworten.
Die eigentliche Frage ist warum das Gateway so gewählt wurde und warum vermutlich ICMP Redirects totgelegt wurden in dem Netz was da natürlich kontraproduktiv ist.
Sieht so ein bisschen danach das der RasPi hier einen PiHole oder Adguard DNS Filter beherbergt. In dem Falle macht das Transfernetz als Position dann durchaus Sinn.
Letztlich kann das alles aber wohl nur der TO selber beantworten.
Das ist sicher nicht der Punkt.
vielleicht doch. Steht der Pi hinter dem Core, fällt das Dreiecksproblem weg. Der Pi ist lt. TO ein PiHole, ja. Ich mach das mit dem PiHole so, dass ich ihn an einen Trunk-Port des Switches hänge und ihn auf allen VLANs Anfragen beantworten lasse. Spricht etwas dagegen?Viele Grüße, commodity
Steht der Pi hinter dem Core, fällt das Dreiecksproblem weg.
Da hast du Recht, das ist die Besonderheit des "Transfer" Segments. Aber nicht ursächlich. Denn genau dafür hat der TCP/IP Standard ja das ICMP Steuerprotokoll und dort ganz besonders den Redirect! 
In dem Design ist es also essentiell das zu aktivieren, denn dann würde es niemals zu diesen "Umwegen" kommen. Redirects sind genau dafür da so etwas zu verhindern.
Das wäre also das wichtigste ToDo des TO, denn auch mit einer neuen Definition des MTs als Default Gateway würde es die Problematik nicht vollständig lösen, denn für Routing in die lokalen Netze hätte man wieder "Umwege".
Das richtige ICMP Handling ist also schon die beste Lösung hier. Leider ja keinerlei Feedback vom TO selber.
OK. Mal abgesehen von Ping, Du schreibst, so sollte es eingerichtet werden:
Nun schickt das lokale LAN eine Anfrage an den Pi. Dieser antwortet, das allerdings über den MT, da er das lokale LAN nicht kennt. Der MT soll das prinzipiell an den Core-Switch leiten und der Core-Switch dann zustellen. Das macht der MT aber nicht, weil der Traffic für ihn "invalid" ist, denn die Connection wurde ja nicht über ihn eingeleitet.
Ich habe die Thematik in Arzpraxen, wenn der Konnektor zur Telematik im selben Netz steht wie der MT.
Wenn SPI für den Traffic nach lokal aktiviert bleiben soll, wird es also ohne Route vom Pi oder ein anderes Netzwerksegment für diesen nicht funktionieren.
Viele Grüße, commodity
- Der Core Router hat nur eine einzige Default Route auf den MT
- Der MT routet alle lokalen LANs am Core mit einer Summary Route an den Core
- Der RasPi hat das Default Gateway auf den MT!!
Nun schickt das lokale LAN eine Anfrage an den Pi. Dieser antwortet, das allerdings über den MT, da er das lokale LAN nicht kennt. Der MT soll das prinzipiell an den Core-Switch leiten und der Core-Switch dann zustellen. Das macht der MT aber nicht, weil der Traffic für ihn "invalid" ist, denn die Connection wurde ja nicht über ihn eingeleitet.
Ich habe die Thematik in Arzpraxen, wenn der Konnektor zur Telematik im selben Netz steht wie der MT.
Wenn SPI für den Traffic nach lokal aktiviert bleiben soll, wird es also ohne Route vom Pi oder ein anderes Netzwerksegment für diesen nicht funktionieren.
Viele Grüße, commodity
Nun schickt das lokale LAN eine Anfrage an den Pi.
Das wäre zu einfach beschrieben... Richtig ist:- Endgerät im lokalen LAN will den PI erreichen und merkt anderes IP Netz
- Endgerät ARPt nach dem Default Gateway (Core) und schickt Paket dahin
- Core erkennt an der Destination IP das das Pi Netz direkt an ihm dran ist und ARPt nach der Ip Adresse
- Pi empfängt Paket, verarbeitet es und schickt die Rückantwort auf dem gleichen Weg
Anders sieht es aus wenn der Pi (Def. Gate auf Core) ins Internet will...
- Pi schickt Paket zu Admin.de und muss sein Gateway ARPen (Core)
- Core erkennt das das gemeinsame Default Gateway im gleichen Netz hängt und schickt einen ICMP Redirect mit Zieladresse des MT an den Pi
- Pi ARPt dann aufgrund des Redirects den MT direkt und schickt sein Paket (und auch alle folgenden) direkt und ohne "Umwege" an den MT zu Admin.de
Redirects sind z.B. auch an Windows Rechern per Default in der Firewall deaktiviert was dann immer zu solchen unnötigen und Performance fressenden "Durchlauferhitzer" Umwegen in diesen Netzen führt.
wird es also ohne Route vom Pi oder ein anderes Netzwerksegment für diesen nicht funktionieren.
Nein! Normal ist das nicht so wenn man es richtig routet. Routen sollen IMMER die Router und niemals die Endgeräte. Eine der goldenen Netzwerker Regeln. 😉Pi empfängt Paket, verarbeitet es und schickt die Rückantwort auf dem gleichen Weg
Warum das? Für den Pi ist das Paket, das von hinter dem Core kommt doch nicht lokal. Geht die Antwort dann nicht an sein Standard-Gateway, das ja der MT ist? Wo ist mein Denkfehler?Viele Grüße, commodity
Warum das? Für den Pi ist das Paket, das von hinter dem Core kommt doch nicht lokal.
Da hast du Recht. Die Rückantwort geht dann auch wieder an den Core Router und der forwardet das ans Zielsegment.Aus den lokalen LAN Segmenten am Core kann es also niemals "Umwege" geben zum Pi.
Anders wenn der Pi auf Netze geht die NICHT in den Netzen am Core liegen sondern woanders und der Pi hat den Core als Default Gateway. Das ist ja genau der Punkt des TOs.
Hier einmal ein Wireshark Trace in exakt dem gleichen Umfeld der das Netzwerk Verhalten visualisiert.
Core ist ein Cisco Layer 3 Switch (.88.254) und Internet Router ein Mikrotik (.88.1). Pi hat die .88.33. Wireshark filtert auf ICMP.
Mahlzeit,
Danke erstmal an alle für den Input - besonders an @aqui für seine (wie immer) schnellen und ausführlichen Antworten.
Das Routing schaue ich mir auf jeden Fall noch mal an, ggf. komme ich noch mal mit genaueren Angaben rüber. Das Thema ICMP Redirects ist mir zugegebenermaßen neu.
@commodity
Der Core routet aus einem relativ einfachen Grund: Weil der das schneller, günstiger und leiser kann als der MT (bzw. irgendein anderer MT). Klingt banal, aber nachdem ich eine Zeit lang auf "kleinen" MTs, immerhin mit 1Gbit Interfaces, versucht habe Inter-VLAN-Routing, wie in @aqui's Tutorial aufzubauen und die Übertragungsrate zwischen den VLANs nicht mal ansatzweise 1Gbit erreicht hat, habe ich das aufgegeben und ehrlich gesagt auch nie wieder mit einem MT versucht.
Wie schon geschrieben ist der Pi der Upstream-DNS für den MT. Hier läuft PiHole und PiHole akzeptiert per Default nur Anfragen aus dem gleichen Subnetz. Kann man ändern, es wird aber aus Sicherheitsgründen davon abgeraten. Darum steht der Pi im selben Subnetz wie der DNS auf dem MT.
Ja, da steht exemplarisch nur ein "lokales Netz" es sind aber tatsächlich mehrere. Mit nur einem lokalen Netz muss man diesen ganzen Aufwand selbstverständlich nicht betreiben.
@awesomenik
Der Pi hat eine statische IP. Diese ist auf dem Gerät festgelegt und wird nicht über eine Reservierung zugewiesen. Früher hat man die Netzwerkinterfaces in der /etc/network/interfaces konfiguriert, heute nutzen manche Distributionen (wie Debian 11 für den Raspberry Pi) dhcpcd. Eine statische IP-Adresse wird dann in der /etc/dhcpcd.conf konfiguriert.
Zum Thema eigenes Subnetz für den Pi s.o.
VG mhard666
Danke erstmal an alle für den Input - besonders an @aqui für seine (wie immer) schnellen und ausführlichen Antworten.
Das Routing schaue ich mir auf jeden Fall noch mal an, ggf. komme ich noch mal mit genaueren Angaben rüber. Das Thema ICMP Redirects ist mir zugegebenermaßen neu.
@commodity
Der Core routet aus einem relativ einfachen Grund: Weil der das schneller, günstiger und leiser kann als der MT (bzw. irgendein anderer MT). Klingt banal, aber nachdem ich eine Zeit lang auf "kleinen" MTs, immerhin mit 1Gbit Interfaces, versucht habe Inter-VLAN-Routing, wie in @aqui's Tutorial aufzubauen und die Übertragungsrate zwischen den VLANs nicht mal ansatzweise 1Gbit erreicht hat, habe ich das aufgegeben und ehrlich gesagt auch nie wieder mit einem MT versucht.
Wie schon geschrieben ist der Pi der Upstream-DNS für den MT. Hier läuft PiHole und PiHole akzeptiert per Default nur Anfragen aus dem gleichen Subnetz. Kann man ändern, es wird aber aus Sicherheitsgründen davon abgeraten. Darum steht der Pi im selben Subnetz wie der DNS auf dem MT.
Ja, da steht exemplarisch nur ein "lokales Netz" es sind aber tatsächlich mehrere. Mit nur einem lokalen Netz muss man diesen ganzen Aufwand selbstverständlich nicht betreiben.
@awesomenik
Der Pi hat eine statische IP. Diese ist auf dem Gerät festgelegt und wird nicht über eine Reservierung zugewiesen. Früher hat man die Netzwerkinterfaces in der /etc/network/interfaces konfiguriert, heute nutzen manche Distributionen (wie Debian 11 für den Raspberry Pi) dhcpcd. Eine statische IP-Adresse wird dann in der /etc/dhcpcd.conf konfiguriert.
Zum Thema eigenes Subnetz für den Pi s.o.
VG mhard666
Hier läuft PiHole und PiHole akzeptiert per Default nur Anfragen aus dem gleichen Subnetz.
Zumindestens im Default tut er das aber nicht. Der beantwortet auch DNS Anfragen aus allen Subnetzen wenn man es nicht einschränkt.Heisser Tip:
Sieht dir mal AdGuard an. Ist deutlich besser und fortschrittlicher als der etwas in die Jahre gekommene PiHole und erlaubt zudem noch das Blocking sehr vieler ungewollter Apps im Netz über ein bequemes GUI. Ebenso Safe Browsing und Po... und Gewalt Filter.
Ein weiterer Pluspunkt ist zudem das es DoH und DoT out of the Box supportet.
Wenn's das denn nun war bitte deinen Thread dann auch als erledigt markieren.
war es noch nicht ganz Wollte darauf noch kurz eingehen:
Ein L3-Setup ist natürlich im Betrieb elegant und ökonomisch, dafür kann man sich dann mit ACLs und ihren Grenzen rumschlagen, während man beim Routing sauber firewallen kann und nur ein Gerät intensiv konfiguriert. Aber das hängt ja von den jeweiligen Anforderungen ab.
Viele Grüße, commodity
Wollte darauf noch kurz eingehen:Zitat von @mhard666:
Der Core routet aus einem relativ einfachen Grund: Weil der das schneller, günstiger und leiser kann als der MT (bzw. irgendein anderer MT). Klingt banal, aber nachdem ich eine Zeit lang auf "kleinen" MTs, immerhin mit 1Gbit Interfaces, versucht habe Inter-VLAN-Routing, wie in @aqui's Tutorial aufzubauen und die Übertragungsrate zwischen den VLANs nicht mal ansatzweise 1Gbit erreicht hat, habe ich das aufgegeben und ehrlich gesagt auch nie wieder mit einem MT versucht. Danke für Die Erläuterung, auch zu den lokalen Netzen. Anmerkung zum MT (mehr für die Nachwelt, Du hast es ja anders gelöst):
Das Problem vieler MT-Neulinge ist, dass sie mit einem hEX und begrenztem KnowHow bzw. Einarbeitungsbereitschaft anfangen und sich am Ende wundern, dass ein 40 EUR Router nicht Gigabit routet. Die "normalen" Routerboards, also 4011, 5009 aufwärts, wahrscheinlich auch der 3011, routen locker 1 GB aufwärts. Ich habe u.a. ein 5009, das hat sich bei 2 Gbit/s (mehr hab ich nicht getestet) seelig ausgeschlafen. In diesen Fällen ist es praktisch immer die Konfiguration oder die HW ist ungenügend ausgesucht. Ein hEX hat zwar 1 Gbit Netzwerk, kann das aber nicht routen (wohl aber bridgen), weil der Prozessor das nicht schafft. Bis man zur (für sich) "richtigen" Konfiguration kommt, dauert es aber und braucht einigen Schmerz und Schweiß. Ob man sich das antun möchte, muss man für sich entscheiden.Der Core routet aus einem relativ einfachen Grund: Weil der das schneller, günstiger und leiser kann als der MT (bzw. irgendein anderer MT). Klingt banal, aber nachdem ich eine Zeit lang auf "kleinen" MTs, immerhin mit 1Gbit Interfaces, versucht habe Inter-VLAN-Routing, wie in @aqui's Tutorial aufzubauen und die Übertragungsrate zwischen den VLANs nicht mal ansatzweise 1Gbit erreicht hat, habe ich das aufgegeben und ehrlich gesagt auch nie wieder mit einem MT versucht. Danke für Die Erläuterung, auch zu den lokalen Netzen. Anmerkung zum MT (mehr für die Nachwelt, Du hast es ja anders gelöst):
Ein L3-Setup ist natürlich im Betrieb elegant und ökonomisch, dafür kann man sich dann mit ACLs und ihren Grenzen rumschlagen, während man beim Routing sauber firewallen kann und nur ein Gerät intensiv konfiguriert. Aber das hängt ja von den jeweiligen Anforderungen ab.
Viele Grüße, commodity
1
Hallo nochmal,
leider komme ich aktuell nicht so oft zum "bauen". Deswegen hat's etwas gedauert mit der Rückmeldung...
@aqui
AdGuard habe ich schon auf dem Plan mir mal anzuschauen... die Zeit halt...
Die Routen sind gesetzt, wie in Deinem Tutorial beschrieben, allerdings hatte ich auf dem MT ein VLAN ungünstig konfiguriert. Hab da damals bei der Konfiguration was probiert, was dann so doch nicht verwendet wurde (oder so nicht funktioniert hat). Hab das rausgeschmissen und es scheint jetzt soweit zu funktionieren.
@commodity
Ja, man muss halt abwägen, wo man wieviel Scmerz und Schweiß reinstecken will
VG mhard666
leider komme ich aktuell nicht so oft zum "bauen". Deswegen hat's etwas gedauert mit der Rückmeldung...
@aqui
AdGuard habe ich schon auf dem Plan mir mal anzuschauen... die Zeit halt...
Die Routen sind gesetzt, wie in Deinem Tutorial beschrieben, allerdings hatte ich auf dem MT ein VLAN ungünstig konfiguriert. Hab da damals bei der Konfiguration was probiert, was dann so doch nicht verwendet wurde (oder so nicht funktioniert hat). Hab das rausgeschmissen und es scheint jetzt soweit zu funktionieren.
@commodity
Ja, man muss halt abwägen, wo man wieviel Scmerz und Schweiß reinstecken will
VG mhard666
Da hast Du sowas von Recht!
Ich fand den adguard übrigens nicht so überzeugend, dass ich das kommerzielle Produkt dem Gemeinschaftsprodukt vorziehen würde. Bin wieder zum Pi-Hole zurück.
Viele Grüße, commodity
Ich fand den adguard übrigens nicht so überzeugend, dass ich das kommerzielle Produkt dem Gemeinschaftsprodukt vorziehen würde. Bin wieder zum Pi-Hole zurück.
Viele Grüße, commodity
