IPv6: The Hard Way

Вы находитесь здесь: version6.ru » IPv6: The Hard Way
Эта страница — только для чтения. Вы можете посмотреть исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== IPv6: The Hard Way ======
//Впервые опубликовано 2012-08-31//

В этой статье я расскажу о ещё одном способе получения IPv6-связности. Он не является бесплатным, требует определённой квалификации для настройки, однако способен предоставить несколько весьма приятных преимуществ по сравнению с используемыми обычно энтузиастами туннелями от tunnelbroker.net и прочих брокеров, а также 6to4.

Целевая аудитория статьи - уже хорошо знакомые с IPv6 администраторы, которые поймут всё (достаточно кратко) описанное без лишних вопросов, и которым не нужно на каждом этапе пошаговое howto. Надеюсь среди аудитории есть и такие. :)

Также подразумевается использование в качестве домашнего роутера полноценной GNU/Linux-системы.

Статья оформлена нетрадиционным образом, сначала идёт "как", а уже потом "зачем", точнее -- что мы получили в итоге, и какой теперь от этого профит.

===== Суть идеи =====
Аренда VPS или выделенного сервера с нативным v6-диапазоном и маршрутизация части этого диапазона к себе домой поверх VPN.

Либо использование этих VPS/сервера в качестве промежуточного роутера между вами и вашим туннелем от tunnelbroker.net.

