IPv6 — он рядом. Часть 1

Сегодня идет множество дискуссий насчет сроков по внедрению IPv6 везде и всюду. Но очевидно одно: без телодвижений крупных компаний ничего не выйдет. Google уже использует IPv6, существуют сети, которые предоставляют IPv6, в том числе некоммерческие.
В этом посте я хотел бы рассказать не только как приобщиться к миру IPv6, но и некоторые тонкости, связанные с ним, о которые мне пришлось споткнуться.
В данном случае рассматривается не самый тривиальный сценарий настройки, в котором используется домашний сервер и вы полностью распоряжаетесь выделенным вам адресным пространством.

Про нужность протокола IPv6, про нехватку адресов IPv4 писалось сотни раз. Я не буду сто первым, почитайте сами.

Дайте мне новые интернеты!

А кто их даст? — спросите вы? Но не все так плохо, так как существуют компании, которые предоставляют доступ к IPv6 совершенно бесплатно, через туннель поверх IPv4 соединения. То есть вы получаете «завернутый» трафик IPv6 по вашему существующему IPv4 соединению.
Вот неполный список таких добрых компаний:

• Hurricane Electric (у нее много сервисов, нас в первую очередь tunnelbroker.net)
• Freenet6 (удобно для тех, кто хочет «в один клик», также полезно для пользователей за NAT-ом)
• SixXS (тоже популярная сеть, но про нее ничего не знаю)

Не сочтите за пиар, но в дальнейшем будет рассматриваться Hurricane Electric, так как я работал именно с ним и он помимо туннелей предоставляет много чего еще полезного.

Прежде чем начать

Пусть у вас есть:
1) Доступ в IPv4 интернет и статический белый IP адрес
2) Домашний сервер с установленным Linux (показано на примере Debian)
3) Клиентские машины (Windows, Linux, Mac — не важно)
Позже этот список будет расширен, но для минимальной конфигурации достаточен.

Регистрируетесь на TunnelBroker.net ничего заумного тут нет, но не кидайтесь сразу создавать туннель, успеете.

Выберите сервер, для этого в помощь Looking Glass, он вам попингует ваш сервер с серверов, предоставляющих туннели. Чем короче пинг — тем лучше, можно еще traceroute посмотреть и выбрать вариант с меньшим числом маршрутизаторов по пути.

Начнем

Теперь время настроить туннель и получить доступ к IPv6 на вашем домашнем сервере.

Зарегистрируйте туннель. Для этого выберите Create Regular Tunnel в личном кабинете TunnelBroker, введите IPv4 адрес вашего сервера, укажите сервер, который вы выбрали.
Ваш конец будет сразу протестирован на получение пакетов с протоколом номер 41, доступность которого необходима для работы туннеля.



Обратите внимание, что для быстрого старта уже готовы примеры настроек для разных операционных систем (1 на скриншоте), ваш клиентский IPv6 адрес отличается (2 от 3) по префиксу от подсети Routed /64 одной цифрой, часто это не замечают. А также можете сразу заполнить rDNS (4) как на скриншоте, пока будет обновляться вы успеете настроить все остальное.

Проверьте работу туннеля. Для этого скопируйте конфигурацию для Linux-route2 и выполните в терминале из под root. Попробуйте ping6 ipv6.google.com, если заработало, поздравляю, туннель работает. Можно для достоверности попинговать ваш Client IPv6 address из Looking Glass (который использовали при выборе сервера).

Сделайте его статическим. В мире IPv6 навсегда отпала потребность в динамических адресах, поэтому значения, которые вы видели никогда не поменяются (если конечно у вас статический IPv4 адрес, да даже если сменится, то поменяется только Client IPv4 address).
Откройте в текстовом редакторе (например nano) файл /etc/network/interfaces (может быть другим, зависит от дистрибутива, но это так на Debian, Ubuntu и многих других)

Добавьте в конец файла описание нового интерфейса примерно так:

auto  he-ipv6
iface he-ipv6 inet6 v4tunnel
  address 2001:470:abcd:abcd::2
  netmask 64
  gateway 2001:470:abcd:abcd::1

  endpoint 216.11.22.33
  local 11.22.33.44
  ttl 255

Назначение полей:
1) address — ваш Client IPv6 address
2) gateway — ваш Server IPv6 address
3) endpoint — ваш Server IPv4 address
4) local — ваш Client IPv6 address

Теперь при перезагрузке у вас туннель будет подниматься автоматически.

MTU-related butthurt prevention

