Для проверки готовности локальной офисной сети к возможности перехода на протокол IPv6 мною был организован испытательный стенд на основе сервера с FreeBSD, являющийся шлюзом для доступа в IPv6 интернет и сервером популярных сетевых ресурсов (WEB, eMail, FTP). Выбор FreeBSD обусловлен наличием уже существующей виртуальной машины с этой системой. Далее я немного расскажу как всё было настроено (не в даваясь в теоретические подробности построения и адресации IPv6) и попытаюсь обрисовать ситуацию о готовности существующих систем и программ к использованию с IPv6 на примере тех сервисов, которые мне удалось протестировать, как со стороны клиента, так и со стороны сервера. Эксперименты активно проводились в период месяц "до" и месяц "после" "Дня IPv6" 8 июня 2011, поэтому сейчас ситуация с поддержкой в некоторых программах может измениться в лучшую сторону.
Цель эксперимента
Проверить совместимость используемого программного обеспечения с сервисами работающими по IPv6;
Добиться максимально прозрачности для пользователя. В идеале, конечный абонент не должен производить никакие настройки, чтобы попадать в IPv6 часть интернета через организованный шлюз.
Эксперимент был проведён в локальной офисной сети на 100-150 компьютеров с Win7, плоское адресное пространство, DHCP и DHS сервера на базе Win2003Server, доступ в интернет NAT или VPN подключение, Windows AD не используется. В качестве сервера на котором планировалось производить все настройки FreeBSD8.1 в VirtualBox, host-машина - персональный компьютер на Win7.
Чтобы получить доступ к IPv6 части интернету был использован туннельный брокер www.tunnelbroker.net. Как зарегистрироваться и получить префиксы, настроить автообновление и про другие полезные вещи можно прочитать тут - version6.ru/he.net/howto.
Для работы были получены следующие префиксы:
2001:470:19:47::/64 - первоначально выданный при регистрации туннеля, его использовать не будем;
2001:470:f9e7::/48 - дополнительно выделенный с большим адресным пространством. Здесь следует поэкспериментировать, потому что не для каждой точки присоединения можно дополнительно выделить префикс /48, для некоторых будет получен ответ что операция невозможна;
2001:470:18:47::2/64 - наш стыковочный адрес;
2001:470:18:47::1/64 - шлюз по умолчанию.
Таким образом мы имеем большое адресное пространство, чтобы гибко его делить между клиентскими компьютерами и серверным оборудованием.
Из приведённой схемы видно что:
2001:470:f9e7:3::/64 - выделено для локальной сети со шлюзом 2001:470:f9e7:3::1/64;
2001:470:f9e7:1::/64 - стыковочная сеть между шлюзом локальной сети и шлюзом IPv6 интернет. На адресах, в идеологии IPv6, экономить не принято - поэтому префикс тоже /64.
Настроим IPv6 шлюз на Win7 для работы с туннельным брокером
Примеры настройки доступа через туннель можно получить при создании туннеля, просто открыв вторую вкладку в режиме управления туннелем на www.tunnelbroker.net. Выбор довольно большой, включая cisco и juniper. Для своих целей я использую следующий CMD скрипт:
@ECHO OFF
REM Выключаем не нужные нам протоколы
netsh interface teredo set state disabled
netsh interface 6to4 set state disabled
REM Удаляем туннельный интерфейс если он уже был
netsh interface ipv6 delete interface "IP6Tunnel"
REM Ищем текущий адрес подключения на интерфейсе с именем VPN
REM На интерфейсе должен быть белый адрес.
REM В моём случае это адрес PPTP интерфейса
FOR /F "tokens=5" %%i IN ('netsh interface ip show ipaddress VPN level^=normal ^| find "infinite"') DO CALL :IP6TUNNELUP %%i
GOTO :CONT
GOTO :END
REM Обновляем сведения о туннеле
:IP6TUNNELUP
curl -k "https://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=%1&pass=<мой пароль полученный на tunnelbroker.net>&user_id=<мой пользователь полученный на tunnelbroker.net>&tunnel_id=<мой идентификатор туннеля>"
REM Разрешаем маршрутизировать на туннельном интерфейсе
netsh interface ipv6 set interface IP6Tunnel forwarding=enabled
REM Устанавливаем стыковочный адрес
netsh interface ipv6 add address IP6Tunnel 2001:470:18:47::2
REM Настраиваем IPv6 маршрут по умолчанию
route delete ::/0
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:18:47::1 publish=yes
REM Разрешаем маршрутизировать на интерфейсе в сторону FreeBSD шлюза
netsh interface ipv6 set interface interface=lan0 forwarding=enabled
REM Добавляем маршруты на интерфейс в сторону FreeBSD шлюза
netsh interface ipv6 set route interface=lan0 prefix=2001:470:f9e7:1::/64 publish=yes
netsh interface ipv6 set route interface=lan0 prefix=2001:470:f9e7:3::/64 publish=yes
:END
После этого мы должны как минимум пинговать ipv6.google.com:
ping ipv6.google.com
Обмен пакетами с ipv6.l.google.com [2a00:1450:4010:c00::69] с 32 байтами данных:
Ответ от 2a00:1450:4010:c00::69: время=705мс
Ответ от 2a00:1450:4010:c00::69: время=701мс
Время отклика многовато, но скорость хорошая. Здесь можно и нужно экспериментировать с различными брокерами и точками входа до них.
Следует заметить что Windows 7 и сама по себе может выступать в качестве шлюза для локальной сети, для этого необходимо разрешить маршрутизацию, объявление маршрута по умолчанию и добавить маршрут который необходимо раздавать в сеть (для понимания процесса настройки вполне достаточно контекстной подсказки netsh). Например, если мы хотим в локальной сети раздавать адреса с префиксом 2001:470:f9e7:2::/64 и маршрутизатором 2001:470:f9e7:2::1/64:
После таких настроек, на всех компьютерах где не отключен протокол IPv6, будет добавлен IPv6 шлюз по умолчанию 2001:470:f9e7:2::1/64 и они получат адреса из сети 2001:470:f9e7:2::/64.
Всё стандартно, команды для IPv6, соответственно, имеют в названии "ipv6" строчку, а для интерфейсов указываем тип не "inet", а "inet6".
Чтобы о нашем маршрутизаторе узнали другие компьютеры в сети нам нужно о себе объявить, для чего используем демон radvd, который ставится из портов, или можно аналогичный по функционалу rtadvd - родной FreeBSD. В radvd можно настроить механизм объявления о DNS серверах - www.ietf.org/rfc/rfc6106.txt - в одном конфигурационном файле вместе с объявлением маршрутов, поэтому его и используем.
Из изменений - добавили только наши префиксы и DNS, остальное оставили как было в установленном с утилитой примере.
После настройки всех интерфейсов мы должны пинговать ipv6.google.com с FreeBSD шлюза. Все утилиты для работы IPv6 на FreeBSD, заканчиваются цифрой "6".
#ping6 ipv6.google.com
PING6(56=40+8+8 bytes) 2001:470:f9e7:1::2 --> 2a00:1450:4010:c00::67
16 bytes from 2a00:1450:4010:c00::67, icmp_seq=0 hlim=49 time=699.042 ms
16 bytes from 2a00:1450:4010:c00::67, icmp_seq=1 hlim=49 time=697.743 ms
#traceroute6 ipv6.google.com
traceroute6 to ipv6.l.google.com (2a00:1450:4010:c00::67) from 2001:470:f9e7:1::2, 64 hops max, 12 byte packets
1 vi-host-w7.ipv6.local. 0.601 ms 0.493 ms 0.475 ms
2 2001:470:18:47::1 362.289 ms 362.791 ms 362.885 ms
3 gige-g3-13.core1.hkg1.he.net 359.731 ms 365.100 ms 359.570 ms
4 google3-10g.hkix.net 360.840 ms 361.714 ms 365.369 ms
Когда демон radvd запущен для анонса нашего маршрутизатора и маршрутов с ним ассоциированных, все компьютеры в сети у которых не отключен протокол IPv6 и автоматическая конфигурация адресов - www.ietf.org/rfc/rfc2462.txt - должны получить адрес из сети 2001:470:f9e7:3::/64 и если на них реализована поддержка RFC6106, то и адрес DNS 2001:470:f9e7:1::2. Для Windows7 протокол IPv6 включен по умолчанию и адрес она получит, а вот получение адреса DNS пока не реализовано, текущее положение с поддержкой IPv6 в различных ОС можно смотреть на вики.
Можно увидеть, что основной шлюз здесь представлен локальный канальным адресом, с указанием номера интерфейса через который он доступен %28.
Как проверять если не работает в Windows 7 (в скобках команды для FreeBSD)
ping (ping6), tracert (traceroute6); .
Смотрим выданный IPv6 адрес - ipconfig (ifconfig);
Смотрим таблицу соседей (аналог ARP в мире IPv4) - netsh int ipv6 show ne (ndp -a);
Смотрим таблицу маршрутизации - route print или netsh int ipv6 show route (netstat -r).
В получившейся конфигурации мы используем параллельно IPv6 и IPv4 протоколы на одном интерфейсе, то есть так называемый dual-stack режим, один из рекомендуемых механизмов перехода, который позволяет одновременно обращаться как к IPv6 так и к IPv4 ресурсам по родному для них протоколу.
DNS
Используемый в сети сервер на основе Win2003Server не поддерживает записи AAAA, поэтому мы не используем его как сервер имён для работы с IPv6, а просто делегируем необходимые зоны на FreeBSD шлюз где и настроим DNSv6. Настройка делегирования не составляет никаких проблем, потому что ничего специфичного IPv6 в этом случае не используется. Кроме того, так как Windows 7 не получает IPv6 адрес DNS, по причинам описанным выше, а DHCPv6 мы не используем данный подход обеспечит нам правильное определение адреса IPv6, пусть даже и через промежуточный IPv4 only DNS.
Настроим на FreeBSD. В /etc/namedb/named.conf добавим:
listen-on {
127.0.0.1;
192.168.137.1;
10.0.2.64;
};
listen-on-v6 {
::1;
any;
};
zone "ipv6.local." {
type master;
file "/etc/namedb/master/ipv6.local";
};
zone "7.e.9.f.0.7.4.0.1.0.0.2.ip6.arpa." {
type master;
file "/etc/namedb/master/f9e7.470.2001.ip6.arpa";
};
Для прослушивания IPv6 надо добавить "listen-on-v6". Описание обратной зоны формируется в "ip6.arpa." и разбивается не по октетам, а по 4 бита, вследствие чего и потому что адрес IPv6 длиннее сам по себе, описание адресов в зоне получается заметно больше чем для адреса IPv4.
/etc/namedb/master/ipv6.local
$ORIGIN ipv6.local.
$TTL 3h
@ IN SOA @ admin.ipv6.local. 2011041212 1d 12h 1w 3h
@ IN NS @
@ IN AAAA 2001:470:f9e7:1:0:0:0:2
nsv4 IN A 10.0.2.64
@ IN MX 10 @
vi-host-w7 IN AAAA 2001:470:f9e7:1:0:0:0:1
ns IN AAAA 2001:470:f9e7:3:0:0:0:1
/etc/namedb/master/f9e7.470.2001.ip6.arpa
$ORIGIN 7.e.9.f.0.7.4.0.1.0.0.2.ip6.arpa.
$TTL 3h
@ IN SOA ns.ipv6.local. admin.ipv6.local. 2011042812 1d 12h 1w 3h
IN NS ns.ipv6.local.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR vi-host-w7.ipv6.local.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ipv6.local.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0 IN PTR ns.ipv6.local.
Что удалось протестировать
WEB http(s) - поддерживается в полной мере как со стороны клиентов так и серверов, наверное самая поддерживаемая платформа проблем с которой не возникло, масса клиентов от самых популярных до консольных что попали мне в руки справились с адресацией IPv6. Со стороны сервера настраивался Apache, использование IPv6 адреса реализовано в тех же директивах, просто сам IPv6 адрес надо брать в квадратные скобки. Всё это подробно есть в документации к серверу, в частности про директиву "Listen" httpd.apache.org/docs/2.0/bind.html;
FTP - со стороны серверов поддержка представлена для широко используемых решений, тестировал для ftpd, proftpd, vsftpd, есть особенности, например, невозможность работать в одном процессе для IPv6 и IPv4, но это всё решаемо и описано в документации, например для vsftpd
# This directive enables listening on IPv6 sockets. To listen on IPv4 and IPv6
# sockets, you must run two copies of vsftpd with two configuration files.
# Make sure, that one of the listen options is commented !!
listen_ipv6=YES
inted также работает с IPv6 для чего есть записи о протоколах tcp6 и udp6.
С клиентами дела уже хуже, реализованные как отдельные клиенты: консольные (поставляемый с Windows), Explorer, FileZilla с задачей справляются. Клиенты реализованные в файловых менеджерах большей частью не готовы, например, Far Мanager не смог подключиться;
ЕMAIL - ситуация такая же как и с FTP - сервера готовы для работы, популярные клиенты тоже готовы, но некоторые, в достаточной мере известные - Сlaws Mail, например, не справились. Для dovecot IPv6 адреса пишутся с тем же директивами только в квадратных скобках:
# A space separated list of IP or host addresses where to listen in for
# connections. "*" listens in all IPv4 interfaces. "[::]" listens in all IPv6
# interfaces. Use "*, [::]" for listening both IPv4 and IPv6.
JABBER и другие IM - в клиентах и серверах нашёл только один, от одного производителя Spark (клиент) и OpenFire (сервер). Больше ни один клиент не поддерживает, ни с помощью плагинов, вообще никак. OpenFire настраивается через WEB, там разницы между IPv6 и IPv4 адресами не делается;
PROXY на SQUID также работает, но не поддерживается прозрачное проксирование, в остальном всё отлично. Адреса IPv6 обрабатываются наравне с IPv4 без каких либо дополнительных условий. Обзор SQUID для IPv6 wiki.squid-cache.org/Features/IPv6. Браузеры умеющие работать с IPv6 WEB справились и с IPv6 PROXY. Proxy это ещё наверное один из самых простых способов получить доступ из IPv6 only сети в сеть IPv4.
В целом базовые возможности протокола, присутствуют во всех протестированных ОС: Windows, Linux, FreeBSD - получение адресов, автоконфигурирование, вывод таблицы соседей, маршрутизация, всё это настраивается и может быть отключено. В Windows, для большинства настроек, это надо делать через консольный интерфейс netsh, в графической интерфейсе большей части настроек нет. Сетевые утилиты ping, traceroute, ssh, telnet, nslookup, также отлично работают. Для *BSD версии утилит IPv6 имеют названия с цифрой "6" на конце, например ping6. В файлах настройках для утилит, как правило, изменения минимальные либо добавляется суффикс с цифрой "6", либо в тех же директивах просто используется нужный IPv6 адрес как есть либо в скобках [].
В Windows, начиная с VISTA, IPv6 включен по умолчанию, включены два механизма перехода TEREDO и 6to4, также присутствует возможность создание туннелей и работа Windows в режиме маршрутизатора IPv6 причём не ограничено по количеству интерфейсов, как это сделано в IPv4 стеке. Однако отдельные включенные части IPv6 могут друг другу мешать, если включен TEREDO, то трафик будет идти именно так, а не через настроенный вручную туннель. Также команда route может не всегда корректно обработать маршрут IPv6, то есть данные не всегда совпадают с тем что можно получить используя netsh int ipv6 show route.
В итоге на персональных компьютерах настраивать ничего не пришлось, единственное для тех кто выключил поддержку IPv6, должен был включить её обратно. Получая родной IPv6 адрес Windows стремится использовать именно его.
К сожалению многое протестировать не удалось, но и из того что удалось можно сделать заключение что IPv6 это уже насущная действительность и планировать переход надо начинать уже сегодня, чтобы не отстать.
Из того что стоит обязательно прочитать: Найэл Ричард Мэрфи, Дэвид Мэлоун. "IPv6.Администрирование сетей". Не новая, не очень удачный перевод, но актуальная, то с чего стоит начать.
P.S. В данный момент всё выключено, так что поработать с описанными ресурсами, к сожалению, не получится.
