Keine IP Vergabe an Clients

dhcp

#1

Hallo Forum,

Habe den UCS komplett neu aufgesetzt, Netzwerkeinstellungen angepasst für eth0 und eth1, und es funktioniert soweit alles.
Habe während der Installation das Netzwerk manuell eingerichtet mit eth0: 10.0.0.2; Netzmaske: 255.0.0.0; Gateway: 10.0.0.1, DNS: 127.0.0.1

Als alles installiert war, habe ich händisch eth1 angelegt mit der IP:172.27.16.2/24
Mit ucr get gateway kam heraus: 10.0.0.1
Mit ucr set gateway=172.27.16.1 (Router) dann geändert.
ip_forwarding ist aktiviert

Dann alles nochmal neu gestartet, Server kommt ins Internet und updates eingespielt (vorher Lizenzdatei eingepflegt).

Dann im Bereich Domäne->DHCP->Subnet 10.0.0.0/8 (war schon angelegt)->Pool für dyn. Bereich erstellt mit 10.0.1.1 - 10.0.1.31 (erlaube unbekannte Clients, verbiete bekannte Clients)
Einen weiteren Pool angelegt mit dem Bereich 10.0.3.0 - 10.0.3.63 (erlaube bekannte Clients, verbiete unbekannte Clients)

Einen Windows-Rechner gestartet und dieser bekommt eine IP aus dem Pool (hier mit der IP: 10.0.1.9) - in das Internet kommt dieser aber noch nicht. Soweit alles ok. Mit arp -a in der Konsole wurden mir verschiedene Geräte angezeigt (APs, PCs, Drucker, etc. unter anderem auch mein Rechner mit der 10.0.1.9).

Was ich noch nicht herausgefunden habe ist:
Wie kann ich meinen Rechner mit der IP 10.0.1.9 dem Pool 10.0.3.0 zuweisen?
Muss ich das alles per Hand einrichten, also muss ich mir merken, dass ich dem PC mit der MAC-Adresse xy die IP 10.0.3.1 zugewiesen habe? Unter der Rubrik “Geräte” ?

Viele Grüße
Toni
Reply


#4

Einen weiteren Pool angelegt mit dem Bereich 10.0.3.0 - 10.0.3.63 (erlaube bekannte Clients, verbiete unbekannte Clients)

Wenn Sie mehrere Pools auf demselben Subnetz haben, so vergibt der DHCP-Server Adressen nach einem eigenen Schema; z.B. erst alle aus dem 10.0.1.0er, und erst wenn die alle belegt sind, dann die aus dem 10.0.3.0er. Eine Trennung der beiden Bereiche ist nur dann sinnvoll möglich, wenn die dazugehörigen Bereiche auch switchtechnisch getrennt sind (z.B. über Einrichtung unterschiedlicher untagged VLANs auf den switchen und Verwendung mehrerer Netzwerkkarten und -interfaces im Server — der Server hätte dann ein Interface im 10.0.1.0er Netz, ein anderes im 10.0.3.0er, und in jedem davon eine eigene Adresse).

Einen Windows-Rechner gestartet und dieser bekommt eine IP aus dem Pool (hier mit der IP: 10.0.1.9) - in das Internet kommt dieser aber noch nicht.

Natürlich nicht. Der Windows-Rechner ist in einem Netz, das Gateway ins Internet in einem ganz anderen Netz. Sie müssen Routing zwischen beiden Netzen implementieren, potenziell mit NAT beim Router zwischen beiden Netzen, aber nicht zwingend.

Variante 1:

  1. Auf dem Univention-Server wird das Routing aktiviert (z.B. in /etc/sysctl.cond den Wert net.ipv4.ip_forward=1 einkommentieren und mit sysctl -p /etc/sysctl.conf aktivieren; sinnvoller noch in einer eigenen Datei im Unterverzeichnis /etc/sysctl.d/, dann ist’s auch upgradesicher).
  2. DHCP-Server auf dem UCS-Server für die beiden 10er Bereiche so erweitern, dass die 10er IP des UCS-Servers das Default-Gateway und auch der DNS-Server für dieses Netz ist.
  3. Auf dem bereits existierenden Default-Gateway im 172er Netz wird eine Route eingerichtet, die besagt, dass das Netz 10.0.0.0/8 über den UCS-Server, also über 172.27.16.2 erreichbar ist.
  4. UCS-Firewall so anpassen, dass weitergeleitete Pakete vom 10er Netz in Richtung Internet zugelassen werden (und auch die Antworten, versteht sich).

