IPv6/Dienste: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 12: | Zeile 12: | ||
== Webserver Apache2 (httpd2) == | == Webserver Apache2 (httpd2) == | ||
[[Webserver Apache2 (httpd2)]] | |||
== Router Advertisement Daemon (radvd) == | == Router Advertisement Daemon (radvd) == |
Version vom 28. Dezember 2023, 14:08 Uhr
IPv6/Daemons - Hinweise zu IPv6 kompatiblen Daemonen
Beschreibung
|- | BIND || Berkeley Internet Name Domain (BIND) daemon ”named” || IPv6/BIND |-
Internet super daemon (xinetd)
Webserver Apache2 (httpd2)
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).
Anhang
Siehe auch
Dokumentation
Links
Projekt
Weblinks