Keine Antwort von UCS an DHCP-Relay

german

#1

Hallo,

auch nach langem Testen und Probieren bekomme ich ein Problem leider nicht gelöst. Zuvor jedoch einige Eckdaten.

Das Netzwerk besteht aus 3 Standorten, verbunden via routed VPN. (Beispieldaten: 192.168.1.0/24, 192.168.2.0/24 und 192.168.3.0/24) (VPN-Netz=192.168.123.0/24)

Der UCS steht in 192.168.3.0/24 und die Gateways der anderen beiden Netze leiten DHCP-Requests aus dem eigenen Netz an die UCS-IP weiter.
TCPDUMP auf dem UCS bestätigen auch den Eingang der weitergeleiteten Anfrage:

20:10:09.909287 IP 192.168.123.6.bootps > UCS.bootps: BOOTP/DHCP, Request from 08:00:27:f5:f3:e9 (oui Unknown), length 306

…/var/log/daemon.log sagt aber bei einer Anfrage aus z.B. 192.168.1.0/24 :
(letzte Netz-IP=Gateway mit DHCP-Forwarder)

UCS dhcpd: DHCPDISCOVER from 08:00:27:f5:f3:e9 via 192.168.1.254: unknown network segment

Im UCS habe ich für das 1er und 2er Netz ein Shared-Network sowie ein Shared-Subnet eingerichtet und für die betreffende MAC einen statischen Eintrag angelegt.
Auch unter Netzwerke habe ich alle 3 angelegt. Auch ein Test mit einem reinen Subnet blieb erfolglos.

Ich hoffe, jemand kann mir hierbei auf die Sprünge helfen.


Über DHCP falsche IP
#2

Datei öffnen “/etc/dhcp/dhcpd.conf”,

Bei folgende Zeile das “#” entfernen:

ldap-debug-file "/var/log/dhcp-ldap-startup.log";

Speichern, dhcp neu starten:

/etc/init.d/univention-dhcp restart

Inhalt der Datei “/var/log/dhcp-ldap-startup.log” posten.

lG


DHCP: Kein Gateway für Android-Geräte
#3

Hier die Ausgabe (anonymisiert):

root@UCS:~# cat /var/log/dhcp-ldap-startup.log #DHCP Service shared-network "3er-Netz.local" { subnet 192.168.3.0 netmask 255.255.255.0 { option broadcast-address 192.168.3.255; option routers 192.168.3.254; option domain-name "3er-Netz.local"; option domain-name-servers 192.168.3.229; max-lease-time 7200; default-lease-time 7200; authoritative; ddns-updates on; do-forward-updates true; } } shared-network "2er-Netz.local" { subnet 192.168.2.0 netmask 255.255.255.0 { option broadcast-address 192.168.2.255; option routers 192.168.2.254; option domain-name "2er-Netz.local"; option domain-name-servers 192.168.3.229; max-lease-time 7200; default-lease-time 7200; authoritative; ddns-updates on; do-forward-updates true; } } shared-network "1ner-Netz.local" { subnet 192.168.1.0 netmask 255.255.255.0 { option broadcast-address 192.168.1.255; option routers 192.168.1.254; option domain-name "1ner-Netz.local"; option domain-name-servers 192.168.3.229; max-lease-time 7200; default-lease-time 7200; authoritative; ddns-updates on; do-forward-updates true; } } shared-network "VPN-Netz.local" { subnet 192.168.123.0 netmask 255.255.255.0 { option broadcast-address 192.168.123.255; } }

Das VPN-Netz habe ich nur zu Testzwecken mit aufgenommen, da die DHCP-Anfragen gemäß TCPDUMP aus diesem Netz kommen. Hat aber leider auch nicht geholfen.


#4

Ich konnte das Problem auf der Seite vom UCS lösen.
Anscheinen betrachtet der dhcpd die LDAP-Einträge im Bereich Netzwerke.
Ich hatte dort die 3 verschiedenen Netzwerke angelegt, auch wenn der UCS nur ein Interface im eigenen Netz hat.

Der DHCP hat sich wohl nur das erste Netz rangezogen, und die Requests kamen eben nicht aus diesem.
Nun habe ich die 3 Netzwerke entfernt und ein Zusammengefasstes hinzugefügt (192.168.0.0/16) und nun vergibt der dhcpd endlich OFFER.

Zwar klappt mein gesamtes Konstrukt immer noch nicht, aber nun liegt das Problem an einer anderen Stelle. Der UCS jedoch macht jetzt, was er soll.