Transcript IPv6 in Virtualisierungsumgebungen

IPv6 in Virtualisierungsumgebungen
Heiko Wundram | Gehrkens.IT
Warum IPv6 jetzt?
• IPv4-Adressraum läuft aus, (nur) noch 20 /8-er
verfügbar!
• Kunden wollen IPv6 ausprobieren
• Hostinganbieter müssen IPv6 ausprobieren!
• Umstellung jetzt sichert die Zukunftsfähigkeit!
Anbindung (1. Tunneling)
• Transport von IPv6 in IPv4 (RFC 3053, Teredo-Protokoll)
• Vergleichsweise unkomplizierte Möglichkeit, geroutete IPv6Adressen/Netze zu bekommen:
– SixXS (www.sixxs.net), Hurricane Electric (www.he.net)
– Teredo, Anycast 6in4
• Keine Verfügbarkeitszusagen, teilweise kein echtes
Adress“eigentum“, keine SLAs, da diese Angebote
üblicherweise unentgeltlich von Tunnel Brokern bereitgestellt
werden
• Teilweise Abhängigkeit von der aktuellen (mglw.
dynamischen) IPv4-Adresse, „dynamische“ IPv6-Adressen
• (Deutlich) reduzierte MTU durch den Tunnel
• Deutlich erhöhte Ping-Zeiten
Anbindung (2. nativ)
• Transport von IPv6 als gleichberechtigtes Protokoll neben
IPv4
• Provider- oder Uplinkabhängig, Netze/Adressen z.B. als PA
über die RIPE:
– IPv6 über Ethernet, zusammen oder separat von IPv4
– IPv6 über PPP (RFC 5072)
• Verfügbarkeitszusagen, Adresseigentum, SLAs natürlich
möglich, je nach vertraglicher Bindung an Provider
• Aktuell schon bei vielen Colocationprovidern verfügbar
• IPv6 über PPP immer noch kaum verfügbar in Deutschland
• Übliche reduzierte MTU bei PPP-Uplink
Exkurs: SixXS
• Anmeldung bei SixXS erfolgt per Webformular
• Nach erfolgreicher Anmeldung:
– Anbindung eigener Router an PoP über zu installierende Tunnel
(6to4)
– Delegation eines Netzes durch den PoP an den eigenen
Tunnelendpunkt
• SixXS unterstützt zusätzlich bei Anfragen nach PI
Adressraum z.B. über die RIPE
Infrastruktur
• Unabhängig von der Anbindung müssen folgende
Komponenten lokal mglw. aktualisiert werden:
– IPv6-fähige Router für Anbindung des lokalen Netzes über den
gewählten Uplink und zum Router-Advertisement für das lokale
Netz
– Bei „intelligenten“ Switchen, solche, die IPv6-Traffic switchen
(z.B. filtern ältere Extreme Networks Pakete mit „defektem“
Ethernet-Typ)
– DNS-Resolver, die mit AAAA-Records umgehen können
– Bei Bedarf Sicherheitsinfrastruktur (IDS, IPS, etc.), die mit IPv6
umgehen kann
Verteilung (1. separates „LAN“)
• Logische/physikalische Trennung von IPv6- und IPv4Transport
• Benötigt entweder VLAN-fähige oder mehrere
Netzwerkkarten in allen Endgeräten
• Konfigurationsmehraufwand, da zwei interne Netzwerke
konfiguriert und verwaltet werden müssen
• Sicherheitsvorteil, da keine öffentlich gerouteten
Adressen „zufällig“ verteilt werden
Verteilung (2. Dual-Stack)
• Transport von IPv4 und IPv6 über das selbe (Ethernet)Netzwerk
• Benötigt Dual-Stack-fähige Endgeräte
• Konfigurationsaufwand geringer, wenn öffentlich
geroutetes IPv6-Netz dem öffentlich gerouteten IPv4Netz „entspricht“
• Durch IPv6-Autokonfiguration kann es zu „zufällig“
verteilten öffentlichen IPv6-Adressen kommen!
Konfiguration (1. Autokonfiguration)
• Netzmaske <= /64 des internen Netzes erlaubt
Autokonfiguration durch Router-Advertisement
• Durch Autokonfiguration kann in den meisten Fällen eine
gesonderte IP-Konfiguration der Endgeräte entfallen
– Linux ab 2.4.x, FreeBSD ab 4.x
– Windows ab XP
• Verteilung von DNS-Servern, bzw. „pushen“ von
gerouteten Netzen jedoch nicht möglich!
Exkurs: Router-Advertisement
•
Bei Linux-Routern kommt üblicherweise radvd zum Einsatz:
–
•
radvd (www.litech.org/radvd/)
Konfigurationsbeispiel (im Einsatz bei x|encon):
interface eth0 {
AdvSendAdvert on;
AdvManagedFlag on;
AdvOtherConfigFlag on;
AdvDefaultPreference high;
prefix 2a02:790:1:6::/96 {
AdvAutonomous off;
};
};
Konfiguration (2. DHCPv6)
• Bei Netzmaske > /64 des internen Netzes zwingend für
automatische Konfiguration benötigt
• Konfiguration ähnlich wie DHCP für IPv4: dynamische
Leases, statische Leases (z.B. MAC-basiert), PushOptionen
– Linux/FreeBSD benötigen spezielles Client-Programm
– Windows-Client ab Vista integriert
• Verteilung von DNS-Servern/NTP-Servern, pushen von
gerouteten Netzen möglich
• Ersetzt jedoch nicht das Router-Advertisement!
Exkurs: DHCPv6-Implementierungen
• Mehrere Client/Server-Implementierungen für
Linux/FreeBSD/Windows verfügbar:
– Wide-Projekt (wide-dhcpv6.sf.net) (Linux, *BSD)
– Dibbler (klub.com.pl/dhcpv6/) (Linux, Windows)
• Konfiguration von Dibbler, sowohl Client als auch Server,
deutlich einfacher als die von Wide
• Gängige Optionen werden von beiden interpretiert und
umgesetzt
• Andere Betriebssysteme (OpenSolaris) bringen eigene
Clients mit
Exkurs: Dibbler-Server
• Konfigurationsbeispiel (im Einsatz bei x|encon):
iface "eth0" {
t1 1800
t2 3600
option dns-server 2a02:790:1:6::1
class {
accept-only fe80::0216:3eff:fe00:1234
pool 2a02:790:1:6::1000
}
}
Exkurs: Dibbler-Client
• Dibbler-Client kommt mit fast allen Linux-Distributionen
im Paketmanagement mit
• Einfache Konfiguration für Endbenutzer
• Konfigurationsbeispiel (im Einsatz bei x|encon):
strict-rfc-no-routing
iface "eth0" {
ia
option dns-server
}
Xen und IPv6
• Xen selbst ist „nur“ ein Hypervisor, dementsprechend
IPv6-agnostisch
• Virtuelle (Ethernet-)Netzwerkinterfaces von Xen
unterstützen IPv6 „out of the box“
• Aktueller Xen-Kernel ist noch immer auf dem Stand von
Linux 2.6.18, dementsprechend stehen einige IPv6Funktionen noch nicht zur Verfügung
• Aktuelle Xen-Tools sind rudimentär IPv6 Managementfähig
Virtuozzo (OpenVZ) und IPv6
• Erst kommerziell ab Virtuozzo 4.0 verfügbar, OpenVZUnterstützung ab 3.x
• Einbindung von IPv6 in Gast-Jails nur über virtuelle
(Ethernet-)Netzwerkinterfaces (veth) möglich, nicht über
venet
• Aktueller Kernel von OpenVZ ist 2.6.32, volle
Unterstützung für IPv6 + Erweiterungen
• Aktuelle Virtuozzo/OpenVZ-Tools sind rudimentär IPv6
Management-fähig
VMWare und IPv6
• VMWare selbst ist „nur“ eine Art Hypervisor,
dementsprechend IPv6-agnostisch
• Virtuelle (Ethernet-)Netzwerkinterfaces von VMWare
unterstützen IPv6 „out of the box“
• VMWare ist Kernel unabhängig
• Aktuelle VMWare-Tools sind fast vollständig IPv6
Management-fähig
Sicherheit (1. IPv6)
• Jedes Gerät mit IPv6-Unterstützung hat mindestens eine
(lokale) IPv6-Adresse auf jedem Interface!
• Unvermittelte Router-Advertisements können den
Netzbetrieb empfindlich stören
• Router-Advertisements auf mehreren LANs können
Routing-Chaos verursache
• Viele (TCP-/UDP-)Dienste lauschen selbst ohne
eingerichtetes IPv6 auf allen IPv6-Adressen, sind also
über die lokale(n) Adresse(n) lokal erreichbar!
Sicherheit (2. Linux)
• Linux behandelt IPv4 und IPv6 durch unterschiedliche
Firewall-Backends; Standardfirewall für IPv6 ist leer!
• Standardmäßig lauscht Linux auf allen Interfaces nach
Router-Advertisements, mehrere Default-Routen möglich
• Stateful Matching für IPv6 unter Linux ist erst ab 2.6.25
funktional
Sicherheit (3. Xen)
• Xen-Tools besitzen eingebaute Funktionalität um
(rudimentäres) IPv4-Firewalling in den Start-Scripten zu
erledigen; dergleichen fehlt vollständig für IPv6!
• Die Xen-Tools-Dienste (Migration, externes
Management, etc.) hören standardmäßig auch auf IPv6Adressen, sind also offen zugängig über die link-lokale
Adresse
• Alle Interfaces für virtuelle Maschinen müssen auf der
Host-Maschine verfügbar sein, sind also dort auch mit
einer link-lokalen Adresse verfügbar!
Fragen?