Но не спешите перезагружать сервер, так как туннель у вас запущен (когда вы его проверяли). Теперь нужно проверить такую вещь как MTU. MTU — это максимальный размер пакета, передаваемого над канальным уровнем модели OSI. В случае нашего туннеля этот размер совпадает с максимальным размером пакета IPv6 поверх туннеля. В силу того, что происходит инкапсуляция пакетов IPv6 в пакеты IPv4, к нему добавляются заголовки пакетов IPv4, следовательно MTU туннеля (максимум 1480) как минимум на 20 меньше MTU интерфейса, по которому вы выходите в интернет по IPv4 (как правило это 1500, но может быть меньше). Если у вас работает

ping6 ipv6.google.com

Но вылетает с ошибкой

wget -6 -O /dev/null http://he.net

Тогда 99% — проблема именно с MTU.

Вычисляем MTU. Так как IPv4 пакеты можно фрагментировать, то есть если он слишком большой для передачи по какому-нибудь каналу, то он может быть порезан на кусочки. Однако к каждому такому куску добавляются заголовки и эффективность сильно снижается. А если пакет не влезает в интерфейс на сервере — то и вовсе работать не будет. Для вычисления MTU с учетом промежуточных узлов будем пинговать сервер нашего туннеля пакетами, которые фрагментировать нельзя.
Делается это так (где в конце должен стоять ваш Server IPv4 address):

ping -M do -s 1472 216.66.84.46

Если пингуется нормально, то ничего менять не надо, пакеты до 1500 байт (1472 + 28 байт) включительно проходят нормально. Если же ответ вида:

From 11.22.33.44 icmp_seq=1 Frag needed and DF set (mtu = 1488)

Тогда пытайтесь уменьшить размер пакета до достижения успеха. Потом увеличивать его до тех пор, пока будет пинговаться.

Исправляем MTU. Пусть у вас максимум при ping -M do -s 1464 ... Тогда берем 1472 — 1464 = 8 потом 1480 — 8 = 1472 И так мы получили, что в этом случае ваш MTU туннеля должен быть равен 1472. Теперь идем обратно в Tunnel Details, вкладку Advanced и выбираем MTU не больший вашего, но ближайший к вашему. Перезапускаем туннель (либо опускаем, поднимаем интерфейс, либо перезагружаем систему). Проверяем снова:

wget -6 -O /dev/null http://he.net

Если не успела смениться фаза луны, то у вас больше нет проблем с MTU туннеля.

Раздача интернетов

Да, на сервере уже есть работающий IPv6, но мы же хотим предоставить его всем компьютерам в доме. Считается, что сервер находится в той же локальной домашней (офисной) сети, что и клиенты и в том же широковещательном домене Ethernet.

Разрешаем IPv6 forwarding. В случае Debian за это отвечает служба sysctl, у которой очень много настроек, в основном сетевых параметров уровня ядра.
Редактируем файл /etc/sysctl.conf

net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1

Применяем изменения (в консоли):

sysctl -p

После этого ваш сервер больше не сможет назначать себе IPv6 адрес автоматически, но нам это и не нужно.

Устанавливаем демон анонсирования подсети. Для этих целей (stateless autoconfiguration отличается от DHCPv6 тем, что адреса назначаются машинами самостоятельно в соответствии с MAC адресом, что хорошо в борьбе с ARP спуффингом) предназначен демон radvd (с DVD дисками не имеет ничего общего).
Установим его:

apt-get install radvd

И сразу остановим:

/etc/init.d/radvd stop

Настраиваем radvd. Тут все просто. Сначала найдите в Tunnel Details ваш префикс Routed /64.
Редактируем файл /etc/radvd.conf

interface eth0
{
   AdvSendAdvert on;
   AdvLinkMTU 1480;
   prefix 2001:470:abcd:abcd::/64
   {
       AdvOnLink on;
       AdvAutonomous on;
   };
};

Где interface — сетевой интерфейс, смотрящий в вашу локальную сеть, prefix — это ваш Routed /64, а AdvLinkMTU — это MTU вашего туннеля.
Автоматическая настройка DNS не рассматривается, так как требуются дополнительные действия на всех клиентских машинах под Linux, а Windows вообще не поддерживает получение DNS через Router Advertisement, только через DHCPv6 (который весьма неудобен). Поэтому проще прописать на всех клиентских машинах DNS сервера Hurricane Electric (ваш Anycasted IPv6/IPv4 Caching Nameserver). В Windows это делается в параметрах сетевого подключения, в Linux редактируется файл /etc/resolv.conf

