Hallo.
Heute fiel uns ein sehr seltsames Problem im Zusammenhang mit unserer Umstellung auf 6.1 + VLAN + Subnetting auf. Ich habe mehrere Clients im “Bibliotheks-Subnet” (bei uns 10.30.52.0/24). Diese sind alle in der workstations-Datei eingetragen. Alle Clients erhalten auch ordnungsgemäß via DHCP ihre IP.
Um es nachvollziehbarer zu machen: Zwei VMs innerhalb von Proxmox erhalten 10.30.52.10 und .11 und zwei “echte” Clients an einem L2-Switch erhalten 10.30.52.200 und .201. Das klappt alles via LINBO.
Nun ist es so: Die beiden Clients innerhalb der VM können sich anpingen – aber an die “echte” Hardware komme ich nicht: Der ping geht nicht durch. Auch ein tracepath “verliert sich” und liefert sinngemäß “No Reply”. Zudem zeigt der eine “echte” Ubuntu-Client oben links in der Ecke nicht seinen Namen sondern einfach “no”.
Was kann das sein bzw wo kann ich da suchen? Im Moment vermute ich am ehesten, dass das Problem auf dem Cisco-L3-Switch zu suchen/finden ist. Die beiden “echten” Clients (beide am gleichen L2-Switch angesteckt) können sich übrigens auch nicht gegenseitig anpingen, was alles merkwürdig ist. Ich weiß natürlich, dass diese Beschreibung vage bleibt aber vielleicht ja jemand eine Idee, in welche Richtung man weitersuchen kann…!?
Alle vier Clients kommen übrigens problemlos ins Internet!
Wer hat da eine gute Idee?
Auf dem Server lautet der Eintrag in der subnet-Datei (default):
10.30.52.0/24;10.30.52.254;;;0;0
Ist das bei euch auch so, dass ihr die Cisco-IP im Subnetz (also immer die .254) nicht anpingen könnt? Der Cisco-Switch (bzw jetzt als als Gateway zu betrachten) müsste da doch reagieren, oder? Er antwortet übrigens in jedem Subnetz auf 10.16.1.253 (das im Servernetz liegt). Auf dieser IP antwortet er also…
ist den das “echte” VLAN dieser Rechner auf dem Server auch definiert?
Oder gibt es das erst “ab” dem Cisco?
Ich habe nicht alle realen VLANs auf dem Server selbst schon definiert.
Ist den das “echte” VLAN auf dem Cisco auch dem trunc zum Server hin
definiert?
Was ich “normal” fände, wäre, dass die echten Clients sich pingen können
und die virtuellen untereinander, aber nicht von virtuall zu real und
umgekehrt.
Das mit dem “no”: da würde ich sagen: da wird der Rechnername nciht
gepatched.
Was steht den auf den Realen Clients in der /etc/hosts?
Was steht dort bei den virtuellen Clients?
Wie meinst du das mit den “echten VLANs” bzw welchen Server meinst du jetzt: Den Proxmox oder linuxmuster?
Ich habe auf dem Proxmox-Server ja Zugriff auf bond0.52 – also untagged. Das klappt ja auch.
Vom Proxmox läuft ein LAG (mit allen VLANs) zum Cisco und vom Cisco geht’s dann auf den L2-Switch. Wenn die Verbindung nicht richtig wäre, würden die Clients keine IP erhalten, oder?
Ich fände es übrigens normal, dass sich alle, die in dem gleichen Subnetz unterwegs sind, sich auch sehen/pingen. Warum sollte das anders sein?
Noch ein Nachtrag: Gerade habe ich gesehen, dass auf dem L2-Switch, den ich heute benutzt hatte, IGMP-Snooping aktiviert ist. Kann’s damit zusammenhängen? Oder sollte das (insbesondere bei Subnetting-Betrieb) deaktiviert sein?
Das Problem ist gelöst … ich habe länger gesucht und am Ende festgestellt, dass es an den sehr restriktiven Einstellungen im Cisco-Switch bzgl der ACE/ACL lag.
Wenn man z.B. für ein VLAN (Computerraum) die im Wiki vorgeschlagenen ACE umsetzt, können sich die Clients untereinander nicht mehr anpingen. Sie haben dann NUR noch Zugriff auf’s Servernetz und sonst auf NICHTS anderes – also auch nicht auf den Lehrer-PC im eigenen Raum.
Ich bin nicht sicher, ob das so gewollt ist bzw ob der Netzbrief in BW das wirklich so restriktiv fordert??! Dennoch ist das ein Stolperstein, der ebenfalls mit ins Wiki bzw unter docs.linuxmuster.net aufgenommen werden sollte. Ich habe mich die ganze Zeit gewundert, dass kein ping durchkommt obwohl sonst alles funktioniert.
Erst ein ping auf’s gateway bzw anschließend die Überprüfung der Routen hat mir allmählich gezeigt, wo ich den “Fehler” suchen muss.
Ich weiß nicht, wer von Euch weitere ACEs fuer alle weiteren eingerichteten VLANs eingerichtet hat … bzw ob man das für alle weiteren VLANs mit eigenen Regeln machen muss, damit die gegenseitige Abschottung auf jeden Fall erhalten bleibt. Über weitere Meinungen diesbzgl wäre ich daher dankbar.
Hallo Michael,
da hast du Recht.
Alle Server-bezogenen pädagogischen Funktionen (Schulkonsole, Tauschordner usw) funktionieren weiterhin, aber alle Funktionen, die direkten Kontakt zw. Lehrer-PC und Schüler-PC erfordern (epoptes, vermutlich: MAus, etc…) würden nicht mehr funktionieren.
Ich habs zum Ticket hinzugefügt: Layer3 - subnetting docs incorrect · Issue #95 · linuxmuster-docs/main · GitHub
Grüße, Tobias
Hallo Michael,
ich habe auf dem host Zugriff auf bond0.52 tagged. Das ist vermutlch der Unterschied: Das VLAN ist auf dem host bei mir getagged. Dafür muss natürlich auch der bond/trunk vom L3-switch zum Server VLAN-getagged sein. Wie es dann zu linuxmuster.net und den clients weitergeht kann man wiederum irgendwie festlegen, ich habe dann die Pakete untagged, denke ich.
Grüße, Tobias
Ok! Gut, dass es jetzt dokumentiert ist. Das erspart anderen die Sucharbeit.
Ich weiß ja nicht, wie groß die Gruppe derjenigen ist, die Subnetting bereits umgesetzt hat – doch ich wundere mich, dass sonst niemand (?) von solchen Problemen berichtet hat?!
Um die Lösung ganz konkret zu machen: Es würde reichen, in den ACEs eine weitere Regel zu erstellen:
Zulassen --> 10.(subnet).0 mit Netmask 0.0.0.255
Dann wäre der Zugriff auf die anderen Rechner innerhalb des Subnetzes erlaubt. Das stellt in den Computerräumen kein Problem dar. Im Lehrernetz imho auch nicht.
Ich stelle mir das in etwa so vor. Mit der zusätzlichen Regel dürfte es keine Probleme geben doch der Zugriff innerhalb des eigenen Subnetzes ist möglich/erlaubt.