Variante 2:

  1. Auf dem Univention-Server wird das Routing aktiviert (z.B. in /etc/sysctl.cond den Wert net.ipv4.ip_forward=1 einkommentieren und mit sysctl -p /etc/sysctl.conf aktivieren; sinnvoller noch in einer eigenen Datei im Unterverzeichnis /etc/sysctl.d/, dann ist’s auch upgradesicher).
  2. DHCP-Server auf dem UCS-Server für die beiden 10er Bereiche so erweitern, dass die 10er IP des UCS-Servers das Default-Gateway und auch der DNS-Server für dieses Netz ist.
  3. Auf dem Univention-Server NAT aktivieren, sodass alle Pakete vom 10er Netz auf Quelladresse des UCS-Servers im 172er Netz umgeschrieben werden, wenn sie ins Internet gehen sollen.
  4. UCS-Firewall so anpassen, dass weitergeleitete Pakete vom 10er Netz in Richtung Internet zugelassen werden (und auch die Antworten, versteht sich).

Unterschied ist, ob der existierende Router im 172er Netz umkonfiguriert werden muss oder nicht.

Die Firewallanpassungen (bei Variante 1 Punkt 4, bei Variante 2 Punkte 3 und 4) kann man irgendwo in einem Script unterbringen, das beim Booten gestartet wird; falls die Univention-Firewall eingesetzt wird, so z.B. in /etc/security/packetfilter.d/50_local, das genau für solche lokale Anpassungen gedacht ist.

Wie kann ich meinen Rechner mit der IP 10.0.1.9 dem Pool 10.0.3.0 zuweisen?

Indem Sie dem Rechnerobjekt eine statische Adresse aus diesem 10.0.3.0er Bereich zuweisen, als: in der UDM das Rechnerobjekt editieren, dessen MAC-Adresse eintragen, die feste IP aus dem 10.0.3.0er Bereich eintragen, und dann unten bei DHCP die beiden (MAC und IP) verknüpfen.

Aber wie oben geschrieben: aktuell haben Sie keinerlei Trennung der Netze.

Nicht bös gemeint, aber Ihre Fragen zeigen einige grundlegende Misverständnisse oder Wissenslücken, wie Netzwerke im Allgemeinen funktionieren. Ich empfehle, dass Sie sich ein wenig mit Literatur zu den Basistechniken bzgl. Netzwerke, Routing, Firewalling mit Linux beschäftigen.


#5

Vielen Dank für Ihre ausführliche Antwort.
Vieles, was Sie vorschlagen ist mir bekannt auch durch Antworten aus anderen Forenbeiträgen, und war entsprechend umgesetzt (siehe Eintrag oben z.B. “ip_forwarding ist aktiviert”) und mit einem Eintrag in den iptables wird es vervollständigt.

Es ging mir nicht um eine Trennung mittels Vlan oder mehrerer Netzwerkkarten (wie bei der Linuxmuster-Lösung mit ipfire), sondern um einfache Trennung der Bereiche, hier mit Hilfe der Pools (zu sehen bei skolelinux stretch und open school server (leider noch basierend auf sles 11), beide lesen die mac-Adresse eines clients automatisch aus und dann diesen per Knopfdruck einem Pool zuweisen).
Ich dachte, dass das UCS auch solche Funktionen hat und ich sie nur übersehe.

Nur ist der UCS nicht mal eben ein gewöhnliches Debian System, sondern bietet unglaublich viele Einstellungsmöglichkeiten auch durch das Managementsystem.
Natürlich habe ich dann erstmal Fragen und ich lerne den UCS gerade erst kennen.

