Weiter: 4.6 DSL - DSL Hoch: 4. Pakete Zurück: 4.4 DHCP_CLIENT - Dynamic
Mit der optionalen Variable OPT_HOSTS kann die Konfiguration von Hostname deaktiviert werden!
Es sollten alle Rechner im LAN beschrieben werden - mit IP-Adresse, Namen, Aliasnamen und evtl. Mac-Adressen für die dhcp-Konfiguration . Dazu setzt man zunächst die Anzahl der Rechner mit der Variablen HOST_N.
Hinweis: Seit Version 3.4.0 wird der Eintrag für den Router aus den Angaben in der <config>/base.txt generiert. Sollen zusätzliche Aliasnamen aufgenommen werden, siehe auch HOSTNAME_ALIAS_N.
Anschließend werden mit den Attributen die Eigenschaften des Hostes definiert. Dabei sind einige Attribute Pflicht, wie z.B. IP-Adresse und Name, die anderen optional, d.h. man kann, aber man muß sie nicht spezifizieren.
In der Beispiel-Datei sind 4 Rechner konfiguriert - nämlich die PCs ``client1'', ``client2'', ``client3'' und ``client4''.
HOST_1_NAME='client1' # 1st host: ip and name
HOST_1_IP4='192.168.6.1'
Aliasnamen müssen mit kompletter Domain angegeben werden.
Die MAC-Adresse ist optional und ist nur dann relevant, wenn fli4l zusätzlich als DHCP-Server eingesetzt wird. Dies wird in der Beschreibung zum optionalen Programmpaket ``OPT_DHCP'' erklärt, siehe unten. Ohne Einsatz als DHCP-Server sind lediglich die IP-Adresse, der Name des Rechners und eventuell Aliasnamen einzusetzen. Die MAC-Adresse ist eine 48-Bit-Adresse und besteht aus 6 Hex-Werten, welche durch einen Doppelpunkt voneinander getrennt werden, z.B.
HOST_2_MAC='de:ad:af:fe:07:19'
Hinweis: Wird fli4l um das IPv6-Paket ergänzt, brauchen keine IPv6-Adressen hinterlegt zu werden, wenn gleichzeitig die MAC-Adressen der Hosts vorliegen, weil das IPv6-Paket dann die IPv6-Adressen automatisch berechnet (modifiziertes EUI-64). Natürlich kann man aber den Automatismus unterbinden und feste IPv6-Adressen vorgeben, wenn man dies wünscht.
Um den DNS-Server zu aktivieren ist die Variable OPT_DNS mit `yes` zu belegen.
Werden im LAN keine Windows-Rechner verwendet oder ist bereits ein DNS-Server vorhanden, kann man OPT_DNS auf `no' setzen und den Rest in diesem Abschnitt übergehen.
Im Zweifel immer (Standard-Einstellung): OPT_DNS='yes'
Wenn Sie OPT_DNS='yes' gewählt haben, können Sie mit Hilfe von
DNS_LISTEN_N die Anzahl, und mit DNS_LISTEN_1 bis
DNS_LISTEN_N lokale IPs angeben, auf denen dnsmasq DNS-Anfragen
annehmen darf. Sollten Sie bei DNS_LISTEN_N eine 0
eingetragen haben, beantwortet dnsmasq DNS-Anfragen auf allen lokalen
IPs.
An dieser Stelle dürfen nur IPs von existierenden Schnittstellen
(ethernet, wlan ...) verwendet werden, es kommt sonst zu Warnmeldungen
beim Start des Routers. Alternativ ist nun möglich hier auch ALIAS-Namen
zu verwenden, z.B. IP_NET_1_IPADDR
Für alle hier angegebenen Adressen werden bei PF_INPUT_ACCEPT_DEF='yes' und/oder PF6_INPUT_ACCEPT_DEF='yes' entsprechende ACCEPT-Regeln in der INPUT-Kette der Firewall erzeugt. Im Falle DNS_LISTEN='0' werden ebenfalls Regeln erzeugt, die den DNS-Zugriff auf allen konfigurierten Schnittstellen erlauben.
Wichtig: Falls der DNS-Server auf zur Laufzeit dynamisch hinzugefügten
Schnittstellen horchen soll, etwa auf Netzwerk-Schnittstellen von
VPN-Tunneln, sollten Sie dieses Array leer lassen, da andernfalls der
DNS-Server nicht auf DNS-Anfragen antworten wird, die über den VPN-Tunnel
gestellt werden.
Im Zweifelsfalle können die Standardeinstellungen übernommen werden.
Logging von DNS-Queries: `yes' oder `no'
Für ausführlichere Ausgaben des DNS, muß DNS_VERBOSE auf yes gesetzt werden. In diesem Fall werden DNS-Anfragen an den Nameserver protokolliert - und zwar über die syslog-Schnittstelle. Damit die Ausgaben auch sichtbar werden, ist dann auch die Variable OPT_SYSLOGD='yes' zu setzen, s.u.
Mit dieser Variable gibt man hier den Hostnamen für den MX-Record (Mail-Exchanger) für die in DOMAIN_NAME definierte Domain an. Ein MTA (Mail"=Transport"=Agent, wie z.B. sendmail) auf einem internen Server fragt per DNS nach einem Mail-Exchanger für die Zieldomain der zuzustellenden Mail. Der DNS-Server liefert hiermit dem MTA den entsprechenden Host, der für Mails der Domain DOMAIN_NAME zuständig ist.
Dies ist keine automatische Konfiguration für Mail-Clients,
wie z.B. Outlook! Also bitte nicht gmx.de hier eintragen und dann
wundern, warum Outlook nicht funktioniert.
Hier können Sie Domains angeben, bei denen DNS-Queries vom DNS-Server prinzipiell als ``nicht vorhanden'' beantwortet werden sollen.
Beispiel:
DNS_FORBIDDEN_N='1'
DNS_FORBIDDEN_1='foo.bar'
In diesem Fall wird zum Beispiel eine Anfrage nach www.foo.bar mit einem Fehler beantwortet.
Man kann damit auch ganze Top-Level-Domains verbieten:
DNS_FORBIDDEN_1='de'
Dann ist die Namensauflösung für sämtliche Rechner in der DE-Topleveldomain abgeschaltet.
Hier können Domains angegeben werden, bei welchen DNS-Queries vom DNS-Server auf eine spezielle IP umgeleitet werden.
Beispiel:
DNS_REDIRECT_N='1'
DNS_REDIRECT_1='yourdom.dyndns.org'
DNS_REDIRECT_1_IP='192.168.6.200'
In diesem Fall wird zum Beispiel eine Anfrage nach yourdom.dyndns.org mit der IP 192.168.6.200 beantwortet. Somit kann man externe Domains auf andere IPs umleiten.
Setzt man diese Variable auf `yes`, werden reverse-lookups für IP-Adressen nach RFC1918 (Private Address Bereiche) nicht vom dnsmasq an andere DNS-Server weitergeleitet, sondern vom dnsmasq beantwortet.
Gelegentlich möchte man trotz aktiviertem DNS_BOGUS_PRIV die Auflösung von Adressen einiger privater Subnetze dennoch an die konfigurierten DNS-Server delegieren. Dies ist zum Beispiel nötig, wenn ein Uplink-Router private Subnetze verwaltet. Diese Array-Variable kann dafür genutzt werden, die privaten Subnetze zu benennen, deren Auflösung delegiert werden darf.
Setzt man diese Variable auf 'yes', werden DNS-Anfragen vom Typ SOA, SRV und ANY
geblockt. Dienste, die diese Anfragen verwenden, werden dann nicht mehr ohne weitere
Konfiguration funktionieren.
Dazu zählen zum Beispiel:
Durch Setzen von 'no' können durch die zusätzlichen weitergeleiteten
DNS-Anfragen ungewollte Einwahlverbindungen aufgebaut oder bestehende nicht
abgebaut werden. Insbesondere bei ISDN- und UMTS-Verbindungen können dadurch
Mehrkosten entstehen. Sie müssen selbst abwägen, was für Sie wichtiger ist.
setzt man diese Variable auf 'yes' kann der fli4l-Router in einer Domäne mit DOMAIN_NAME='example.local' konfiguriert werden, die wiederrum per DNS_ZONE_DELEGATION_x_DOMAIN='example.local' von einem anderen Nameserver aufgelöst wird.
Gibt die TTL (Time to live, in Sekunden) für Einträge aus den /etc/hosts Dateien und den per DHCP vergebenen IP-Adressen an. Der Standardwert für den fli4l-Router beträgt 60 Sekunden. Standardmäßig setzt der dnsmasq die TTL für lokale Einträge auf 0 und deaktiviert damit faktisch das nachfolgende Caching der DNS Einträge. Die Idee dahinter ist das ablaufende DHCP Leases usw. zeitnah weitergegeben werden können. Fragt allerdings z.B. ein lokaler IMAP Proxy die DNS Einträge dadurch mehrfach pro Sekunde ab ist das eine deutliche Belastung für das Netzwerk. Ein Kompromiss ist daher ein relativ kurzer TTL von 60 Sekunden. Es kann ja auch ohne die kurze TTL von 60 Sekunden jederzeit zu einem simplen abschalten eines Hosts kommen, so dass die abfragende Software sowieso mit nicht antwortetenden Hosts klarkommen muss.
setzt man diese optionale Variable auf 'yes' wird die Unterstützung für IPV6- Adressen des DNS-Servers aktiviert.
Der dnsmasq kann auch eine DNS-Domäne eigenständig verwalten, d.h. er ist ``authoritativ'' für diese Domäne. Dazu muss man zweierlei tun: Zum einen muss angegeben werden, welcher externe (!) DNS-Namensdienst auf den eigenen fli4l verweist und über welche Netzwerk-Schnittstelle dies passiert. Die Angabe der externen Referenz ist erforderlich, denn die Domäne, welche der fli4l verwaltet, ist ja immer eine Unterdomäne einer anderen Domäne.4.2 Die Angabe der Schnittstelle ist wichtig, weil sich der dnsmasq dort ``nach außen'' anders verhält als auf den anderen Schnittstellen ``nach innen'': Nach außen beantwortet der dnsmasq niemals Anfragen für Namen außerhalb der konfigurierten eigenen Domäne. Nach innen funktioniert der dnsmasq natürlich auch als DNS-Relay ins Internet, damit die Auflösung von nicht-lokalen Namen funktioniert.
Zum anderen muss konfiguriert werden, welche Netze nach außen via Namensauflösung erreichbar sind. Hierbei sollten natürlich nur Netze mit öffentlichen IP-Adressen angegeben werden, denn über private Adressen können Hosts von außen ohnehin nicht erreicht werden.
Im Folgenden wird die Konfiguration an einem Beispiel beschrieben. Dieses Beispiel setzt das IPv6-Paket sowie ein öffentlich geroutetes IPv6-Präfix voraus; letzteres kann z.B. von einem 6in4-Tunnel-Provider wie Hurricane Electric bereitgestellt werden.
Die Einstellung DNS_AUTHORITATIVE='yes' aktiviert den authoritativen
Modus des dnsmasq. Dies reicht jedoch nicht aus, da weitere Angaben gemacht
werden müssen (s.u.).
Standard-Einstellung: DNS_AUTHORITATIVE='no'
Beispiel: DNS_AUTHORITATIVE='yes'
Mit dieser Variable wird der DNS-Name konfiguriert, über den auf den fli4l von außen mit Hilfe eines DNS-NS-Records verwiesen wird. Das kann auch ein DNS-Name sein, der zu einem Dynamic DNS-Dienst gehört.
Beispiel: DNS_AUTHORITATIVE_NS='fli4l.noip.me'
Mit dieser Variable wird konfiguriert, an welcher Adresse bzw. Schnittstelle
der dnsmasq DNS-Anfragen für die eigene Domäne authoritativ beantwortet.
Symbolische Namen wie IP_NET_2_IPADDR sind erlaubt. Der dnsmasq kann nur
an einer Adresse/Schnittstelle authoritativ antworten.
Momentan können nur fest zugewiesene Adressen angegeben werden. Adressen, die sich erst durch eine Einwahl ergeben (z.B. mit Hilfe einer PPP-Verbindung), können nicht verwendet werden. Dies wird in einer späteren fli4l-Version korrigiert werden.
Wichtig: Zu beachten ist, dass dies niemals eine Adresse/Schnittstelle sein
darf, an der das eigene LAN hängt, weil sonst keine nicht-lokalen Namen mehr im
LAN aufgelöst werden können!
Beispiel: DNS_AUTHORITATIVE_IPADDR='IP_NET_2_IPADDR'
Hier werden die Netzadressen angegeben, für die der dnsmasq authoritativ die Namen auflösen soll. Dabei funktioniert sowohl die Vorwärts- (Name zu Adresse) als auch die Rückwärtsauflösung (Adresse zu Name).
Ein komplettes Beispiel:
DNS_AUTHORITATIVE='yes'
DNS_AUTHORITATIVE_NS='fli4l.noip.me'
DNS_AUTHORITATIVE_IPADDR='IP_NET_2_IPADDR' # Uplink hängt an eth1
DNS_ZONE_NETWORK_N='1'
DNS_ZONE_NETWORK_1='2001:db8:11:22::/64' # lokales IPv6-LAN
Dabei wird angenommen, dass ``2001:db8:11::/48'' ein zu dem fli4l öffentlich geroutetes IPv6-Präfix ist und dass für das LAN das Subnetz 22 gewählt wurde.
Es gibt besondere Situationen, wo die Angabe eines oder mehrerer DNS Server sinnvoll ist, z.B. bei Einsatz von fli4l im Intranet ohne Internetanschluss oder einem Mix von diesen (Intranet mit eigenem DNS Server und zusätzlich Internetanschluss).
Stellen wir uns folgendes Szenario vor:
Dann wird man ISDN_CIRC_1_ROUTE auf `0.0.0.0' und ISDN_CIRC_2_ROUTE auf `192.168.1.0' setzen. Bei Zugriff auf Rechner mit IP-Adresse 192.168.1.x wird fli4l dann den Circuit 2, sonst den Circuit 1 benutzen. Wenn das Firmennetz aber nicht öffentlich ist, wird in diesem vermutlich ein eigener DNS Server betrieben. Nehmen wir an, die Adresse dieses DNS Servers wäre 192.168.1.12 und der Domainname wäre ``firma.de''.
In diesem Fall gibt man an:
DNS_ZONE_DELEGATION_N='1'
DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_N='1'
DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_IP='192.168.1.12'
DNS_ZONE_DELEGATION_1_DOMAIN_N='1'
DNS_ZONE_DELEGATION_1_DOMAIN_1='firma.de'
Dann werden bei DNS Anfragen an die Domain firma.de der firmeninterne DNS Server benutzt. Alle anderen DNS Anfragen gehen wie üblich an die DNS Server im Internet.
Ein anderer Fall:
Hier hat man also die Möglichkeit, auf 2 Wegen in das Internet zu gelangen. Möchte man geschäftliches und privates trennen, bietet sich dann folgendes an:
ISDN_CIRC_1_ROUTE='0.0.0.0'
ISDN_CIRC_2_ROUTE='0.0.0.0'
Man legt also auf beide Circuits eine Defaultroute und schaltet dann die Route mit dem imond-Client um - je nach Wunsch. Auch in diesem Fall sollte man DNS_ZONE_DELEGATION_N und DNS_ZONE_DELEGATION_x_DOMAIN_x wie oben beschrieben einstellen.
Möchte man auch die Reverse-DNS-Auflösung für ein so erreichbares Netz nutzen, z.B. wird ein Reverselookup von einigen Mailserver gemacht, gibt man in der optionalen Variable DNS_ZONE_DELEGATION_x_NETWORK_x, das/die Netz(werke) an, für die der Reverselookup aktiviert werden soll. Das folgende Beispiel verdeutlicht das:
DNS_ZONE_DELEGATION_N='2'
DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_N='1'
DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_IP='192.168.1.12'
DNS_ZONE_DELEGATION_1_DOMAIN_N='1'
DNS_ZONE_DELEGATION_1_DOMAIN_1='firma.de'
DNS_ZONE_DELEGATION_1_NETWORK_N='1'
DNS_ZONE_DELEGATION_1_NETWORK_1='192.168.1.0/24'
DNS_ZONE_DELEGATION_2_UPSTREAM_SERVER_N='1'
DNS_ZONE_DELEGATION_2_UPSTREAM_SERVER_1_IP='192.168.2.12'
DNS_ZONE_DELEGATION_2_DOMAIN_N='1'
DNS_ZONE_DELEGATION_2_DOMAIN_1='bspfirma.de'
DNS_ZONE_DELEGATION_2_NETWORK_N='2'
DNS_ZONE_DELEGATION_2_NETWORK_1='192.168.2.0/24'
DNS_ZONE_DELEGATION_2_NETWORK_2='192.168.3.0/24'
Mit der Konfigurationsoption DNS_ZONE_DELEGATION_x_UPTREAM_SERVER_x_QUERYSOURCEIP kann man die IP-Adresse für die ausgehenden DNS Anfragen an den oder die Upstream DNS Server setzen. Das ist z.B. dann sinnvoll wenn man den Upstream DNS Server über ein VPN erreicht und nicht möchte, dass die lokale VPN Adresse vom fli4l-Router als Quell IP-Adresse beim Upstream DNS Server auftaucht. Ein anderer Anwendungsfall ist eine vom Upstream DNS Server aus gesehen nicht routebare IP-Adresse (die durch ein VPN Interface evtl. auftritt). Auch in diesem Fall ist es notwendig die vom dnsmasq benutzte ausgehende IP-Adresse fest auf eine vom fli4l-Router benutzte und vom Upstream DNS Server aus erreichbar IP-Adresse zu setzen.
DNS_ZONE_DELEGATION_N='1'
DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_N='1'
DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_IP='192.168.1.12'
DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_QUERYSOURCEIP='192.168.0.254'
DNS_ZONE_DELEGATION_1_DOMAIN_N='1'
DNS_ZONE_DELEGATION_1_DOMAIN_1='firma.de'
DNS_ZONE_DELEGATION_1_NETWORK_N='1'
DNS_ZONE_DELEGATION_1_NETWORK_1='192.168.1.0/24'
Der Nameserver dnsmasq lehnt normalerweise Antworten anderer Nameserver ab, die IP-Adressen aus privaten Netzwerken enthalten. Er verhindert dadurch eine bestimmte Klasse von Angriffen auf das Netzwerk. Hat man allerdings eine Domain in einem Netzwerk mit privaten IP-Adressen und einen extra Nameserver, der für dieses Netz zuständig ist, liefert der genau die Antworten, die vom dnsmasq abgelehnt werden würden. Diese Domains kann man in DNS_REBINDOK_x auflisten, die entsprechenden Antworten auf Anfragen zu der Domain werden dann akzeptiert. Ein weiteres Beispiel für Nameserver, die private IP-Adressen als Antwort liefern, sind sogenannte ``Real-Time Blacklist Server''. Ein Beispiel basierend auf diesen könnte wie folgt aussehen:
DNS_REBINDOK_N='8'
DNS_REBINDOK_1_DOMAIN='rfc-ignorant.org'
DNS_REBINDOK_2_DOMAIN='spamhaus.org'
DNS_REBINDOK_3_DOMAIN='ix.dnsbl.manitu.net'
DNS_REBINDOK_4_DOMAIN='multi.surbl.org'
DNS_REBINDOK_5_DOMAIN='list.dnswl.org'
DNS_REBINDOK_6_DOMAIN='bb.barracudacentral.org'
DNS_REBINDOK_7_DOMAIN='dnsbl.sorbs.net'
DNS_REBINDOK_8_DOMAIN='nospam.login-solutions.de'
Mit OPT_DHCP kann man einstellen, ob der DHCP-Server aktiviert wird.
Mit dieser Variable legt man fest, ob man die interne DHCP-Funktion des dnsmasq benutzt, oder ob man auf den externen ISC-DHCPD zurückgreifen will. Im Falle des ISC-DHCPD entfällt der Support für DDNS.
aktiviert zusätzliche DHCP-Ausgaben im log.
legt die standard Lease-Time für dynamisch vergebene IP-Adressen fest.
legt die maximale Lease-Time für dynamisch vergebene IP-Adressen fest.
Standard Lease-Time für statisch zugeordnete IP-Adressen.
legt die maximale Lease-Time für statisch zugeordnete IP-Adressen fest.
legt das Verzeichnis für die Leases-Datei fest. Möglich ist die Angabe eines absoluten Pfades oder des Wertes auto. Bei Angabe von auto wird die lease-Datei im Unterverzeichnis dhcp des persistent-Verzeichnisses (siehe Base-Dokumentation) abgelegt.
Befindet sich das Verzeichnis für die Leases in der Ram-Disk (da der Router z.B. von CD oder einem anderen nicht schreibbaren Medium bootet), gibt der Router beim Booten eine Warnung wegen einer fehlenden Lease-Datei aus. Diese Warnung entfällt, wenn man DHCP_LEASES_VOLATILE auf yes setzt.
legt die Adresse des ersten WINS-Server fest. Bei installiertem und aktiviertem WINS-Server wird die Adresse des WINS-Server des SAMBA-Paketes übernommen.
legt die Adresse des zweiten WINS-Server fest. Bei installiertem und aktiviertem WINS-Server wird die Adresse von WINS-Server des SAMBA-Paketes übernommen.
Anzahl der DHCP-Ranges
Referenz zu einem in IP_NET_x definiertem Netz
legt die erste zu vergebende IP-Adresse fest.
legt die letzte zu vergebende IP-Adresse fest. Die beiden Variablen DHCP_RANGE_x_START und DHCP_RANGE_x_END kann man auch leer lassen, es wird dann keine DHCP-Range angelegt und nur die weiteren Variablen genutzt, um einem Host der per MAC-Zuordnung seine DHCP-IP bezieht, die Werte der Variablen zu übergeben.
legt die Adresse des DNS-Server für DHCP-Hosts des Netzes fest. Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable einfach weggelassen, wird die IP-Adresse, des zugeordneten Netzes verwendet. Es ist auch möglich, diese Variable auf 'none' zu setzen. Dann wird kein DNS-Server übertragen.
legt die IP-Adresse des zweiten DNS-Servers fest. Es gelten die gleiche Option wie in der vorherigen Variable
legt eine spezielle DNS-Domain für DHCP-Hosts dieser Range fest. Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable einfach weggelassen, wird der Default DNS-Domain DOMAIN_NAME verwendet.
legt die Adresse des NTP-Servers für DHCP-Hosts dieser Range fest. Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable einfach weggelassen, wird die IP-Adresse des in DHCP_RANGE_x_NET referenzierten Netzes verwendet, wenn ein Zeitserverpaket auf dem Router aktiviert ist. Es ist auch möglich, diese Variable auf 'none' zu setzen. Dann wird kein NTP-Server übertragen.
legt die Adresse des Gateways für diese Range fest. Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable einfach weggelassen, wird die IP-Adresse des in DHCP_RANGE_x_NET referenzierten Netzes verwendet. Es ist auch möglich, diese Variable auf 'none' zu setzen. Dann wird kein Gatway übertragen.
legt die MTU für Clients in diesem Range fest. Diese Variable ist optional.
gestattet die Angabe Nutzer-definierter Optionen für diesen Bereich. Die verfügbaren Optionen kann man dem Manual des dnsmasq entnehmen (http://thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example). Sie werden ungeprüft übernommen, können also bei Fehlern zu Problemen mit dem DNS/DHCP-Server führen. Diese Variable ist optional.
legt die Anzahl von DHCP-Bereichen fest, die an nicht lokale Netze vergeben werden. Hierzu ist am Gateway zum entsprechenden Netz ein DHCP-Relay zu installieren.
erste zu vergebende IP-Adresse.
letzte zu vergebende IP-Adresse.
Netzwerkmaske für diesen Bereich.
Adresse des DNS-Servers für diesen Bereich.
Adresse des NTP-Servers für diesen Bereich.
Adresse des Default-Gateway für diesen Bereich.
legt die MTU für Clients in dieser Range fest. Diese Variable ist optional.
Netzwerkinterface über den dieser Bereich erreicht wird.
Anzahl der MAC-Adressen von Host, dennen der Zugriff auf DHCP-Adressen verweigert wird.
MAC-Adresse des Hosts, dem der Zugriff auf DHCP-Adressen verweigert wird.
Der dnsmasq unterstützt Clients, die via Bootp/PXE übers Netz booten. Die dafür nötigen Informationen werden vom dnsmasq bereitgestellt und pro Subnetz und Host konfiguriert. Die dafür nötigen Variablen sind in den DHCP_RANGE_%- und HOST_%-Abschnitten untergebracht und beschreiben das zu bootende File (*_PXE_FILENAME), den Server, der dieses File bereitstellt (*_PXE_SERVERNAME und *_PXE_SERVERIP) und evtl. notwendige Optionen (*_PXE_OPTIONS). Weiterhin kann man den internen tftp-Server aktivieren, so dass das Booten komplett von dnsmasq unterstützt wird.
Hier wird das zu bootende Image angegeben. Im Falle von PXE wird hier der zu ladende pxe-Bootloader, wie z.B. pxegrub, pxelinux oder ein anderer passender Bootloader angegeben.
Einige Bootloader benötigen spezielle Optionen zum Booten. So
erfragt zum Beispiel pxegrub über die Option 150 den Namen der
Menu-Datei. Diese Optionen können hier angegeben werden und werden
dann ins Konfigfile übernommen. Im Falle von pxegrub könnte das
z.B. wie folgt aussehen:
HOST_x_PXE_OPTIONS='150,"(nd)/grub-menu.lst"'
Sind mehrere Optionen nötig, werden sie einfach mit Leerzeichen voneinander getrennt angegeben.
Das DHCP-Relay wird dann verwendet, wenn ein anderer DHCP-Server die Verwaltung der Ranges übernimmt, der nicht direkt von den Clients erreicht werden kann.
Dieser Wert ist auf 'yes' zu setzen, damit der Router als DHCP-Relay arbeitet. Es darf nicht gleichzeitig ein DHCP-Server aktiv sein.
Standard-Einstellung: OPT_DHCPRELAY='no'
Das Interface, über das die Antworten des DHCP-Servers wieder reinkommen, muß in der Liste mit aufgeführt werden.Zusätzlich muss sichergestellt werden, dass die Routen auf dem Rechner, auf dem der DHCP-Server läuft, korrekt gesetzt sind. Die Antwort des DHCP-Servers geht an die IP des Interfaces, an dem der DHCP-Client hängt. Nehmen wir folgendes Scenario an:
Dann muss es auf dem DHCP-Server eine Route geben, über den die Antworten an die 192.168.6.1 ihr Ziel erreichen. Ist der Router, auf dem das Relay läuft, der default gateway für den DHCP-Server, ist bereits alles ok. Ist dem nicht so, wird eine extra Route benötigt. Ist der DHCP-Server ein fli4l-Router, würde folgender Konfig-Eintrag dieses Ziel erreichen: IP_ROUTE_x='192.168.6.0/24 192.168.7.1'
Im Betrieb kann es zu Warnungen kommen, dass bestimmte Pakete ignoriert werden. Diese Warnungen kann man ignorieren, sie stören nicht den normalen Betrieb.
Beispiel:
OPT_DHCPRELAY='yes'
DHCPRELAY_SERVER='192.168.7.2'
DHCPRELAY_IF_N='2'
DHCPRELAY_IF_1='eth0'
DHCPRELAY_IF_2='eth1'
Der TFTP-Server wird dann verwendet, wenn der fli4l per TFTP Dateien ausliefern soll. Dies kann zum Beispiel dazu dienen, das ein Client per Netboot startet.
Spezifiziert das Verzeichnis, in dem die Dateien liegen, die der tftp-Server an die Klienten ausliefern soll. Die entsprechenden Dateien sind mit Hilfe eines geeigneten Programms (z.B. scp) im entsprechenden Pfad abzulegen.
Aktiviert den YADIFA Slave DNS Server. Standard-Wert ist 'no'.
Wenn diese Einstellung aktiviert wird erzeugt das yadifa Startscript automatisch für alle Slavezonen entsprechende Zone Delegation Einträge für den dnsmasq. Damit sind die Slavezonen auch direkt über den dnsmasq abfragbar und man benötigt im Prinzip keine YADIFA_LISTEN_x Einträge mehr. Die Anfragen werden dann vom dnsmasq beantwortet und einen nur auf localhost:35353 horchenden yadifa weitergeleitet.
Wenn Sie OPT_YADIFA='yes' gewählt haben, können Sie mit
Hilfe von YADIFA_LISTEN_N die Anzahl, und
mit YADIFA_LISTEN_1 bis YADIFA_LISTEN_N lokale IPs
angeben, auf denen YADIFA DNS-Anfragen annehmen darf. Eine
Portnummer ist optional möglich, mit der Angabe 192.168.1.1:5353
würde der YADIFA Slave DNS Server auf DNS Anfragen auf Port 5353
horchen. Achten Sie darauf, dass der dnsmasq in diesem Fall nicht
auf allen Schnittstellen horchen darf
(siehe DNS_BIND_INTERFACES). An dieser Stelle dürfen nur
IPs von existierenden Schnittstellen (ethernet, wlan ...)
verwendet werden, es kommt sonst zu Warnmeldungen beim Start des
Routers. Alternativ ist nun möglich hier auch ALIAS-Namen zu
verwende, z.B. IP_NET_1_IPADDR
Gibt IP-Adressen und Netze an denen der Zugriff auf YADIFA erlaubt ist. YADIFA nutzt die Angaben um den fli4l Paketfilter entsprechend zu konfigurieren und die Konfigurationsdateien von YADIFA zu erstellen. Mit dem Prefix ! wird der IP-Adresse oder dem Netz der Zugriff auf YADIFA verweigert.
Der fli4l Paketfilter wird für YADIFA so konfiguriert, dass alle erlaubten Netze aus dieser Einstellung und der für die einzelnen Zonen zusammen in eine ipset Liste (yadifa-allow-query) aufgenommen werden. Eine Unterscheidung nach Zonen ist beim Paketfilter leider nicht möglich. Zusätzlich werden alle IP-Adressen und Netze aus dieser globalen Einstellung, denen der Zugriff verweigert wird, in diese Liste aufgenommen. Es ist daher nicht möglich den Zugriff später für einzelne Zonen wieder auszuweiten.
Gibt die Anzahl der Slave DNS Zonen an die YADIFA verwalten soll.
Der Name der Slave DNS Zone.
Aktiviert (='yes') oder deaktiviert (='no') die dnsmasq Zone Delegation nur für die Slavezone.
Die IP-Adresse mit einer optionalen Portnummer des DNS Master Server.
Gibt IP-Adressen und Netze an denen der Zugriff auf diese YADIFA DNS Zone erlaubt ist. Damit kann der Zugriff auf bestimmte DNS Zonen weiter eingeschränkt werden. YADIFA nutzt die Angaben um die Konfigurationsdateien von YADIFA zu erstellen.
Mit dem Prefix ! wird die IP-Adresse oder das Netz der Zugriff auf YADIFA verweigert.