Я не работал с IPv6 за исключением туннелирования 4to6 на моем домашнем компьютере с такими вещами, как GoGoNet. Я читал о том, как это работает в целом. NAT не требуется (или не рекомендуется), и каждый клиент использует общедоступный IPv6-адрес, и я понимаю, что брандмауэры продолжаются. Насколько я понимаю, без использования NAT, UAL и получения ARIN для предоставления вам собственного глобального диапазона это будет означать, что адрес ipv6 на всех системах в вашей локальной сети будет из диапазона, предоставленного вашим провайдером. Что произойдет, если вы смените провайдера? Означает ли это, что вам нужно изменить весь диапазон адресов вашей локальной сети?
В типичном магазине окон ipv4 у меня может быть такая ситуация:
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+
Серверы имеют статически назначенные LAN IP-адреса, DNS-серверы должны и другие также, поскольку брандмауэр выполняет переадресацию портов на серверы через IP-адреса, которые вы вводите (по сравнению с именами хостов).
Если бы я хотел настроить это как среду только для ipv6? Будет ли все так же со статически назначенными серверами и dhcpv6 для рабочих станций?
Но тогда, если я переключусь на другого провайдера, будет ли это означать, что мне нужно изменить IP-адрес для всех серверов? Что делать, если у меня 100 серверов? Думаю, я могу использовать dhcpv6 на серверах, но я не видел брандмауэра бизнес-класса, который позволял бы переадресацию портов через имя хоста или внутренние DNS (sonicwall, juniper, cisco и т. Д.), Только локальный IP (по крайней мере для ipv4). И DNS-серверу в любом случае нужны статические IP-адреса.
Также не будет ли это означать, что во время перехода на изменение lan ipv6 ips мои серверы могут отправлять трафик локальной сети через Интернет на мой старый блок, поскольку это больше не локальная сеть? По крайней мере, с технической точки зрения, я понимаю, что вряд ли кто-то так быстро воспользуется старым блоком и что его можно заблокировать на брандмауэре.
Похоже, было бы здорово, если бы каждый получил свой собственный блок ipv6, назначенный perm, но я понимаю, что это сделало бы глобальную таблицу маршрутизации слишком большой.
Обновить Основываясь на ответах ниже, я обновил пример местоположения выше, поэтому это будет эквивалент ipv6?
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+
Собственные системы каждого сайта будут общаться через Link-Local, Site-to-Site будут общаться друг с другом ULA (зашифровано VPN), а мир (включая службы) будет общаться через общедоступные IP-адреса?
Определенно есть некоторые механизмы, которые могут вам помочь.
Для внутреннего трафика LAN между системами в вашей сети существуют уникальные локальные адреса. Думайте о них как о адресах RFC1918; они будут работать только в вашей сети. Вы сможете использовать эти адреса для любых коммуникаций в пределах вашей сети; просто вырезать сети из fd00::/8
и пусть ваши маршрутизаторы начнут рекламировать их.
При обычном развертывании это будет означать, что все ваши узлы имеют (как минимум) 3 адреса IPv6; ссылка-местная fe80::/64
адрес (который может разговаривать только с другими узлами в своем широковещательном домене), уникальный локальный fd00::/8
адрес (который может разговаривать со всем в вашей локальной сети) и публичный адрес.
Теперь это по-прежнему означает, что вы перенумеровываете все, когда меняете ISP (что вы делаете сейчас в любом случае для общедоступных узлов, предполагая, что вы не владеете пространством IPv4), просто вам не нужно беспокоиться обо всех внутренних связь, которая может оставаться на Уникальном Локальном диапазоне.
Это может покрыть ваши опасения, но есть еще предложение NPTv6, для которого в настоящее время существует экспериментальный RFC. Это позволит вам переводить общедоступные префиксы в частные диапазоны на границе сети, что означает отсутствие внутренней перенумерации при смене интернет-провайдеров и возможность беспрепятственно использовать несколько интернет-провайдеров с разными назначенными адресами (постоянно или во время переходного периода для провайдера). изменение).
Для внутренних служб (терминальные серверы, внутренние почтовые серверы, принтеры, веб-прокси и т. Д.) Вы можете использовать локальные адреса сайта в уникальном локальном блоке под fd00: / 8. Это предназначено для создания блока / 48, из которого вы можете вырезать / 64 для отдельных сайтов. Вы можете иметь тысячи сайтов, использующих эту модель, начиная с одного / 64. Серверы и службы, использующие эту схему адресации, будут защищены от смены ISP. Вам необходимо будет туннелировать эти адреса между сайтами, если сайты подключены через Интернет.
ПРИМЕЧАНИЕ. Уникальные локальные блоки вызывают те же проблемы, что и блоки частных адресов IPv4. Однако, если вы рандомизируете 40 бит, следующие за FD
, вероятность столкновения маловероятна.
Клиентским машинам не нужны согласованные IP-адреса в Интернете. Существуют параметры конфиденциальности, которые будут периодически генерировать новые адреса, чтобы отслеживать клиентов по IP-адресу. Если на ваших маршрутизаторах работает служба radvd (Router Advertisement Daemon), ваши клиенты могут генерировать свой собственный адрес. (Объявления маршрутизатора идентифицируют шлюз и могут предоставить список DNS-серверов.) IPv6 с radvd
заменяет базовые службы DHCP. Нулевую конфигурацию можно использовать, чтобы разрешить обнаружение многих служб, которые DHCP будет использовать для объявления. Адреса клиентских машин должны находиться в блоках адресов / 64, отличных от используемых на серверах, доступных в Интернете.
DMZ (демилитаризованная зона) - это место, где должны находиться ваши серверы и службы, доступные в Интернете. Эти адреса, вероятно, изменятся при смене провайдера. Они могут находиться в одном / 64, что упростит изменение адресов. Поскольку IPv6 требует поддержки нескольких адресов, вы можете подключить своего нового поставщика услуг Интернета и выполнить переключение упорядоченным образом перед отключением исходного соединения с поставщиком услуг Интернета.
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
Вы можете использовать любые значения, которые хотите различать между DMZ и зонами вашего хоста. Вы можете использовать 0 для DMZ, как я сделал для сайта 2 выше. Ваш интернет-провайдер может предоставить меньший блок, чем / 48. RFC предполагают, что они могут подразделить / 64 и выделить / 56. Это ограничит диапазон, который вы можете выделить для / 64.