isc-dhcpd-server - korrekte Einstellung von Subnetz und Netzmaske, jedoch zugeordnete IP- und Netzmaske (ifconfig) unterschiedlich

460
rbaleksandar

Ein Kollege von mir versucht derzeit, ein Problem mit einer Raspberry Pi 3-Maschine (neuester Rasbian) zu beheben. Das isc-dhcpd-serverläuft ohne Probleme bei einem anderen ähnlichen Setup. In /etc/dhcp/dhcpd.confbeiden Systemen ist derselbe Inhalt enthalten, einschließlich der subnetKonfiguration, in der eindeutig angegeben ist, dass 192.168.100.x mit netmask255.255.255.0 verwendet werden muss:

# example.org domain and domain name servers configuration # ... ddns-update style none;  option subnet-mask 255.255.255.0; option broadcast-address 192.168.100.255; option domain-name "project.test";  subnet 192.168.100.0 netmask 255.255.255.0 { range 192.168.100.2 192.168.100.253; } 

Der DHCP-Server weist jedoch aus irgendeinem Grund automatisch eine IP-Adresse aus einem völlig anderen Netzwerk zu (beachten Sie, dass der Raspberry Pi nicht an einen Router usw. angeschlossen ist und die Umgebung keine Verbindung zu anderen Geräten oder zum Internet hat:

root@rpi:~$ ifconfig eth0 169.254.221.127 netmask 255.255.0.0 broadcast 169.254.255.255 lo ... 

Ich bin nicht mit dem DHCP-Server und der gesamten Konfiguration vertraut, die erforderlich ist, damit er ordnungsgemäß funktioniert. Ich vermisse wahrscheinlich etwas Offensichtliches. Gibt es einen anderen Ort, an dem diese Konfiguration geändert werden muss?

Rekursives Suchen im Inneren /etc

grep -rnw * -e "169.254.*" 

(auf beiden Maschinen) zwei Übereinstimmungen zurückgegeben - eine in gai.conf und eine in Netzwerken . Die gai.conf habe ich noch nie gehört. Was die Netzwerke angeht, so ist dies die link-localEinstellung. Wie es scheint, ist dies auf vielen Systemen ein Standardwert (einschließlich meiner eigenen virtuellen Maschinen, auf denen Xubuntu 16.04 ausgeführt wird).

0
Die angezeigte Adresse wurde vom DHCP nicht angegeben. Dies ist ein Fallback, den der Host sich selbst zuweist (Hosts im selben LAN können mit diesen kommunizieren, versuchen Sie es mit Top-Ping-Tests). Wenn Sie das verstanden haben, bedeutet dies, dass Ihr DHCP-Setup aus irgendeinem Grund nicht funktioniert. Überprüfen Sie die Protokolle und verwenden Sie tcpdump, um zu sehen, was los ist. Raouf M. Bencheraiet vor 6 Jahren 0

1 Antwort auf die Frage

1
grawity

Diese Adresse wird nicht per DHCP zugewiesen. Der 169.254.0.0/16Bereich bezieht sich auf "zeroconf" -Adressen - link-local-Adressen, die vom System selbst ausgewählt werden. Diese werden meistens als Fallback verwendet, wenn DHCP nicht verfügbar ist. Wenn Sie diese Adresse sehen, aber keine reguläre Adresse, kann dies einige Dinge bedeuten:

  • Ihr DHCP-Client konnte keine Lease erhalten und hat aufgegeben.

  • Oder Ihr Netzwerkprofil ist tatsächlich auf "local-only" (in NetworkManager oder ähnliches) eingestellt.

Wenn Ihr DHCP - Client und Server wie immer, nicht zu tun, was sie sollen, untersuchen, was sie werden tun - überprüfen Systemprotokolle, um ein Paket - Capture - Tool (Wireshark / tcpdump) verwenden, und so weiter.

  1. Läuft der dhcpd-Daemon?
  2. Welchen DHCP-Client verwendet das RPI? Läuft es? Können Sie es im verbose oder debug Modus ausführen?
  3. Sendet der Client ein DHCPDISCOVER und antwortet der Server mit einem DHCPOFFER?
  4. Sendet der Client ein DHCPREQUEST und antwortet der Server mit einem DHCPACK?

Die /etc/networksDatei ist nicht wichtig. Der einzige Zweck (ähnlich wie / etc / hosts) besteht darin, den Netzwerkpräfixen Anzeigenamen zuzuweisen, z. B. beim Ausführen des routeBefehls. In ähnlicher Weise /etc/gai.confenthält nur Prioritäten für die DNS - Lookup Ergebnisse Sortieren - nichts mit DHCP zu tun.

@rbaleksandar: Obwohl Grawity es technisch richtig gesagt hat ("Fallback"), lass es mich vielleicht noch deutlicher erklären. Wenn ein DHCP-Client versucht, Informationen von einem DHCP-Client abzurufen, und ein Fehler auftritt, verwendet er normalerweise den "Link Local" -Adressbereich, der mit 169.254 beginnt. Extrem häufig auftretende Ursachen können ein Problem mit dem DHCP-Server sein (Prüfpunkt Nr. 1 aus der Antwort von grawity) oder nur ein anderes Netzwerkproblem, das den DHCP-Verkehr auf die Weise verhindert, wie Sie dies wahrscheinlich glauben. TOOGAM vor 6 Jahren 0
Okay, nachdem ich die Sachen ein wenig gelesen hatte, stellte ich fest, dass "rpi" in Punkt zwei von @ grawitys Antwort auf das in der Frage erwähnte "Raspberry Pi 3" bezog. TOOGAM vor 6 Jahren 0
Beachten Sie, dass Zeroconf-Adressen perfekt verwendbar sind, insbesondere in einem isolierten Netzwerk wie dem OP-Netzwerk. Die Verwendung von Zeroconf-Adressen erspart Ihnen die Mühe, einen DHCP-Server einzurichten und Clients für dessen Verwendung zu konfigurieren. Johan Myréen vor 6 Jahren 0