IPv6 ohne nat aber wie sieht es mit einem isp wechsel aus?


12

Ich habe nicht mit IPv6 außerhalb von 4to6-Tunneln auf meinem Heim-PC mit Dingen wie GoGoNet gearbeitet. Ich habe gelesen, wie es allgemein funktioniert. Kein NAT erforderlich (oder empfohlen) und jeder Client verwendet eine öffentliche IPv6-Adresse und ich verstehe die fortgesetzte Verwendung von Firewalls. Ohne die Verwendung von NAT, UAL und ARIN, um einen eigenen globalen Bereich zu erhalten, würde dies nach meinem Verständnis bedeuten, dass die IPv6-Adresse auf allen Systemen in Ihrem LAN aus einem Bereich stammt, der von Ihrem ISP bereitgestellt wird. Was würde passieren, wenn Sie Ihren ISP ändern? Würde das bedeuten, dass Sie Ihren gesamten LAN-Adressbereich ändern müssen?

In einem typischen Ipv4-Windows-Shop könnte ich eine Situation wie die folgende haben:

Site1 Lan IPs: 192.168.1.0/24
Site2 Lan IPs: 10.0.0.0/24
Site1 Public IP: 11.12.13.1/29 (11.12.13.1 - 11.12.13.5 usable)
Site2 Public IP: 20.30.40.1/29 (20.30.40.1 - 20.30.40.5 usable)
Site-to-site VPN via firewalls

Site1:                                 Lan IP,         Public IP:Port
Hardware firewall/router             - 192.168.1.1,    11.12.13.1
Windows AD DC server (AD DNS server) - 192.168.1.10
Windows Exchange (email)             - 192.168.1.11,   11.12.13.2:25+443
Windows RDS (term server)            - 192.168.1.12,   11.12.13.3:3389
Workstations (via DHCP)              - 192.168.1.100+

Site2:
Hardware firewall/router             - 10.0.0.1,       20.30.40.1
Windows AD DC server (AD DNS server) - 10.0.0.10
Windows IIS (webserver)              - 10.0.0.11,      20.30.40.2:80
Workstations (via DHCP)              - 10.0.0.100+

Die Server haben statisch zugewiesene LAN-Adressen, die DNS-Server müssen und die anderen auch, da die Firewall die Portweiterleitung an Server über die von Ihnen eingegebenen IP-Adressen (gegenüber Hostnamen) durchführt.

Nun, wenn ich dies als IPv6-Umgebung einrichten wollte? Wäre bei statisch zugewiesenen Servern und dhcpv6 für Workstations noch alles beim Alten?

Aber wenn ich dann zu einem anderen ISP wechsle, muss ich dann die IP-Adresse für alle Server ändern? Was ist, wenn ich 100 Server habe? Ich vermute, ich kann dhcpv6 auf den Servern verwenden, aber ich habe keine Firewall der Biz-Klasse gesehen, die die Portweiterleitung über den Hostnamen oder interne DNS (Sonicwall, Wacholder, Cisco usw.) nur über die lokale IP (zumindest für IPv4) zulässt. Und der DNS-Server benötigt trotzdem statische IPS.

Bedeutet das nicht auch, dass meine Server während des Übergangs von LAN-IPv6-IPs möglicherweise LAN-Verkehr über das Internet an meinen alten Block senden, da dieser nicht mehr lokal ist? Zumindest technisch gesehen ist es unwahrscheinlich, dass jemand den alten Block so schnell verwendet und dass er auf der Firewall blockiert werden kann.

Ich höre mich an, als ob es großartig wäre, wenn jeder seinen eigenen perm zugewiesenen ipv6-Block bekommen würde, aber ich verstehe, dass dies die globale Routingtabelle unbrauchbar groß machen würde.

Aktualisieren Aufgrund der folgenden Antworten habe ich den obigen Beispielspeicherort aktualisiert. Dies wäre also das IPv6-Äquivalent.

Site1 ULA: fd80::192:/64
Site2 ULA: fd80::10:/64
Site1 Public IP: 2000:1112:1301::/48
Site2 Public IP: 2000:2030:4001::/48
Site-to-site VPN via firewalls

