PC aus Subnetz kann Opis nicht erreichen (peadml Linux 6.0)

[mabauer]

Hallo,
wir setzen an unserer Schule die paedml-Linux 6.0 ein. In dieser Lösung ist ein Opsi-Server, ein Linux-Server und eine Firewall auf einem ESXi integriert.
Die paedml sieht nur max 200 Clients bzw 200 IP-Geräte vor. Das ist uns zu wenig. Deshalb haben wir eine weiteres Subnetz (10.128.0.0/9) mit einem L3-Switch hinzugefügt. In dem „Server-Subnetz“ (10.1.0.0/24) sind keine Clients eingebunden (Übersicht siehe Anhang).

Die Routen auf dem Server, der Firewall und dem Opsi-Server habe ich gesetzt. Am Switch habe ich Routing entsprechend konfiguriert. Das hat auch auf Anhieb gut funktioniert.

Leider haben wir mit dieser Konfiguration noch ein Problem. Nicht alle Clients können im Bootvorgang den Opsi erreichen. Das Bedeutet, das eine Softwareverteilung so nicht möglich ist.

Ich möchte das Problem an einem Beispiel eines Computerraums beschreiben:
Dieser Raum ist mit 16 Schüler-PCs (IP-Adressen 10.134.0.1 - .16) und einem Lehrer-PC (IP: 10.134.0.30) ausgestattet.
Die PCs mit der Adresse 10.134.0.1, .2 und .30 können den Opsi nicht erreichen. Somit ist eine Installation des Betriebssystems und der entsprechender Software mit Hilfe des Opsi nicht möglich. Die Rechneraufnahme funktioniert, die Installation hingegen bricht bei der Kontaktierung des Opsi ab (siehe Bild im Anhang (2)). Bei allen anderen Clients im Raum funktioniert die Verbindung zum Opsi und somit auch die Softwareverteilung.

Die Routingtabelle des Opsi ist i.O. (siehe Anhang (3))

Werden die verschiedenen Clients vom Opsi gepingt ergeben sich zwei unterschiedliche Verhaltensweisen:

a) Ein Ping vom Opsi an die Geräte die normal funktionieren (IP .3 - .16), wird direkt an die Clients gesendet. (siehe Anhang (4))

b) Ein Ping an eines der Geräte die den Opsi nicht erreichen können, erfolgt ein Redirect über die Firewall 10.1.0.11 (siehe Anhang (5))

Die Anbindung erfolgt über den selben Switch, die Switchports sind nicht unterschiedlich Konfiguriert, die Rechner zeigen anfänglich das selbe boot-Verhalten und die Clients bekommen vom DHCP die richtigen IP-Adress-Konfigurationen zugewiesen. Aus meiner Sicht unterschieden sich nur die unterschiedlichen Kommunikationspfade vom Opsi zu den Clients.

Über einen Tipp würde ich mich sehr freuen
Vielen Dank.
LG
Matze
https://dl.dropboxusercontent.com/u/895 ... rungen.pdf

[d.oertel]

Hi,

Ich habe das ganze nach opsi@school verschoben da paedML hier hin passt.
Die Anfrage ist sehr gut dokumentiert (Lob).
Leider hängt sie nur sehr indirekt mit opsi zusammen sondern ist wohl ein Netzwerk bzw. Firewall Problem.

Wenn ich das richtig verstehe, müsste die Kommunikation für den Bereich 10.134.0.x immer über die Firewall gehen.
Diese scheint sich an dieser Stelle aber unterschiedlich zu Verhalten.
Mein nächster Blick würde also der Firewallkonfiguration gelten.
Schon mal den paedML Support konsultiert ?

gruß
d.oertel

[mabauer]

Hi,
erstmal Danke für die Rückmeldung.
Den Support kann ich nicht kontaktieren, weil eine Netzerweiterung durch einen Router oder L3-Switch zwar vorgesehen ist, aber vom Support ausgeschlossen ist.
Das hat nichts mit der Firewall zu tun. Der Opis kennt den direkten Pfad (über den L3-Switch) nicht und versendet deshalb seine Rückantworten über das Gateway (10.1.0.11). Das Gateway kennt den Pfad zum Ziel-PC und stellt dann das Paket an den Zeil-PC zu.
Hier nochmals ein Traceroute vom Opis zu zwei unterschiedlichen PCs in einem PC-Raum:

Code: Alles auswählen

root@backup:~# traceroute 10.134.0.3
traceroute to 10.134.0.3 (10.134.0.3), 30 hops max, 60 byte packets
 1  10.1.0.10 (10.1.0.10)  0.603 ms  1.598 ms  1.796 ms
 2  g600-pc03.paedml-linux.lokal (10.134.0.3)  0.961 ms  0.324 ms  0.467 ms

root@backup:~# traceroute 10.134.0.2
traceroute to 10.134.0.2 (10.134.0.2), 30 hops max, 60 byte packets
 1  firewall.paedml-linux.lokal (10.1.0.11)  0.387 ms  0.317 ms  0.288 ms
 2  firewall.paedml-linux.lokal (10.1.0.11)  0.335 ms !<5-1>  0.328 ms !<5-1>
0.343 ms !<5-1>
root@backup:~#

Das selbe nochmals von den Clients zum Opis, was ohne Probleme funktioniert:

Code: Alles auswählen

Client mit der IP 10.134.0.3:
C:\Users\winadmin>tracert 10.1.0.2
Routenverfolgung zu backup.paedml-linux.lokal [10.1.0.2] über maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms 10.128.0.1
2 <1 ms <1 ms <1 ms backup.paedml-linux.lokal [10.1.0.2]
Ablaufverfolgung beendet.
C:\Users\winadmin>

Client mit der IP 10.134.0.2
C:\Users\winadmin>tracert 10.1.0.2
Routenverfolgung zu backup.paedml-linux.loka1 [10.1.0.2] über maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms 10.128.0.1
2 <1 ms <1 ms <1 ms backup.paedm1-linux.1okal [10.1.0.2]
Ablaufverfolgung beendet.
C:\Users\winadmin>

Mein Problem ist es nun, dass eben in einem PC-Raum 13 PCs funktionieren und 3 PCs eben nicht.
Über Anregungen, Hilfestellungen oder Tipps würde ich mich tierisch freuen.
LG
Matze

[wolfbardo]

Hallo,

wenn ich das ganze richtig sehe, wird das opsi-Bootimage vom Client gezogen, Netz usw. sind ok aber der opsiserver wird über die 4441 nicht erreicht.

Dann sollte man sich im opsi-client per ssh einloggen können (user root passwort linux123)

und die Bootimage log aus /tmp/log einsehen können bzw hier bereitstellen können.

Möglicherweise hilft auf dem Client auch das master.py abzuschiessen und erneut aufzurufen.

Welche Bootimage version wird verwendet? (evtl hilft das neue Bootimage aus 4.0.5)

Gruss
Bardo Wolf

[mabauer]

Hi wolfbardo,
vielen Dank für Deine Rückmeldung!
Ich habe jetzt gleich Unterricht und kann i.M. nur etwas zu der verwendeten Version sagen:
Wir verwenden: 4.0.5.1-6
Die log-Datei stelle ich spätestens am Di Mittag zur Verfügung.
Nochmals Danke.
LG Matze