Login
Newsletter
Werbung

Do, 5. April 2012, 15:00

Dynamisches DNS-Update im lokalen IPv4/IPv6-Netzwerk

NAT46

Tayga ermöglicht auch den Zugriff von einem System, das nur IPv4 verwendet, auf eine IPv6-Adresse. Dazu ist es aber notwendig, die IPv4 Map-Adresse des IPv6-Rechners zu kennen. Wenn in der Datei /etc/tayga.conf data-dir /var/db/tayga eingetragen wird, kann in der Datei /var/db/tayga/dynamic.map diese Adresse ermittelt werden. Ein Programm, welches named diese Adresse und den Namen des Hosts bekannt gibt, ist nicht erhältlich, aber es ist in ninsd vorgesehen. Damit ninsd die Adressen aus den Pool verarbeitet, muss zusätzlich die Option -m /var/db/tayga/dynamic.map angegeben werden. Die Firewall muss gegebenenfalls angepasst werden. Ein Skript, das die Konfiguration und das Starten der Dienste übernimmt, befindet sich im Paket ninsd. Damit sollte das Aufsetzen des Servers nach den Editieren weniger Variablen und gegebenenfalls deren Anpassung erledigt sein.

ULA

Ein Pendant zu den lokalen IPv4-Adressen (10.0.0.0/24, 192.168.0.0/16 0der 172.16.0.0/12) sind die ULA (Unique Local Unicast)-Adressen. Diese werden unter Einbeziehung einer MAC-Adresse, die zum Aufbau der EUI64 dient, und dem Zeitpunkt der Anforderung gebildet. Solch ein ULA-Präfix kann auf der Seite www.kame.net/~suz/gen-ula.html gebildet und für das interne Netzwerk verwendet werden. Das errechnete Präfix erlaubt es, 65536 Subnetze zu benutzen. Die mit dem ULA-Präfix gebildete Adresse wird, genauso wie deren IPv4-Entsprechungen, nicht im Internet geroutet.

Keine IPv6-Verbindung zur Außenwelt

Auch wenn die Verbindung zur IPv6-Außenwelt verloren gegangen ist, z.B. wegen Wartungsarbeiten am POP des Tunnelanbieters oder eines Ausfalls des (A)DSL-Routers, bleibt das interne IPv6-Netzwerk funktionsfähig, eine Verbindung nach außen ist aber nicht mehr möglich.

Aufbau der IPv6-Adressen

Sehr grob betrachtet gibt es zwei grundsätzliche Adresstypen. Die Adressen, die mit 0 beginnen, wie 0:0:0:0:0:0:0:1 (entspricht 127.0.0.1 bei IPv4), sind lokal für dem jeweiligen Rechner. Ein Zugriff auf diese Adressen ist nur auf diesem Rechner möglich. IPv6-Adressen, die mit F beginnen, besitzen eine lokale Natur. Das heißt, dass sie nur im lokalen Netzwerk gültig sind.

In diesem Bereich sind Adressen mit den Präfix fe80:: angesiedelt, die für Koordinierungszwecke zwischen den verschiedenen Partnern in einen Netzwerksegment dienen. Der Bereich FD3D:: ist für ULA-Adressen reserviert.

Die Adressen, die mit 200 beginnen, sind globale Adressen und können sowohl von außen erreicht werden als auch mit der Außenwelt direkt kommunizieren. Diese Adressen unterteilen sich wiederum in zwei Hauptbereiche. 2001:: sind normale globale Adressen und 2002:: sind Adressen, die mit 6in4 oder Teredo (Microsoft) bzw. Miredo (Posix-Systeme)-Tunnels aufgebaut werden. Der Bereich 2001 hat den Vorteil, dass das Routing sehr einfach ist, die vergebene IP beinhaltet sozusagen Routing-Informationen:

+--+-----+---+--------+--------+--------------------------------+
| 3|  13 | 8 |   24   |   16   |          64 Bit                |
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
|  | ID  |   |  ID    |  ID    |                                |
+--+-----+---+--------+--------+--------------------------------+

FP           = Format Prefix (3 bit) for Aggregatable Global Unicast Addresses
TLA ID       = Top-Level Aggregation Identifier
RES          = Reserved for future use
NLA ID       = Next-Level Aggregation Identifier (ISP)
SLA ID       = Site-Level Aggregation Identifier
INTERFACE ID = Interface Identifier

Diese Tabelle gilt für Kundennetze, bei denen die volle SLA (Subnetz) zur Verfügung gestellt wird (/48-Bereich). Manche Provider werden aber einer Teil der SLA (8 Bit) in Anspruch nehmen, so dass für den Endverbraucher dann 256 Subnetze möglich sind. Die restlichen 64 Bit stellen, so war es vorgesehen, eine universelle Interface-ID dar, die die MAC-Adresse der Schnittstelle beinhaltet, oder eine frei vergebene Adresse wie z.B. 2001:db8:1234::1.