Aber wenn Ihr “nicht bös gemeint” (eigentlich ist es das doch, sonst hätte man es sich sparen können) Absatz bedeuten soll, dass ich in diesem Forum nichts zu suchen habe, weil ich ihrer Meinung nach keine Ahnung von Netzwerktechnik habe, dann werde ich den UCS und @school weder meiner Schule noch anderen empfehlen.
Denn weitere Hilfe werde ich aufgrund ihrer Bemerkung dann nicht zu erwarten habe (und anderen Kollegen ergeht es vielleicht ebenso).
Ich wusste nicht, dass newbies hier nicht erwünscht sind und meine Anfängerfragen lästig sind.
Tut mir leid, Ihnen (und anderen die das gelesen haben) ihre Zeit geraubt zu haben. Es wird nicht wieder vorkommen.


#6

Huhu,

[quote=“Toni, post:5, topic:6289, full:true”]
Vieles, was Sie vorschlagen ist mir bekannt auch durch Antworten aus anderen Forenbeiträgen, und war entsprechend umgesetzt (siehe Eintrag oben z.B. “ip_forwarding ist aktiviert”) und mit einem Eintrag in den iptables wird es vervollständigt.[/quote]

Funktioniert’s denn jetzt mit der Firewallregel?

Falls nicht, dann posten Sie bitte mal die folgenden Angaben:

  1. Von einem der Clients aus dem 10er Bereich die Ausgabe von ipconfig und route print (sofern’s ein Windows-Client ist; bei einem Linux-Client eher ip address show und ip route show)
  2. Vom UCS-Server die Ausgabe der folgenden Befehle:
  3. cat /proc/sys/net/ipv4/ip_forward
  4. ip route show
  5. iptables -L FORWARD -nv
  6. iptables -t nat -L -nv

Damit sollte dann erkennbar sein, wo es hakt.

[quote]Es ging mir nicht um eine Trennung mittels Vlan oder mehrerer Netzwerkkarten (wie bei der Linuxmuster-Lösung mit ipfire), sondern um einfache Trennung der Bereiche, hier mit Hilfe der Pools (zu sehen bei skolelinux stretch und open school server (leider noch basierend auf sles 11), beide lesen die mac-Adresse eines clients automatisch aus und dann diesen per Knopfdruck einem Pool zuweisen).
Ich dachte, dass das UCS auch solche Funktionen hat und ich sie nur übersehe.[/quote]

Sie meinen eine rein organisatorische Trennung, um anhand der IP-Adresse sehen zu können, wozu der Rechner gehört? Verstehe, ja dafür braucht man keine VLAN-Trennung, wenn’s nicht um Sicherheit geht.

Eine solche »hier ist die Liste der bekannten DHCP-Clients, klick da« gibt es in der Tat nicht. Sie können alle vergebenen Adressen sowohl in der Logdatei /var/log/syslog verfolgen (dort steht auch der Name, den der Client mitgeschickt hat, was die Zuordnung erleichtern dürfte), also auch in der Lease-Datei, in der die aktuellen (und auch die schon abgelaufenen) Leases stehen, /var/lib/dhcp/dhcpd.leases. Das ist wie auf einem Standard-Debian mit DHCP-Server.

Eine feste Zuordnung nehmen Sie dann so vor, wie ich es im ersten Post geschrieben habe; Sie müssen’s direkt am Rechnerobjekt im Univention Directory Manager hinterlegen.

[qute]Aber wenn Ihr “nicht bös gemeint” (eigentlich ist es das doch, sonst hätte man es sich sparen können) Absatz bedeuten soll, dass ich in diesem Forum nichts zu suchen habe, weil ich ihrer Meinung nach keine Ahnung von Netzwerktechnik habe,…[/quote]

Mein Abschnitt war wirklich nicht böse gemeint. Dass er so gewirkt hat, tut mir Leid; das war nicht meine Absicht. Mein Gedanke war, dass die diversen Aspekte rund um Netzwerke und Linux einen großen Komplex bilden und zu groß sind, um sie alle hier ausführlich zu erläutern. Z.B. haben die zwei von mir erwähnten Varianten aufgrund von NAT unterschiedliche Einschränkungen; mit NAT wird man vom 172er Netz nicht in die 10er Netze kommen.

Ihr ursprünglicher Post enthielt halt einige Punkte Ihres zweiten Posts nicht, und bas hab ich dann falsch verstanden.

Natürlich sind Fragen von Neulingen hier erwünscht; das Forum ist für alle Nutzer von UCS da: Anfänger, Langzeitnutzer, Interessenten.

Gruß,
mosu