|
|
| (4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| '''topic''' - Kurzbeschreibung
| | [[Kategorie:IPv6/Administration]] |
| == Beschreibung ==
| |
| Hinweise zu IPv6 kompatiblen Daemons
| |
| | |
| == Berkeley Internet Name Domain (BIND) daemon ”named” ==
| |
| Seit der Version 9 wird IPv6 unterstützt. Setzen Sie immer die neuest verfügbare Version ein. Zumindest muss Version 9.1.3 eingesetzt werden, da ältere Versionen Sicherheitslöcher beinhalten können, die von Remote entsprechend ausgenutzt werden können.
| |
| | |
| === Auf IPv6 Adressen hören ===
| |
| Anmerkung: Im Gegensatz zu IPv4 können bei aktuellen Versionen Server Sockets nicht an dedizierte IPv6 Adressen gebunden werden, es ist folglich ''jede'' oder ''keine'' Adresse gültig. Da dies ein Sicherheitsproblem sein kann, lesen Sie diesbezüglich ebenfalls den Abschnitt Access Control Lists (ACL) weiter unten!
| |
| | |
| ==== BIND named konfigurieren, damit er auf IPv6 Adressen antwortet ====
| |
| Folgende Optionen müssen geändert werden, damit IPv6 aktiviert wird
| |
| | |
| Nach einem Neustart (des Dienstes) sollte z.B. Folgendes zu sehen sein:
| |
| | |
| Ein kleiner Test sieht wie folgt aus:
| |
| | |
| und sollte Ihnen ein Ergebnis anzeigen...
| |
| | |
| ==== BIND named konfigurieren, damit er auf IPv6 Adressen nicht antwortet ====
| |
| Folgende Optionen müssen geändert werden, damit IPv6 deaktiviert wird:
| |
| | |
| | |
| === Access Control Lists (ACL) mit IPv6 Unterstützung ===
| |
| ACLs mit IPv6 Adressen sind realisierbar und sollten wann immer möglich eingesetzt werden. Ein Beispiel:
| |
| | |
| Diese ACLs können für Client-Anfragen und Zonentransfers zu Secondary Nameserver eingesetzt werden. Es kann auch unterbunden werden, dass ihr Caching-Nameserver mittels IPv6 von der Außenwelt verwendet wird.
| |
| | |
| Es ist ebenfalls möglich, dass die Optionen ''allow-query'' und ''allow-transfer'' bei den meisten Single-Zonen-Definitionen verwendet werden.
| |
| | |
| === Anfragen mit festen IPv6 Adressen senden ===
| |
| Diese Option ist nicht verpflichtend, ev. aber benötigt:
| |
| | |
| | |
| === Pro Zone definierte feste IPv6 Adressen ===
| |
| Es ist möglich pro Zone mehrere IPv6 Adressen zu definieren.
| |
| | |
| ==== Transfer source Adresse ====
| |
| Die Transfer source Adresse wird für ausgehende Zonentransfers verwendet:
| |
| | |
| | |
| ==== Notify source Adresse ====
| |
| Die Notify source Adresse wird für ausgehende notify Mitteilungen verwendet:
| |
| | |
| | |
| === IPv6 DNS zone files Beispiele ===
| |
| Einige Informationen finden Sie auch unter IPv6 DNS Setup Information (article). Eventuell ebenfalls hilfreich ist folgendes Tool: IPv6 Reverse DNS zone builder for BIND 8/9 (webtool).
| |
| | |
| === IPv6 bezogene DNS-Daten bereitstellen ===
| |
| Für IPv6 wurden neue Reverse Lookup Arten und Root Zonen definiert:
| |
| | |
| * AAAA und reverse IP6.INT: beschrieben in <nowiki>RFC 1886</nowiki> / DNS Extensions to support IP version 6 sowie seit BIND Version 4.9.6 in Verwendung
| |
| * A6, DNAME (WURDE ABGELEHNT!) und reverse IP6.ARPA: beschrieben in <nowiki>RFC 2874</nowiki> / DNS Extensions to Support IPv6 Address Aggregation and Renumbering sowie seit BIND 9 in Verwendung. Informationen zum aktuellen Stand sind unter Domain Name System Extension (dnsext) zu finden.
| |
| | |
| Mehr Inhalt zu diesem Thema wird eventuell in späteren Versionen eingearbeitet, inzwischen können Sie in den RFCs und in folgenden Quellen nachlesen:
| |
| | |
| * AAAA und reverse IP6.INT: IPv6 DNS Setup Information
| |
| * A6, DNAME (WURDE ABGELEHNT!) und reverse IP6.ARPA: lesen Sie im Kapitel 4 und 6 des BIND 9 Administrator Reference Manual (ARM) nach, welches mit dem bind-Paket mitgeliefert wird. Sie können es auch hier lesen: BIND manual version 9.3
| |
| | |
| Da IP6.INT (ebenfalls) ABGELEHNT WURDE, (jedoch nach wie vor in Verwendung ist,) muss ein DNS Server, der IPv6 Informationen anbieten will, beide reverse Zonen bereitstellen.
| |
| | |
| ==== Aktuell beste Praxis ====
| |
| Da es mit den neuen Formaten noch Probleme gibt, ist die aktuell beste Praxis:
| |
| | |
| Vorwärts-Auflösung mit:
| |
| | |
| * AAAA
| |
| | |
| Rückwärts-Auflösung mit:
| |
| | |
| * Reverse nibble format für die Zone ip6.int (FÜR RÜCKWÄRTSKOMPATIBILITÄT)
| |
| * Reverse nibble format für die Zone ip6.arpa (EMPFHOHLEN)
| |
| | |
| === IPv6 Verbindung überprüfen ===
| |
| Ob BIND auf einen IPv6 socket hört bzw. IPv6 Daten bereitstellt, können Sie anhand folgender Beispiele überprüfen.
| |
| | |
| ==== IPv6 Verbindung durch ACL abgelehnt ====
| |
| Eine IPv6 Verbindung kann durch Angabe eines dedizierten Server, der abgefragt werden soll, erzwungen werden:
| |
| | |
| Ein entsprechender Log-Eintrag sieht wie folgt aus:
| |
| | |
| Wenn Sie diesen Eintrag in der Logdatei finden, prüfen Sie, ob von diesem Client Anfragen akzeptiert werden sollen und ggf. ändern Sie Ihre ACL Konfiguration.
| |
| | |
| ==== Erfolgreiche IPv6 Verbindung ====
| |
| Eine erfolgreiche IPv6 Verbindung sieht wie folgt aus:
| |
| | |
| | |
| == Internet super daemon (xinetd) ==
| |
| IPv6 wird ungefähr seit der xinetd Version 1.8.9 unterstützt. Verwenden sie immer die neueste Version, zumindest aber Version 2.3.3, da ältere Versionen Sicherheitslöcher beinhalten können, die von Remote entsprechend ausgenutzt werden können.
| |
| | |
| Einige Linux Distributionen beinhalten ein separates IPv6 kompatibles Paket des xinetd, bei anderen Distributionen wird der IPv6 kompatible xinetd mit folgender Variable zumeist in der Datei /etc/sysconfig/network (bei Red Hat kompatible Distributionen) gestartet: NETWORKING_IPV6="yes". In neuere Versionen unterstützt eine Binärdatei sowohl IPv4 als auch IPv6.
| |
| | |
| Wenn Sie nun einen "eingebauten" Service wie z.B. daytime durch folgende Änderung der Konfigurationsdatei /etc/xinetd.d/daytime aktivieren
| |
| | |
| dann sollten Sie nach einem Neustart des xinetd-Dienstes z.B. folgendes positive Ergebnis sehen:
| |
| | |
| Das Beispiel zeigt auch die xinetd Dienste IMAP und IMAP-SSL, die nur auf IPv4 Adressen hören.
| |
| | |
| Hinweis: frühere Versionen hatten ein Problem, dass der nur für IPv4 kompilierte xinetd nicht bei einem IPv6-aktivierten Knoten startete, und eine IPv6-aktivierte nicht bei einem Knoten, der nur IPv4 aktiv hatte. Dies sollte aber mindestens seit Version 2.3.11 gefixt sein.
| |
| | |
| == Webserver Apache2 (httpd2) ==
| |
| IPv6 wird beim Apache Webserver durch die Entwickler seit der Version 2.0.14 unterstützt. Verfügbare Patches für die alte 1.3.x Serie sind inzwischen nicht mehr aktuell und sollten nicht mehr in öffentlich zugänglichen Umgebungen eingesetzt werden. Verfügbar sind die Patches noch unter KAME / Misc.
| |
| | |
| === Auf IPv6 Adressen hören ===
| |
| Anmerkung: Virtuelle Hosts mit IPv6 Adressen sind bis zur Version 2.0.28 nicht operabel (es gibt für die Version 2.0.28 einen Patch). Testen Sie aber immer zuerst die neueste Version, da ältere Versionen mitunter auch Sicherheitsprobleme mit sich bringen können.
| |
| | |
| ==== Virtueller Host mit IPv6 Adresse ====
| |
| | |
| | |
| ==== Virtueller Host mit IPv4 und IPv6 Adresse ====
| |
| | |
| Das Ergebnis sollten nach einen Neustart des Dienstes etwa Folgendes sein:
| |
| | |
| Für einfache Tests können Sie auf das bereits gezeigte telnet-Beispiel zurückgreifen.
| |
| | |
| ==== Zusätzliche Anmerkungen ====
| |
| Apache2 unterstützt eine Methode namens ”sendfile”, um die Auslieferung von Datenn zu beschleunigen. Einige NIC-Treiber unterstützen auch offline das Berechnen der Checksumme. In einigen Fällen kann dies zu Verbindungsproblemen und ungültigen TCP-Checksummen führen. In diesen Fällen ist ”sendfile” zu deaktivieren, entweder durch Rekompilieren unter der Benützung der configure-Option ”--without-sendfile” oder durch Benützung der Direktive "EnableSendfile off" in der Konfigurationsdatei.
| |
| | |
| == Router Advertisement Daemon (radvd) ==
| |
| Der Router Advertisement Daemon ist auf einem LAN dann sehr sinnvoll, wenn die Clients automatisch konfiguriert werden sollen. Der Daemon selbst sollte auf einem Linux Gateway Router eingerichtet sein (es hat nicht notwendigerweise das default IPv4 Gateway zu sein, Vorsicht also wer am LAN Router Advertisements versendet).
| |
| | |
| Sie können einige Flags und Informationen im Advertisement spezifizieren. Allgemein werden verwendet:
| |
| | |
| * Präfix (notwendige Angabe)
| |
| * Lebensdauer des Präfix
| |
| * Intervall der Advertisements (optional)
| |
| | |
| Nach der korrekten Konfiguration sendet der Daemon die Advertisements über angegebene Interfaces. Die Clients empfangen die Advertisements und konfigurieren automatisch Ihre Adressen mit dem empfangenen Präfix und der Default-Route.
| |
| | |
| === radvd konfigurieren ===
| |
| ==== Einfache Konfiguration ====
| |
| Die Konfigurationsdatei des radvd ist normalerweise die Datei /etc/radvd.conf. Eine einfache Konfiguration sieht wie folgt aus:
| |
| | |
| Als Ergebnis auf der Client-Seite ergibt sich hieraus:
| |
| | |
| Ein hoher Wert für die Lebensdauer wurde verwendet, da der Wert nicht manuell konfiguriert wurde.
| |
| | |
| ==== Spezielle 6to4 Konfiguration ====
| |
| Seit der Version 0.6.2pl3 wird die automatische (Neu)-Erstellung des Präfixes abhängig von der IPv4 Adresse eines angegebenen Interfaces unterstützt. Dies kann dazu eingesetzt werden, die Advertisements dann in einem LAN zu verteilen, nachdem das 6to4 tunneling geändert wurde. Zumeist eingesetzt wird dies hinter einem dynamischen dial-on-demand Linux Router. Wegen der sicherlich kürzeren Lebensdauer dieser Präfixe (nach jedem dial-up ist ein anderes Präfix gültig), wird der Wert der Lebensdauer auf einen minimalen Wert gesetzt:
| |
| | |
| Das Ergebnis auf Clientseite ist (unter der Annahme, dass ppp0 die lokale IPv4 Adresse 1.2.3.4 hat):
| |
| | |
| Da eine kurze Lebensdauer definiert wurde, wird das Präfix bald verworfen werden, sollte kein entsprechendes Advertisement empfangen werden.
| |
| | |
| Achtung: wenn keine spezielle 6to4-Unterstützung der initscripts benutzt wird, ist eine spezielle Route am internen Interface des Routers notwendig, sonst gibt es Probleme bei eingehenden Paketen. Für das gezeigte Beispiel lautet diese:
| |
| | |
| Diese Route muß jedesmal, wenn der Prefix wechselt, ersetzt werden. Die ist dann der Fall, wenn das Dial-Up-Interface eine neue IPv4-Adresse bekommen hat.
| |
| | |
| === Fehlersuche ===
| |
| Mit dem Programm ”radvdump” können Sie gesendete und empfangene Advertisements detailliert betrachten. Die Anwendung ist einfach:
| |
| | |
| Im Output wird jedes Advertisement in einem lesbarem Format dargestellt. Zu sehen sollten die von Ihnen eingestellten Werte sein; falls dem nicht so ist, wurde das Advertisement eventuell nicht von Ihrem radvd gesendet... (für die Rückverfolgung des Routers können Sie die LLAddress, die MAC Adresse des Routers, verwenden...)
| |
| | |
| == Dynamic Host Configuration v6 Server (dhcp6s) ==
| |
| dhcp6s kann für stateful Konfiguration benutzt werden. Der Daemon selbst muß nicht unbedingt auf dem Linux-Standard-Router laufen.
| |
| | |
| Man kann hier mehr Informationen als bei radvd spezifizieren. Die meisten sind denen des IPv4 DHCP-Servers ähnlich.
| |
| | |
| Nach einer passenden Konfiguration reagiert der Daemon auf empfangene IPv6-Multicast-Pakete, die von einem Client an die Adresse ff02::1:2 gesendet werden.
| |
| | |
| === Konfiguration des DHCPv6-Servers (dhcp6s) ===
| |
| ==== Einfache Konfiguration ====
| |
| Die Konfigurationsdatei des dhcp6s ist normalerweise /etc/dhcp6s.conf. Ein einfaches Beispiel sieht wie folgt aus:
| |
| | |
| | |
| === Konfiguration des DHCPv6-Client (dhcp6s) ===
| |
| ==== Einfache Konfiguration ====
| |
| Die Konfigurationsdatei von dhcp6c ist normalerweise /etc/dhcp6c.conf. Ein einfaches Beispiel sieht wie folgt aus:
| |
| | |
| | |
| === Benutzung ===
| |
| ==== dhcp6s ====
| |
| Starten des Servers, z.B. durch
| |
| | |
| ==== dhcp6c ====
| |
| Starten des Clients im Vordergrund, z.B. durch
| |
| | |
| === Fehlersuche ===
| |
| ==== dhcp6s ====
| |
| Der Server hat einen Vordergrund und zwei Debug-Schalter (von denen beide benutzt werden sollten), hier ein Beispiel:
| |
| | |
| ==== dhcp6c ====
| |
| Mit einem IPv6 Ping an die DHCP Multicast-Adresse kann getestet werden, ob der IPv6 DHCP Server überhaupt erreichbar ist am Link.
| |
| | |
| Der Client hat einen Vordergrund und zwei Debug-Schalter, hier ein Beispiel:
| |
| | |
| Bemerkung: die netlink-Fehlermeldungen haben keinen Einfluß auf die Funktionalität.
| |
| | |
| == ISC Dynamic Host Configuration Server (dhcpd) ==
| |
| ISC DHCP unterstützt IPv6 seit der Version 4.x.
| |
| | |
| === Konfiguration des ISC DHCP Server für IPv6 (dhcpd) ===
| |
| Es ist zu beachten, daß der ISC DHCP Server aktuell entweder IPv4 oder IPv6 bedienen kann, nicht beides, d.h. der Daemon muß zweimal gestartet werden (für IPv6 mit Option ”-6”) um beide Protokolle zu unterstützen.
| |
| | |
| ==== Einfache Configuration ====
| |
| Erstellen einer eigenen Konfigurationsdatei /etc/dhcp/dhcpd6.conf für den IPv6-Teil des dhcpd. Es ist zu beachten, daß der router natürlich eine Schnittstelle mit einer IPv6-Adresse aus dem definierten Subnetz konfiguriert haben muß.
| |
| | |
| Es ist zu beachten, dass die ”dhcp.client-id” nicht länger die MAC-Adresse ist, sondern eine per System eindeutige ID! ”dhcp6c” (siehe oben) benutzt die Datei /var/lib/dhcpv6/dhcp6c_duid (wird beim ersten Start erstellt, falls nicht vorhanden) als eindeutige ID. Es ist eine 14 Byte lange ID, welche mit einer 2 Byte Längeninformation startet (üblicherweise ”0x000e”):
| |
| | |
| | |
| === Benutzung ===
| |
| ==== dhcpd ====
| |
| Starte den Server im Vordergrund:
| |
| | |
| == DHCP Server Dibbler ==
| |
| Dibbler ist auch ein DHCP server.
| |
| | |
| === Konfiguration des Dibbler DHCP server für IPv6 ===
| |
| ==== Einfache Konfuration ====
| |
| Erstellen der Konfigurationsdatei /etc/dibbler/server.conf . Es ist zu beachten, daß der router natürlich eine Schnittstelle mit einer IPv6-Adresse aus dem definierten Subnetz konfiguriert haben muß.
| |
| | |
| | |
| === Benutzung ===
| |
| ==== dibbler-server ====
| |
| Start Server im Vorgergrund:
| |
| | |
| == tcp_wrapper ==
| |
| Mit der tcp_wrapper Programmbibliothek können Sie Ihre Dienste gegen Missbrauch schützen.
| |
| | |
| === Filter-Funktionalität ===
| |
| Sie können tcp_wrapper für folgende Zwecke einsetzen:
| |
| | |
| * Nach Source-Adressen filtern (IPv4 oder IPv6)
| |
| * Nach Benutzern filtern (benötigt einen aktiven ident Daemon auf der Client-Seite)
| |
| | |
| === Welches Programm benützt tcp_wrapper ===
| |
| Folgende Programme sind bekannt:
| |
| | |
| * Jeder Dienst, der durch den xinetd aufgerufen wird (und wenn der xinetd mit der tcp_wrapper Bibliothek kompiliert wurde)
| |
| * sshd (wenn der mit der tcp_wrapper Bibliothek kompiliert wurde)
| |
| | |
| === Anwendung ===
| |
| Der tcp_wrapper wird durch zwei Dateien konfiguriert und kontrolliert: /etc/hosts.allow sowie /etc/hosts.deny. Weitere Informationen finden Sie mit:
| |
| | |
| | |
| ==== Beispiel für /etc/hosts.allow ====
| |
| In dieser Datei wird ein Dienst pro Zeile eingetragen, der positiv gefiltert werden soll (d.h. Verbindungen werden erlaubt).
| |
| | |
| Achtung: es existieren fehlerhafte Implementierungen, welche folgende fehlerhafte IPv6-Netzwerk-Beschreibung unterstützen: [2001:0db8:100:200::/64]. Hoffentlich werden diese Versionen bald gefixt.
| |
| | |
| ==== Beispiel für /etc/hosts.deny ====
| |
| In dieser Datei werden alle Einträge negativ gefiltert. Und normalerweise sollen alle Verbindungen unterbunden werden:
| |
| | |
| Sie können bei Bedarf obige Standardzeile auch durch Folgende ersetzen, jedoch wird dadurch bei zu vielen Verbindungen in kurzer Zeitz eine DoS Angriff möglich (Last des Mailers sowie des Spool-Verzeichnisses). Ein logwatch ist somit wahrscheinlich die bessere Lösung.
| |
| | |
| | |
| === Protokollierung ===
| |
| Entsprechend der Syslog Daemon Konfiguration in der Datei /etc/syslog.conf protokolliert der tcp_wrapper normalerweise in die Datei /var/log/secure.
| |
| | |
| ==== Abgelehnte Verbindung ====
| |
| Das Logging einer abgelehnten IPv4-Verbindung zu einem durch den xinetd überwachten Daytime Dienst sieht wie folgt aus:
| |
| | |
| Das Logging einer abgelehnten IPv4-Verbindung zu einem durch den xinetd überwachten sshd Daemon (auf IPv4 und IPv6 auf Verbindungen wartend) sieht wie folgt aus:
| |
| | |
| | |
| ==== Akzeptierte Verbindung ====
| |
| Das Logging einer akzeptierten IPv4-Verbindung zu einem durch den xinetd überwachten Daytime Dienst sieht wie folgt aus:
| |
| | |
| Das Logging einer akzeptierten IPv4-Verbindung zu einem auf zwei Ports hörenden sshd sieht wie folgt aus:
| |
| | |
| == vsftpd ==
| |
| === Auf IPv6-Adressen lauschen ===
| |
| Editiere die Konfigurationsdatei, üblicherweise /etc/vsftpd/vsftpd.conf, und setze die Option für das ”listen” wie folgt:
| |
| | |
| Mehr ist nicht zu tun.
| |
| | |
| == proftpd ==
| |
| === Auf IPv6-Adressen lauschen ===
| |
| Editiere die Konfigurationsdatei, üblicherweise /etc/proftpd.conf, allerdings ist hier zu beachten, daß dies in der Konfigurationsart virtueller Host nicht 100% logisch ist
| |
| | |
| Mehr ist nicht zu tun.
| |
| | |
| == Andere Daemons ==
| |
| Seit einiger Zeit ist dies meist einfach, suchen Sie einfach nach einer Kommandozeilen-Option oder einer Konfigurationsvariable, um das Lauschen an IPv6-Adressen zu aktivieren. Schauen Sie dazu in den Manual-Seiten des Daemons oder in den entsprechenden FAQs nach. Es kann allerdings durchaus sein, daß sich der Daemon nur an die IPv6-”any”-Adresse (::) binden läßt und kein dediziertes Binden an eine spezielle IPv6-Adresse möglich ist (das hängt von der Unterstützung des Programmierers ab).
| |
| | |
| <noinclude>
| |
| | |
| == Anhang ==
| |
| === Siehe auch ===
| |
| {{Special:PrefixIndex/{{BASEPAGENAME}}}}
| |
| ==== Dokumentation ====
| |
| ==== Links ====
| |
| ===== Projekt =====
| |
| ===== Weblinks =====
| |
| | |
| | |
| [[Kategorie:IPv6]] | |
| | |
| </noinclude>
| |