Dieser Aufbau der Adresse hat den Vorteil, dass die in den Routern gespeicherten Routen weniger umfangreich sind als bei IPv4.

Ninsd und andere DNS-Server

Ninsd unterstützt auch andere DNS-Server wie dnsmasq, das den Vorteil besitzt, ressourcenschonend zu sein, und dementsprechend auf viele Heimroutern eingesetzt wird. Die Unterstützung ist dadurch gegeben, dass ein Skript oder Programmname als Parameter angegeben werden kann. Diese externe Komponente kann die über die Standardeingabe erhaltenen Anweisungen umsetzen und ein Server-spezifisches Update vornehmen.

DNS64 wird von dnsmasq nicht unterstützt. Das Updaten von dnsmasq kann z.B. mit einem awk-Skript vorgenommen werden. Ein Beispiel befindet sich im ninsd-Verzeichnis. Für CPE (den Router zum Anschluss an DSL) wird für den Zugriff auf externe IPv4-Systeme von internen IPv4-Rechnern DS-Lite eingesetzt. Dies ist eigentlich die letzte Kompatibilitätsstufe für das Miteinander von IPv4 und IPv6. Dabei ist die WAN-Adresse des CPE eine IPv6-Adresse, IPv4-Nachrichten werden über einen Tunnel zum ISP-Server weitergeleitet.

Beim Einsatz eines CPE, das auf openWRT oder ddWRT basiert, können tayga und totd (ein DNS-Proxy, der die IPv4-Adressen mit einer IPv6-Adresse ergänzt) installiert werden. Damit kann auch solch ein CPE als vollwertiger Server genutzt werden, vorausgesetzt, dass ninsd installiert wurde.

Unbound ist ein weiterer DNS-Server. Er unterstützt nicht DNS64, so dass ein weiterer Helfer (totd) unter Umständen notwendig ist. Das dynamische Update von unbound kann mittels des Dienstprogrammes unbound-control vorgenommen werden. Die Syntax ist einfach und kann aus den Daten, die von ninsd gesandt werden, zusammengebaut werden.

Aufbau des DNS-Proxys mit totd

Bei vielen Anleitungen ist die Konfiguration des DNS-Proxys an die lokale Adresse 127.0.0.1 (erster Nameserver in der Datei /etc/resolv.conf) gebunden. Bei unserem Vorhaben ist dies aber nicht gewünscht. Der DNS-Proxy sollte an allen Netzwerk-Schnittstellen lauschen und Anfragen, die nicht beantwortet werden können, an den eigentlichen DNS-Server weiterreichen. Hierzu stehen zwei Vorgehensweisen zur Verfügung:

  1. Vorgabe der Netzwerk-Schnittstelle
  2. Verwendung einen nicht Standard Port für den Namen-Server

Möglichkeit 2 ist am einfachsten zu realisieren. Dies bedeutet, dass der eigentliche Nameserver nicht am Standard-Port 53 lauschen darf, sondern auf einem anderen, z.B. 54. Totd kann mit praktisch allen DNS-Servern eingesetzt werden. Jeder Server hat seine eigenen Parameter zur Festlegung des Ports, das sollte man in der entsprechenden Dokumentation nachsehen. Totd benötigt nur eine sehr einfache Konfigurationsdatei /etc/totd.conf:

forwarder ::1 port 3553 
prefix 2001:db8:cafe:beef::

Die Zeile forwarder sorgt dafür, dass der eigentliche Nameserver die Anfragen erhält. In diesem Fall würde er auf Port 3553 lauschen. Die zweite Zeile gibt das Präfix zur Bildung der IPv6-Adressen der IPv4-Systeme an. Totd wird von manchen Distributionen als Paket angeboten.

Vor- und Nachteile diverser DNS-Server

Named ist leistungsfähig und unterstützt DNS64, benötigt aber viel Speicher. Unbound ist einfach zu konfigurieren, erzeugt direkt die Einträge für die reverse Auflösung und benötigt weniger Speicher als named, unterstützt aber (offiziell) kein DDNS. DNS64 ist nicht implementiert, dürfte aber in einer zukünftigen Version (aktuell ist 1.4.16) vorhanden sein.

Dnsmasq ist in Bezug auf Speicherverbrauch ein Leichtgewicht. Es unterstützt DHCPv4, aber nicht DHCPv6 und DNS64. Im Hinblick des Einsatzes in einem DSL-Router mit DS-Lite ist dies für externe Adresse nicht notwendig. Das lokale Netzwerk kann vorerst auf IPv4-Basis aufgebaut werden, was allerdings auch mit einigen Nachteilen verbunden ist.

Kommentare (Insgesamt: 3 || Alle anzeigen )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung