2
Warum braucht mein Debian mit mehreren Interfaces mehrere Routing-Tabellen?
Hallo zusammen,
ich spanne über eine MT-Router mehrere VLANs auf, die in der MT-Firewall ausreichend getrennt sind. Das klappt seit einigen Jahren ganz gut.
Jetzt möchte ich gerne auf einer Debian-Maschine Avahi als MDNS-Reflektor einsetzen.
Nach der Anschaffung eines Bonjour-fähigen Druckers, der in einem anderen VLAN ist als die Clients, habe ich Bind mit DNS-SD-Einträgen so eingerichtet, dass auch das iPhone diesen gefunden hat.
Leider musste ich nach dem Upgrade auf iOS17 aber feststellen, dass nun keine DNS-SD-Querys mehr gestellt werden, so dass der Drucker nur per mDNS gefunden wird.
Mit ein bisschen Fummelei läuft der Reflektor jetzt auch problemlos - doch frage ich mich noch, ob diese Fummelei wirklich nötig war oder ob ich nur eine Trivialität übersehen habe?
Der Server hat vier Interfaces, die jeweils in einem anderen VLAN stecken. Alle vier erhalten ihre Konfiguration per DHCP. Damit hat der Reflektor schnell funktioniert, doch waren andere Services auf der Maschine nicht mehr ansprechbar. Auch nachdem ich diese jeweils an ein Interface gebunden hatte, änderte sich das nicht.
Geholfen hat letztendlich, für jedes der Interfaces eine neue Routing-Tabelle anzulegen und diese jeweils mit einer Regel für das in dem VLAN verwaltete Netz und einer Default-Route zum Gateway zu bestücken, hier am Beispiel für ein VLAN_200, zu welchem der Adressbereich 192.168.200.0/24 gehört:
Anschließend habe ich noch eine Routing-Regel pro VLAN angelegt, die dafür sorgt, dass Pakete aus dem jeweiligen VLAN gemäß der jeweiligen Routing-Tabelle bearbeitet werden:
Danach lief es wie gewünscht: ein Dienst, der an das VLAN_200 gebunden war, war auch nur da zu erreichen - aber problemfrei.
Was mich jetzt nur wundert:
Vielleicht könnt Ihr mir hier helfen, mein 90%-Verständnis dessen, was ich da gebastelt habe, auf 100% zu erhöhen...
Danke!
Viele Grüße
Michael
ich spanne über eine MT-Router mehrere VLANs auf, die in der MT-Firewall ausreichend getrennt sind. Das klappt seit einigen Jahren ganz gut.
Jetzt möchte ich gerne auf einer Debian-Maschine Avahi als MDNS-Reflektor einsetzen.
Nach der Anschaffung eines Bonjour-fähigen Druckers, der in einem anderen VLAN ist als die Clients, habe ich Bind mit DNS-SD-Einträgen so eingerichtet, dass auch das iPhone diesen gefunden hat.
Leider musste ich nach dem Upgrade auf iOS17 aber feststellen, dass nun keine DNS-SD-Querys mehr gestellt werden, so dass der Drucker nur per mDNS gefunden wird.
Mit ein bisschen Fummelei läuft der Reflektor jetzt auch problemlos - doch frage ich mich noch, ob diese Fummelei wirklich nötig war oder ob ich nur eine Trivialität übersehen habe?
Der Server hat vier Interfaces, die jeweils in einem anderen VLAN stecken. Alle vier erhalten ihre Konfiguration per DHCP. Damit hat der Reflektor schnell funktioniert, doch waren andere Services auf der Maschine nicht mehr ansprechbar. Auch nachdem ich diese jeweils an ein Interface gebunden hatte, änderte sich das nicht.
Geholfen hat letztendlich, für jedes der Interfaces eine neue Routing-Tabelle anzulegen und diese jeweils mit einer Regel für das in dem VLAN verwaltete Netz und einer Default-Route zum Gateway zu bestücken, hier am Beispiel für ein VLAN_200, zu welchem der Adressbereich 192.168.200.0/24 gehört:
ip route add 192.168.200.0/24 dev $IFACE src $IP_DES_SERVERS_IM_200_NETZ table VLAN_200
ip route add default via 192.168.200.1 table VLAN_200Anschließend habe ich noch eine Routing-Regel pro VLAN angelegt, die dafür sorgt, dass Pakete aus dem jeweiligen VLAN gemäß der jeweiligen Routing-Tabelle bearbeitet werden:
ip rule add from $IP_DES_SERVERS_IM_200_NETZ table VLAN_200Danach lief es wie gewünscht: ein Dienst, der an das VLAN_200 gebunden war, war auch nur da zu erreichen - aber problemfrei.
Was mich jetzt nur wundert:
- war das wirklich nötig, oder wäre es einfacher gegangen?
- gibt das "from" in der "ip rule" nicht die Quell-Adresse des Pakets an? Müsste hier dann nicht "192.168.200.0/24" stehen, statt der IP, die der Server im VLAN_200 hat? Trotzdem klappt es.
Vielleicht könnt Ihr mir hier helfen, mein 90%-Verständnis dessen, was ich da gebastelt habe, auf 100% zu erhöhen...
Danke!
Viele Grüße
Michael
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: 2137933953
Url: https://administrator.de/contentid/2137933953
Ausgedruckt am: 17.11.2024 um 15:11 Uhr
2 Kommentare
Neuester Kommentar
Hi.
Braucht dein Host eigentlich nicht.. .
... denn anhand der IP-Adressen der Schnittstelle. weiß der Host ja, in welchen Netzen nebst Subnetz (/24 z.B.) er ist..
Aber: eine auf dem Host installiierte Software erwartet ggf. weiterrn Infos - das hängt aber eben von der Softwarr ab ...
.. . auch wenn das m.E. eher ein Programmiermangel ist ...
Braucht dein Host eigentlich nicht.. .
... denn anhand der IP-Adressen der Schnittstelle. weiß der Host ja, in welchen Netzen nebst Subnetz (/24 z.B.) er ist..
Aber: eine auf dem Host installiierte Software erwartet ggf. weiterrn Infos - das hängt aber eben von der Softwarr ab ...
.. . auch wenn das m.E. eher ein Programmiermangel ist ...
Hallo!
Sowas hatte ich auch erwartet. Daher habe ich eben auf einer Testmaschine nochmal etwas rumprobiert. Kaum hatte ich die o.g. Regeln und Routen entfernt, brach eine bestehende SSH-Verbindung ab. Dann habe ich weiter geschaut und festgestellt: der Übeltäter war DHCP.
Durch DHCP wurden zu jedem neuen Interface jeweils netzspezifische Routen zur main-table hinzugefügt:
192.168.200.0/24 => über das Interface zu VLAN_200
Offensichtlich sind davon selbst bestehende TCP-Verbindungen betroffen: Daten kommen aus VLAN_200 per Mikrotik auf VLAN_100 rein, werden aber über VLAN_200 beantwortet.
Entferne ich diese Regeln, klappen SSHd (und andere Dienste) problemlos - solange es nicht UDP ist.
Bei UDP gibt es nicht die bestehende Verbindung, sondern die Antwort wird neu erzeugt. Damit greifen die Routing-Regeln. Soll eine UDP-Antwort an einen Client im selben VLAN_200 gehen, wird ohne die Regeln in table main immer eine Gateway-Verbindung versucht, da ja als Default-Route das Gateway auf dem Router eingetragen ist, der sich an der Stelle aber überflüssig vorkommt (warum soll er eine Antwort einer Maschine aus VLAN_200 an einen Client in VLAN_200 routen?).
Anders ausgedrückt, scheine ich zwei Optionen zu haben:
Zitat von @MirkoKR:
Braucht dein Host eigentlich nicht.. .
... denn anhand der IP-Adressen der Schnittstelle. weiß der Host ja, in welchen Netzen nebst Subnetz (/24 z.B.) er ist..
Braucht dein Host eigentlich nicht.. .
... denn anhand der IP-Adressen der Schnittstelle. weiß der Host ja, in welchen Netzen nebst Subnetz (/24 z.B.) er ist..
Sowas hatte ich auch erwartet. Daher habe ich eben auf einer Testmaschine nochmal etwas rumprobiert. Kaum hatte ich die o.g. Regeln und Routen entfernt, brach eine bestehende SSH-Verbindung ab. Dann habe ich weiter geschaut und festgestellt: der Übeltäter war DHCP.
Durch DHCP wurden zu jedem neuen Interface jeweils netzspezifische Routen zur main-table hinzugefügt:
192.168.200.0/24 => über das Interface zu VLAN_200
Offensichtlich sind davon selbst bestehende TCP-Verbindungen betroffen: Daten kommen aus VLAN_200 per Mikrotik auf VLAN_100 rein, werden aber über VLAN_200 beantwortet.
Entferne ich diese Regeln, klappen SSHd (und andere Dienste) problemlos - solange es nicht UDP ist.
Bei UDP gibt es nicht die bestehende Verbindung, sondern die Antwort wird neu erzeugt. Damit greifen die Routing-Regeln. Soll eine UDP-Antwort an einen Client im selben VLAN_200 gehen, wird ohne die Regeln in table main immer eine Gateway-Verbindung versucht, da ja als Default-Route das Gateway auf dem Router eingetragen ist, der sich an der Stelle aber überflüssig vorkommt (warum soll er eine Antwort einer Maschine aus VLAN_200 an einen Client in VLAN_200 routen?).
Anders ausgedrückt, scheine ich zwei Optionen zu haben:
- obiges Regelwerk, damit der Server auf allen Interfaces kommunizieren kann
- Regeln einführen, die die durch DHCP frisch eingerichteten Default-Routen wieder entfernen, den Server ebenfalls auf allen Interfaces kommunizieren lassen - aber immer nur VLAN übergreifend.
