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
, IP_NET_1_DEV
oder
{LAN}
sind erlaubt. Der dnsmasq kann nur an einer
Adresse/Schnittstelle authoritativ antworten.
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_LISTEN='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_LISTEN='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 Adressen der DNS-Server fest.
Mehrere DNS-Server können durch Leerzeichen getrennt angegeben werden.
Diese Variable ist optional.
Wird hier nichts eingetragen, oder die Variable weggelassen,
wird die IP-Adresse des zugehörigen Netzes verwendet, wenn der DNS-Server auf dem Router aktiviert ist.
Es ist auch möglich, diese Variable auf 'none' zu setzen. Dann wird kein DNS-Server übertragen.
Diese Einstellung wird ggf. von
DHCP_RANGE_x_DNS_SERVERS überschrieben.
legt die Adressen der WINS-Server fest.
Mehrere WINS-Server können durch Leerzeichen getrennt angegeben werden.
Diese Variable ist optional.
Wird hier nichts eingetragen, oder die Variable weggelassen,
wird bei installiertem und aktiviertem WINS-Server die Adresse des WINS-Server
des SAMBA-Paketes übernommen.
Es ist auch möglich, diese Variable auf 'none' zu setzen. Dann wird kein WINS-Server übertragen.
Diese Einstellung wird ggf. von
DHCP_RANGE_x_WINS_SERVERS überschrieben.
legt die Adressen der NTP-Server fest.
Mehrere NTP-Server können durch Leerzeichen getrennt angegeben werden.
Diese Variable ist optional.
Wird hier nichts eingetragen, oder die Variable weggelassen,
wird die IP-Adresse des zugehörigen 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.
Diese Einstellung wird ggf. von
DHCP_RANGE_x_NTP_SERVERS überschrieben.
aktiviert oder deaktiviert die Übermittlung der DHCP-OPTION 252 (Web Proxy Autodiscovery Protocol) womit Browser automatisiert die Proxy-Einstellungen beziehen können. (siehe http://de.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol)
definiert die URL der wpad.dat Datei oder wird leer gelassen um eine leere Antwort an den anfragenden Browser zu schicken, wodurch dieser keine weiteren regelmäßigen Anfragen durchführt.
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 eine spezielle DNS-Domain für DHCP-Hosts dieser Range fest. Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable weggelassen, wird der Default DNS-Domain DOMAIN_NAME verwendet.
legt die Adressen der DNS-Server fest.
Mehrere DNS-Server können durch Leerzeichen getrennt angegeben werden.
Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable weggelassen,
wird die Einstellung aus DHCP_DNS_SERVERS verwendet.
Es ist auch möglich, diese Variable auf 'none' zu setzen. Dann wird kein DNS-Server übertragen.
legt die Adressen der WINS-Server fest.
Mehrere WINS-Server können durch Leerzeichen getrennt angegeben werden.
Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable weggelassen,
wird die Einstellung aus DHCP_WINS_SERVERS verwendet.
Es ist auch möglich, diese Variable auf 'none' zu setzen. Dann wird kein WINS-Server übertragen.
legt die Adressen der NTP-Server fest.
Mehrere NTP-Server können durch Leerzeichen getrennt angegeben werden.
Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable einfach weggelassen,
wird die Einstellung aus DHCP_NTP_SERVERS verwendet.
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.
aktiviert oder deaktiviert die Übermittlung der DHCP-OPTION 252 (Web Proxy Autodiscovery Protocol) für diese DHCP-Range womit Browser automatisiert die Proxy-Einstellungen beziehen können. (siehe http://de.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol) Diese Variable ist optional.
definiert die URL der wpad.dat Datei oder wird leer gelassen um eine leere Antwort an den anfragenden Browser zu schicken, wodurch dieser keine weiteren regelmäßigen Anfragen durchführt. 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.
Adressen der DNS-Server
(siehe DHCP_RANGE_x_DNS_SERVERS).
Adressen der WINS-Server
(siehe DHCP_RANGE_x_WINS_SERVERS).
Adressen der NTP-Server
(siehe DHCP_RANGE_x_NTP_SERVERS).
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'
Ein DHCP-Client kann verwendet werden, um eine IP-Adresse für eine oder mehrere Schnittstellen des Routers zu beziehen – dies erfolgt meist vom Service-Provider. Diese Möglichkeit der Anbindung kommt derzeit hauptsächlich bei Kabelmodem-Betreibern und in der Schweiz, in den Niederlanden und in Frankreich vor. Manchmal wird diese Konfiguration auch benötigt, wenn der Router hinter einem anderen Router eingebunden wird, der die Adressen per DHCP verteilt (z. B. FritzBox).
Die Konfiguration eines Netzwerks für DHCP erfordert zwei verschiedene Aktionen:
Die Konfiguration der Netzwerk-Schnittstelle via DHCP wird immer dann durchgeführt, wenn der betreffende Circuit online geht; analog wird die erhaltene Adresse wieder freigegeben, wenn der Circuit offline geht. Routen werden gemäß der Variablen CIRC_%_NETS_IPV4 gesetzt.
Das Paket wird über die Variable OPT_DHCP_CLIENT aktiviert:
Diese Variable muss auf 'yes' gesetzt werden, um DHCP-Circuits anlegen zu können.
Standard-Einstellung: OPT_DHCP_CLIENT='no'
Soll für ein Netz DHCP verwendet werden, so muss ein passender Circuit konfiguriert werden, siehe Abschnitt Circuit-Konfiguration. Der zu verwendende Typ in CIRC_x_TYPE lautet “dhcp”. Zu den allgemeinen Circuit-Variablen kommen die folgenden hinzu, die DHCP-spezifisch sind:
In dieser Variable ist die Netzwerk-Schnittstelle vermerkt, für die das DHCP-Protokoll genutzt werden soll. Es ist sinnvoll, auf die Schnittstelle mit Hilfe der zugehörigen IP_NET_x_DEV-Variable zu verweisen.
Beispiel: CIRC_1_DHCP_DEV='IP_NET_1_DEV'
Das Paket kommt momentan mit zwei verschiedenen Implementierungen eines DHCP-Clients, dhcpcd und dibbler. Momentan wird dhcpcd nur für DHCPv4 und dibbler nur für DHCPv6 verwendet, so dass man nicht wirklich eine Wahl hat und diese Einstellung im besten Falle einfach nicht setzen sollte. Sollten später weitere Implementierungen unterstützt werden, wird die Auswahl über diese Variable erfolgen.
Beispiel 1: CIRC_1_DHCP_DAEMON='dhcpcd'
Beispiel 2: CIRC_1_DHCP_DAEMON='dibbler'
Falls IPv6-Unterstützung aktiviert ist, muss darauf geachtet werden, dass nur IPv6-Netze (via CIRC_x_NET_IPV6) geroutet werden und die Variable CIRC_x_NET_IPV4 nicht vorhanden oder leer ist. Auch ist zu beachten, dass der DHCPv6-Server in der Regel nicht eine einzelne Adresse, sondern ein ganzes IPv6-Subnetzpräfix zuweist (Prefix Delegation), so dass die IPV6_NET_x-Variable ein Suffix enthalten sollte (siehe hierzu die letzten beiden Beispiele weiter unten).
Es ist nicht möglich, mit Hilfe eines einzigen Circuits sowohl IPv4- als auch IPv6-Adressen via DHCP zu empfangen, Hierzu müssen zwei separate DHCP-Circuits eingerichtet werden.
Standard-Einstellung:
CIRC_1_DHCP_DAEMON='dhcpcd'
(für IPv4)
CIRC_1_DHCP_DAEMON='dibbler'
(für IPv6)
Manche Provider verlangen die Übermittlung eines Hostnamens. Dieser Name ist vom Provider zu erfahren und hier anzugeben. Er muss nicht zwangsläufig mit dem Hostnamen des Routers übereinstimmen.
Beispiel: CIRC_1_DHCP_HOSTNAME='gandalf'
Fehlt diese Variable oder ist sie leer, wird kein Hostname zum DHCP-Server gesandt.
Standard-Einstellung: CIRC_1_DHCP_HOSTNAME=”
Mit dieser Variable kann optional der Start des DHCP-Clients verzögert werden.
In manchen Installationen (z. B. fli4l als DHCP-Client hinter einem Kabelmodem oder einer FritzBox) ist es notwendig zu warten, bis der genutzte DHCP-Server z. B. nach einen Stromausfall ebenfalls neu gestartet worden ist.
Falls CIRC_x_WAIT ebenfalls verwendet wird, muss darauf geachtet werden, dass die Variable CIRC_x_WAIT größer als CIRC_x_DHCP_STARTDELAY ist, da ansonsten immer zu wenig Zeit zum Warten zur Verfügung steht.
Beispiel: CIRC_1_DHCP_STARTDELAY='20'
Standard-Einstellung: CIRC_1_DHCP_STARTDELAY='0'
Diese Variable steuert die Übernahme von zusätzlichen Routen, die der DHCP-Server senden kann. Für gewöhnlich wird dem DHCP-Client vom DHCP-Server nur ein Default-Router mitgeteilt. Gelegentlich passiert es jedoch, dass der DHCP-Server gar keinen Default-Router mitteilt und/oder andere Routen übermittelt. Das ist beispielsweise bei einem Telekom-Entertain-IPTV-Anschluss der Fall. In diesem Fall werden diese zusätzlichen Routen ebenfalls auf dem fli4l-Router installiert.
Diese Verarbeitung ist standardmäßig aktiviert. Vertrauen Sie Ihrem DHCP-Server jedoch nicht, können Sie die Verarbeitung der zusätzlichen Routen deaktivieren. Bedenken Sie jedoch, dass dann die korrekte Routing-Funktionalität nicht garantiert werden kann.
Beispiel: CIRC_1_DHCP_ACCEPT_CSR='no'
Standard-Einstellung: CIRC_1_DHCP_ACCEPT_CSR='yes'
Neben einem oder mehreren passenden Circuits müssen weiterhin ein oder mehrere passende Netze via IP_NET_x in der config/base.txt für den DHCP-Betrieb vorbereitet werden. Dazu müssen diese Variablen auf den Namen des jeweils zu verwendenden DHCP-Circuits oder eines seiner Schlagwörter (beides jeweils in geschweiften Klammern) gesetzt werden.
Beispiel 1 (IPv4):
IP_NET_N='1' IP_NET_1='{circ1}' # alternativ '{dhcp0}' IP_NET_1_DEV='eth1' [...] # CIRC_N='1' # CIRC_1_NAME='DHCP-LAN' CIRC_1_TYPE='dhcp' CIRC_1_ENABLED='yes' CIRC_1_NETS_IPV4_N='1' CIRC_1_NETS_IPV4_1='0.0.0.0/0' CIRC_1_UP='yes' CIRC_1_WAIT='15' CIRC_1_DHCP_DEV='IP_NET_1_DEV'
Beispiel 2 (IPv4 mit Nutzung von Schlagwörtern):
IP_NET_N='1' IP_NET_1='{dhcp-lan}' IP_NET_1_DEV='eth1' [...] # CIRC_N='1' # CIRC_1_NAME='DHCP-LAN' CIRC_1_TYPE='dhcp' CIRC_1_ENABLED='yes' CIRC_1_NETS_IPV4_N='1' CIRC_1_NETS_IPV4_1='0.0.0.0/0' CIRC_1_UP='yes' CIRC_1_WAIT='15' CIRC_1_DHCP_DEV='IP_NET_1_DEV'
Beispiel 3 (IPv6 mit DHCPv6-Server im LAN und Referenz über den Circuit-Namen):
IPV6_NET_N='1' IPV6_NET_1='{DHCPv6-LAN}::1:0:0:0:1/64' IPV6_NET_1_DEV='eth1' [...] # CIRC_N='1' # CIRC_1_NAME='DHCPv6-LAN' CIRC_1_TYPE='dhcp' CIRC_1_ENABLED='yes' CIRC_1_UP='yes' CIRC_1_WAIT='15' CIRC_1_DHCP_DEV='IPV6_NET_1_DEV' CIRC_1_PROTOCOLS='ipv6'
Beispiel 4 (IPv6 mit DHCPv6-Server auf der anderen Seite einer PPP-Verbindung):
IPV6_NET_N='1' IPV6_NET_1='{DHCPv6-manitu}::1:0:0:0:1/64' IPV6_NET_1_DEV='eth1' [...] # CIRC_N='2' # CIRC_1_NAME='DHCPv6-manitu' CIRC_1_TYPE='dhcp' CIRC_1_ENABLED='yes' CIRC_1_UP='yes' CIRC_1_WAIT='15' CIRC_1_DHCP_DEV='{DSL-manitu}' CIRC_1_PROTOCOLS='ipv6' # CIRC_2_NAME='DSL-manitu' CIRC_2_TYPE='ppp' CIRC_2_ENABLED='yes' CIRC_2_PPP_TYPE='ethernet' CIRC_2_NETS_IPV6_N='1' CIRC_2_NETS_IPV6_1='::/0' [...]
In den IPv4-Beispielen wird die Default-Route über den DHCP-Circuit gelegt. Ist
das nicht erwünscht, muss CIRC_x_NETS_IPV4_% entsprechend geändert
werden. Auch werden alle Circuits bereits beim Booten aktiviert
(CIRC_x_UP='yes'
), und der Boot-Vorgang wartet maximal 15 Sekunden
darauf, dass der Router eine IP-Adresse erfolgreich via DHCP erhalten hat. Das
ist vor allem dann nötig, wenn andere Pakete eine vorhandene Netzanbindung
während des Boot-Vorgangs erfordern.
In den IPv6-Beispielen werden keine Default-Routen über den DHCP-Circuit gelegt. Das liegt daran, dass bei DHCPv6 (im Gegensatz zum IPv4-Pendant) keine Informationen zum Routing versandt werden. Informationen über Next-Hop-Router werden hier über so genannte “Router Advertisements” verschickt.
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.