Site1:                       Link-Local, ULA,            Public
Hardware firewall/router   - fe80::1,    fd80::ABCD:1,   2000:1112:1301::1
Windows AD DC server (DNS) - fe80::10,   fd80::ABCD:10,  2000:1112:1301::A
Windows Exchange (email)   - fe80::11,   fd80::ABCD:11,  2000:1112:1301::B
Windows RDS (term server)  - fe80::12,   fd80::ABCD:12,  2000:1112:1301::C
Workstations (via DHCP)    - fe80::100+, fd80::ABCD:1xx, 2000:1112:1301::10+

Site2:                       Link-Local, ULA,            Public
Hardware firewall/router   - fe80::1,    fd80::ABCD:2,    2000:2030:4001::1
Windows AD DC server (DNS) - fe80::10,   fd80::ABCD:20,   2000:2030:4001::A
Windows IIS (webserver)    - fe80::11,   fd80::ABCD:21,   2000:2030:4001::B
Workstations (via DHCP)    - fe80::100+, fd80::ABCD:2xx,  2000:2030:4001::10+

Jedes standorteigene System würde über Link-Local kommunizieren, Site-to-Site würde miteinander kommunizieren.

Antworten:


10

Es gibt definitiv einige Mechanismen, die Ihnen hier weiterhelfen.

Für den internen LAN-Verkehr zwischen Systemen in Ihrem Netzwerk gibt es eindeutige lokale Adressen. Stellen Sie sie sich wie RFC1918-Adressen vor. Sie funktionieren nur in Ihrem Netzwerk. Sie können diese Adressen für jede Kommunikation innerhalb Ihrer Netzwerkgrenzen verwenden. Schneiden Sie einfach einige Netze ab fd00::/8und lassen Sie Ihre Router damit beginnen, sie zu bewerben.

In einer normalen Bereitstellung bedeutet dies, dass alle Ihre Knoten (mindestens) 3 IPv6-Adressen besitzen. Eine verbindungslokale fe80::/64Adresse (die nur mit anderen Knoten in ihrer Broadcast-Domäne kommunizieren kann), eine eindeutige lokale fd00::/8Adresse (die mit allem in Ihrem LAN kommunizieren kann) und eine öffentliche Adresse.

Dies bedeutet weiterhin, dass Sie beim Ändern von ISPs die gesamte Nummer neu vergeben (was Sie jetzt sowieso für öffentlich adressierbare Knoten tun, vorausgesetzt, Sie besitzen keinen IPv4-Speicherplatz), nur dass Sie sich nicht um den gesamten internen Speicher kümmern müssen Kommunikation, die im Unique Local-Bereich verbleiben kann.

Das könnte Ihre Bedenken abdecken - aber es gibt auch den NPTv6-Vorschlag, für den es derzeit einen experimentellen RFC gibt . Dies würde es Ihnen ermöglichen, die öffentlichen Präfixe in die privaten Bereiche am Netzwerkrand zu übersetzen, was bedeutet, dass beim Ändern von ISPs keine interne Umnummerierung erfolgt und dass mehrere ISPs mit unterschiedlichen zugewiesenen Adressen nahtlos verwendet werden können (entweder permanent oder während einer Übergangszeit für einen Anbieter Veränderung).


1
+1 - Die einfache Tatsache ist jedoch, dass Sie für ein kleines Heimnetzwerk nur die lokalen Linkadressen verwenden fe80::/64und die von Ihrem ISP zugewiesenen IP-Adressen keine Rolle spielen. Für ein Rechenzentrum war der Wechsel von ISPs schon immer eine große Aufgabe, daher gibt es auch dort kaum Änderungen.
Mark Henderson

1
Bei Verwendung von fd00 :: / 8 (ULA) soll ein semi-random / 48-Adressblock generiert werden. Sie können zB sixxs.net/tools/grh/ula verwenden , um einen Block von ULA-Adressen mit einem standardkonformen Algorithmus zu generieren. Verwenden Sie die ULA-Adressen für die interne Kommunikation (Dateiserver usw.) und für Standort-zu-Standort-VPN-Tunnel und verwenden Sie die öffentlichen Adressen, um auf das Internet zuzugreifen. Dann müssen Sie beim Ändern von ISPs (wie lokal gehosteten Websites und den Endpunkten der VPN-Tunnel, aber nicht allen Firewall-Richtlinien für Ihren ULA-Adressraum) nur die wirklich öffentlichen Dienste neu nummerieren
Sander Steffann