Настраиваем сетевой интерфейс. Если вы прямо сейчас запустите radvd (не надо пока), то клиенты получат свои заветные адреса, но ничего работать не будет. Дело в том, что пакеты от клиентов в интернет уходить будут, а обратно нет, так как, попав на ваш сервер, они не найдут вас в сети в силу отсутствия маршрута к клиентам вашей подсети (Routed /64). Можно, конечно, прописать только маршрут, но лучше добавить интерфейсу на сервере первый адрес из этой подсети, так принято делать, к тому маршрутизация будет срабатывать чуть-чуть быстрее.
Находим в файле /etc/network/interfaces настройки интерфейса (смотрящего в локальную сеть), в моем случае eth0, которые выглядят примерно так:

allow-hotplug eth0
iface eth0 inet static
  address 192.168.6.6
  netmask 255.255.255.0
  broadcast 192.168.6.255

И в конце секции дописываем настройки IPv6, в итоге получается (все вместе):

allow-hotplug eth0
iface eth0 inet static
  address 192.168.6.6
  netmask 255.255.255.0
  broadcast 192.168.6.255

iface eth0 inet6 static
  address 2001:470:abcd:abcd::1
  netmask 64

Где часть адреса до двойного двоеточия (привет C++) соответствует вашему Routed /64. Будьте аккуратны при редактировании этого файла. Так я однажды случайно поломал настройки сети и не мог зайти на сервер по SSH, пришлось искать монитор.
Для сиюминутного назначения адреса выполняем:

ip -6 addr add 2001:470:abcd:abcd::1/64 dev eth0

Обратите внимание, что у адреса в этой команде указывается длина префикса (/64) на конце, это важно. Ну и имя интерфейса поменять в случае чего нужно не забыть.

Проверяем работу. Пришло время проверить свеженастроенную IPv6 сеть.
Запускаем radvd

/etc/init.d/radvd start

И сразу все машины в сети получили IPv6 адреса в вашей Routed /64 подсети на основе своего MAC адреса (во всяком случае машины на Windows не потребовали переподключения).
На клиентских машинах (мы же не забыли прописать DNS) открываем test-ipv6.com

Если у вас тоже все зеленькое — поздравляю! Вы приобщили свою сеть к миру IPv6.
Google, YouTube тоже должны работать через IPv6.

PROFIT !!!

Маленький бонус. Моя, например, подсеть размешена в Амстердаме, с пингами все хорошо. Но более высокая подсеть Hurricane Electric (2001:470::/32) зарегистрирована в США и все ее подсети распознаются как США вне зависимости от географии. Поэтому вы можете все сервисы Google, которые доступны только на территории США, не используя американский прокси и не жертвуя длиной пинга. Поэтому вместо абстрактной пользы мы имеет совершенно конкретные преимущества:

1. Глобальная доступность всех клиентов — прощай NAT
2. Все думают, что вы американец
3. Быстрее работают торренты, в основном за счет пиров с включенным Teredo
4. Настраивая IPv6 сегодня, вы будете готовы к его наступлению завтра, а возможно сможете заработать на его настройке во время ажиотажа
5. Выделенная подсеть — необъятный простор для извращений, причем бесплатный. Вам доступен rDNS, DNS неймсервер от того же Hurricane Electric, с поддержкой динамического DNS и с очень милым интерфейсом.

В следующих сериях. Это первая часть цикла статей об IPv6, но я могу сразу сказать, что будет в следующих частях:

• Часть 2. Настройка фаервола. Борьба с NAT. Настройка конфигурации с несколькими серверами, объединение офисов. Настройка OpenVPN + IPv6, создание подсетей, Routed /48, Dualstack.
• Часть 3. Работа с DNS, rDNS. Размещение своих сервисов в IPv6, Native IPv6. Чем хорош и плох Native IPv6, предоставляемый хостерами. Собственный Native IPv6, как зарегистрировать сеть для своей фирмы, к чему подключить.
• Часть 4. Онлайн сертификация на навыки в области IPv6 от Hurricane Electric. Теория, необходимая для прохождения сертификации (step-by-step инструкции для читеров не ждите, хотя уже есть в интернетах). Будущее IPv6.

Я не обещаю быстрый выход последующих частей, но часть 2 ожидается через недели 2-3. К сожалению, в следующих частях уровень доступности изложения сохранить не удастся, так уровень навыков целевой аудитории тоже будет выше.

Будьте готовы к IPv6, его приход неизбежен.