===== Как =====
==== Получаем IPv6 ====
=== Нативный от удалённого провайдера ===
Покупаем Xen или KVM VPS, либо выделенный сервер, с которыми "в комплекте" идёт смаршрутизированный блок IPv6:
  * [[http://en.edis.at/|EDIS]]: \\ KVM VPS в Австрии от 4 EUR/мес; 1 ТБ трафика; /112 в комплекте, до /48 по запросу (хотя провайдер предоставляет выбор из большого числа датацентров, запрос дополнительной подсети v6 возможен только для VPS в австрийском);
  * [[http://www.evorack.com/unmanaged-xen-vps.php|Evorack]]: \\ Xen VPS в UK от 2.5 GBP/мес; 250 ГБ трафика; одна IPv6-подсеть /64 бесплатно по запросу в техподдержку;
  * [[http://iperweb.com/site/budget-vps.php|IperWeb]]:\\ KVM VPS в Италии от 15 евро за полгода; 1 ТБ трафика; /112 в комплекте, по запросу чего-то побольше -- бесплатно выдали /48;
  * [[http://www.kimsufi.com/fr/|Kimsufi 2G]]: \\ выделенный сервер во Франции за 15 евро; подсеть /64 в комплекте; внимание: по неподтверждённой информации, UDP-трафик лимитируется (20 мегабитами или меньше);

Недостатком этого варианта будет являться то, что весь ваш v6-трафик будет проходить через датацентр хостера, соответственно если вы будете качать по IPv6 нелицензионные торренты, в теории это может привести к закрытию вашего (платного) эккаунта за нарушение ToS/AUP, без возврата денег.

=== Транзит до tunnelbroker.net ===
Можно также воспользоваться практически любым VPS-хостером (Xen или KVM) из числа не предоставляющих нативного IPv6, либо дающих не подсеть, а какое-то небольшое количество адресов (часто можно увидеть предложения с 5-10-15 //штуками// одиночных IPv6-адресов в комплекте).

В таком случае VPS или сервер от этого хостера можно использовать в качестве "перевалочного пункта" на пути от вас до ближайшего к нему туннельного сервера tunnelbroker.net. Таким образом "IPv4 endpoint" для туннеля будет ваша VPS, а уже она будет маршрутизировать приходящую от he.net сеть непосредственно вам.

Для этого варианта интересными лично мне видятся:

  * [[https://clients.inceptionhosting.com/cart.php?gid=10|InceptionHosting]]: \\ Xen VPS в Нидерландах (близко к Амстердамскому серверу he.net) от 7 EUR/квартал; 300 ГБ исходящего трафика, входящий нелимитирован;
  * [[http://nqhost.com/cheap-vps.html|NQhost]]: \\ Xen VPS в Москве за $7/месяц; безлимитные 100 мегабит.

Из минусов - вероятно чуть меньшая производительность, из-за большего количества звеньев в цепочке, по которой к вам будет идти трафик.

Из плюсов - торренты можно качать без опаски, внутрь пакетов протокола 41 ваш хостер не полезет, а если осерчает HE.net, это чревато максимум закрытием бесплатного эккаунта на tunnelbroker.net (но о таких случаях не известно). Также в вашем распоряжении полный контроль над rDNS, в том числе делегация на свои сервера, что далеко не всегда доступно с "нативными" хостерами.

==== Роутим IPv6 к себе ====
С помощью [[http://www.tinc-vpn.org/|Tinc]] организуем туннель между своим домашним роутером и вашим удалённым сервером.

  * //tinc is a Virtual Private Network (VPN) daemon that uses tunnelling and encryption to create a secure private network between hosts on the Internet.//

Почему именно Tinc?
  * //**Encryption, authentication and compression**. All traffic is optionally compressed using zlib or LZO, and OpenSSL is used to encrypt the traffic and protect it from alteration with message authentication codes and sequence numbers.//
  * //**Automatic full mesh routing**. Regardless of how you set up the tinc daemons to connect to each other, VPN traffic is always (if possible) sent directly to the destination, without going through intermediate hops.//

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

  * http://www.vanheusden.com/Linux/tinc_mini_howto.html

==== Раздаём IPv6 ====
Роутинг нужно настроить в двух местах:
  * На удалённом VPS или сервере, там нужно настроить маршрутизацию назначенной вам IPv6-подсети в виртуальный интерфейс Tinc (всё делается в его файле tinc-up, это обычный шелл-скрипт, можно просто вручную прописать там команды на добавление адресов и маршрутов);
  * На вашем домашнем роутере, здесь всё более привычно: есть внешний интерфейс (созданный Tinc), туда приходит смаршрутизированная сеть, нужно раздать её в LAN, radvd в помощь.

Внутри Tinc VPN я рекомендую использовать ULA-адресацию, маршруты же на реальные адреса добавлять через эти внутренние.

Для пущей безопасности, ip6tables можно настроить на обоих роутерах, в результате нежелательные попытки соединений и прочий мусорный трафик будут отсекаться ещё на вашем маршрутизаторе где-то в Европах, и до вас (что может быть важно, если вы, к примеру, сидите в российской глубинке на 3G-модеме) даже и близко не долетят. :)
  

===== Зачем =====
Итак, зачем же всё это было нужно? Настроив IPv6-туннель по схеме, сходной с указанной выше, мы получаем:

==== 1. Редкий диапазон адресов ====
При использовании первого варианта (удалённого хостера с нативным IPv6), вы получаете адреса из малоизвестного блока, это может быть выгодно по ряду причин, от практических (случались эпизоды попадания всей 2001:470::/32 в K-Line на некоторых IRC-сетях) до эстетических (некоторые считают 2001:470::/32 и особенно 2002::/16 адресами "второго класса" :).

==== 2. IPv4-независимость ====
Без разницы, каким провайдером вы пользуетесь  -- к примеру ваш основной провайдер внезапно "упал", и вы переключились на резерв в виде 3G-модема -- Tinc при смене вашего IPv4 очень быстро восстановит связь с удалёнными нодами своей VPN, и вы сможете продолжать пользоваться вашим IPv6-диапазоном как ни в чём не бывало.

Также пропадает необходимость при динамическом IPv4 постоянно обновлять IPv4 endpoint на удалённом конце туннеля. Tinc автоматически переподнимает VPN при потере связи (к примеру, от переподключения v4-коннекта и смены v4-адреса).

==== 3. Распределённость ====
Tinc позволяет создать распределённую VPN-сеть, где каждая из нод напрямую общается со всеми другими нодами. На практике, в контексте данной статьи это означает то, что можно подключить в созданную VPN ещё и третьего-четвёртого-десятого клиента, настроив на вашем VPS или сервере маршрутизацию отдельных v6-блоков на локальные адреса для каждого из них. Без разницы, в какой IPv4-сети находится ваш ноутбук, при включении он установит связь с вашей Tinc-сетью, после чего получит возможность использовать свой всегда один и тот же, глобально-статичный IPv6-адрес. Получаем этакий самодельный Mobile IPv6.

==== 4. Шифрование ====
Благодаря Tinc, весь трафик между вашим домашним роутером и удалённым роутером будет передаваться в //зашифрованном// виде. Злоумышленники больше не смогут перехватить трафик вашего туннеля; однако по-прежнему остаётся вопрос о доверии владельцу другого его конца, и всему что "за" ним. Впрочем для ресурсов требующих безопасности передаваемых данных, в любом случае следует использовать HTTPS.

==== 5. Сжатие ====
Благодаря Tinc, весь трафик между вашим домашним роутером и удалённым роутером будет передаваться в //сжатом// виде. Сбылась давняя мечта об "ускорителе интернета", хорошо сжимаемые страницы (а также всякие тестовые файлы, состоящие из одних нулей) имеют шанс передаваться быстрее физической скорости используемого вами интернет-соединения.

==== 6. Совместимость с NAT ====
Tinc передаёт все данные поверх UDP (также используя TCP-соединение для т.н. "control connection"). В отличие от используемого в случаях с tunnelbroker.net и 6to4 "протокола 41", для Tinc VPN не требуется внешний IPv4-адрес он отлично работает из-за провайдерских NAT.

===== Вопросы? =====
Обсудить эту статью и задать вопросы об описанной схеме можно в [[irc|наших IRC-каналах об IPv6]].
ipv6-the-hard-way.1348246164.txt.gz · Последние изменения: 2012-09-21 16:49 UTC От rm
	Новости
	Сообщество
	Twitter
	IRC
Views

Навигация

Personal Tools

Поиск

Инструменты

Ссылки