Ah, ok, ich habe nicht nur an mehrere IPv6-Adressen pro Host gedacht. Ich habe das Beispiel aktualisiert und mein Verständnis für einen entsprechenden Satz für ipv6 hinzugefügt. Lassen Sie mich wissen, ob ich die richtige Schreibweise habe. Klingt auch so, als ob VPN-Setups sehr einfach wären, wenn die Firewall nur Daten in der UAL verschlüsseln müsste. Werde mich auch über das NPTv6-Zeug informieren.
Halfdone

6

Für interne Dienste (Terminalserver, interne Mailserver, Drucker, Webproxys usw.) können Sie lokale Adressen der Site in einem eindeutigen lokalen Block unter fd00: / 8 verwenden. Dies ist so konzipiert, dass ein / 48-Block generiert wird, aus dem Sie / 64s für einzelne Sites herausarbeiten können. Mit diesem Modell können Sie Tausende von Standorten von einem einzigen Standort aus erreichen. Server und Dienste, die dieses Adressierungsschema verwenden, sind vor einer Änderung des Internetdienstanbieters geschützt. Sie müssen diese Adressen zwischen Standorten tunneln, wenn die Standorte über das Internet verbunden sind.

ANMERKUNG: Bei eindeutigen lokalen Blöcken treten dieselben Probleme auf wie bei den privaten IPv4-Adressblöcken. Wenn Sie jedoch die folgenden 40 Bits zufällig auswählen FD, ist es sehr unwahrscheinlich, dass eine Kollision auftritt.

Client-Computer benötigen keine konsistenten IP-Adressen im Internet. Es gibt Datenschutzoptionen, die regelmäßig neue Adressen generieren, um die Verfolgung von Clients nach IP-Adressen zu unterbrechen. Wenn Ihre Router einen radvd-Dienst (Router Advertisement Daemon) ausführen, können Ihre Clients ihre eigene Adresse generieren. (Routerankündigungen identifizieren das Gateway und können eine Liste von DNS-Servern bereitstellen.) IPv6 radvdersetzt grundlegende DHCP-Dienste. Zero Config kann verwendet werden, um die Erkennung vieler Dienste zu ermöglichen, für deren Ankündigung DHCP verwendet wird. Die Adressen der Client-Computer sollten sich in anderen / 64-Adressblöcken befinden als die von Ihren im Internet zugänglichen Servern verwendeten.

In der DMZ (De-Militarized Zone) sollten sich die Server und Dienste befinden, auf die Sie über das Internet zugreifen können. Diese Adressen werden sich wahrscheinlich ändern, wenn sich Ihr ISP ändert. Diese können sich innerhalb eines einzelnen / 64 befinden, wodurch das Ändern der Adressen einfacher wird. Da IPv6 Unterstützung für mehrere Adressen erfordert, können Sie Ihren neuen ISP verbinden und die Umstellung ordnungsgemäß durchführen, bevor Sie die ursprüngliche ISP-Verbindung trennen.

Unique local block: fd33:ab:de::/48
Site 1:  fd33:ab:de:1::/64
Site 2:  fd33:ab:de:2::/64

Site 1 /48: 2000:1112:1301::/48
Site 1 DMZ: 2000:1112:1301:1:/64    (set on servers)
Site 1 Hosts: 2000:1112:1301:2:/64  (via radv)

Site 2 /48: 2000:2030:4001::/48
Site 2 DMZ: 2000:2030:4001::/64
Site 2 Hosts: 2000:2030:4001:2:/64

Sie können alle Werte verwenden, die Sie zwischen der DMZ und Ihren Hostzonen unterscheiden möchten. Sie könnten 0 für die DMZ verwenden, wie ich es für Site 2 oben getan habe. Ihr ISP bietet möglicherweise einen kleineren Block als a / 48 an. Die RFCs schlagen vor, a / 64 zu unterteilen und / 56s zuzuweisen. Dies würde den Bereich einschränken, den Sie für die Zuweisung von / 64s haben.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.