Сами себе туннельный брокер IPv6 с помощью openvpn и 6to4

  • Tutorial


Вы хотите чтобы Ваши устройства (Windows\Linux\Android\iOS) начали использовать IPv6, но Ваш провайдер его еще не предоставляет? У Вас есть собственный сервер\VDS\просто компьютер с линуксом и постоянным прямым IPv4 (НЕ IPv6) адресом или даже свой openvpn сервер? Тогда возможно эта статья Вам поможет.
Она не для маститых сетевых гуру, я просто собрал в одном месте набор указаний с целью распространения IPv6 среди масс. Хотя буду благодарен всем маститым гуру, которые меня раскритикуют в комментах и укажут на ошибки. Так как пишу я пост практически сразу после того, как система заработала. Все может быть бесконечно далеко от идеала.


Побудил меня настроить подобную систему мой новый планшет, который на стоковой (других пока что нет) прошивке не хочет получать IPv6 от wifi-роутера, не говоря уже о невозможности использовать IPv6, работая через 3G.

Нам понадобится следующий инструментарий:
  1. Хост с linux и прямым, статическим IP адресом (подойдет любой выделеный или виртуальный сервер). У меня VPS на Xen с gentoo и собственным ядром. Однако я считаю, что ничего нестандартного не использую, поэтому должно работать и на популярных бинарных дистрибутивах.
  2. Установленный на сервере пакет iproute2. Проверка через «ip --version».
  3. openvpn сервер. Версия openvpn — должна быть >= 2.3, крайне желательно 2.3.2 или новее.
  4. openvpn клиент. Существуют версии под linux, windows, os x, android (1, 2) и iOS. Требования к версии такие же как у сервера.


Настраиваем IPv6 на сервере через 6to4.

Для облегчения перехода на IPv6 создана технология 6to4: каждому IPv4 адресу в соответствует подсеть /48 IPv6-адресов. Подробнее...
Предположим, IP Вашего сервера: 208.64.121.161 (взял IP test.com). Идем на 6to4.version6.net/?lang=en_GB, вбиваем IP, например, 208.64.121.161. Получаем следующие настройки:

Your IPv4 address is 208.64.121.161
Your 6to4 address is 2002:d040:79a1::2080:6412:1161
6to4 gateway address is 192.88.99.1


Нам нужен только выделенный жирным кусок. Это наша /48 IPv6 подсеть. У Вас две группы после 2002 в адресе должны быть другими! В них закодирован Ваш IPv4.

Придумываем себе адрес в этой подсети. Для простоты можно использовать ::2 (почему-то замечены глюки при использовании ::1, может кто расскажет почему, а может мне показалось), то есть 2002:d040:79a1::2.

Создаем туннель (заменяя IPv4 на Ваш адрес):
ip tunnel add tun6to4 mode sit remote any local 208.64.121.161 ttl 64
Поднимаем интерфейс:
ip link set dev tun6to4 up
Задаем интерфейсу IPv6 адрес, который придумали раньше:
ip -6 addr add 2002:d040:79a1::2/128 dev tun6to4
Задаем маршрут по умолчанию (192.88.99.1 — общий маршрутизатор для 6to4, не меняем его!):
ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1
После этого наш сервер должен получить возможность работать по IPv6. Проверяем:
ping6 2001:ad0::1

В генте я это все сохранил, добавив в /etc/conf.d/net следующие строчки (создав линк net.lo->net.tun6to4 и не забыв сделать rc-update add net.tun6to4 default):
iptunnel_tun6to4=«mode sit remote any local 208.64.121.161 ttl 64»
config_tun6to4=«2002:d040:79a1::2»
routes_tun6to4=«2000::/3 via ::192.88.99.1 dev tun6to4 metric 1»
rc_net_tun6to4_need=«net.eth0»


Если пинги идут, значит этап 1 пройден. Если не идут, думаем, проверяем везде ли мы заменили то, что надо заменить на наши данные. Если ничего не помогает подробно рассказываем что делали (с указанием IP сервера) в комментах, попробую помочь. В личку не помогаю.

Настраиваем openvpn для работы с IPv6

Как настроить openvpn писано до меня не раз. В том числе тут. Юзайте поиск. Я на всякий случай привожу свои конфиги, вырезав приватные данные.

Сервер
port censored
proto udp
dev tun
ca vpn1/ca.crt
cert vpn1/server.crt
key vpn1/server.key
dh vpn1/dh2048.pem
server 10.censored 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 60
comp-lzo adaptive
user nobody
group nobody
persist-key
persist-tun
fast-io
status openvpn-status.log

max-clients 30
tls-auth vpn1/ta.key 0
chroot /var/chroot/openvpn

cipher AES-256-CBC
auth SHA512
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA

local censored
client-to-client
ping-timer-rem
management localhost 7505
client-config-dir ccd

Клиент
client
dev tun
proto udp

remote censored censored
resolv-retry infinite
nobind

persist-key
persist-tun

comp-lzo adaptive
verb 3

key-direction 1

cipher AES-256-CBC
auth SHA512
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA

verify-x509-name 'C=RU, ST=RU, L=censored'

censored


<tls-auth>
censored
</tls-auth>


Для раздачи IPv6 через openvpn придумываем номер /64 подсети. Это любое число от 0 до FFFF. Например, 5. То есть в моем случае /64 подсеть будет выглядеть целиком так: 2002:d040:79a1:5::. Добавляем в openvpn.conf на сервере строчку:
server-ipv6 2002:d040:79a1:5::/64
В принципе в этой строчке и заключается вся настройка openvpn для IPv6. Осталось только указать openvpn-серверу, чтоб он сообщал клиентам маршрут по умолчанию для IPv6. Вы можете это делать либо глобально в серверном openvpn.conf либо в ccd файле для каждого клиента с помощью строчки:
push "route-ipv6 2000::/3"
Так же необходимо указать клиентам IPv6 DNS-сервер. Я использую свой, Вы можете воспользоваться гугловским. В серверном openvpn.conf или в ccd:
push "dhcp-option DNS 2001:4860:4860::8888"

(Пере)запускаем сервер.
В конфиге клиента ничего менять не надо. Подключаемся к серверу и должны получить IPv6 адрес. На клиенте смотрим:
ip -6 addr list
Видим что-то типа:
9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 100
inet6 2002:d040:79a1:5::1005/64 scope global


Аналогично смотрим IPv6 адрес tun-интерфейса на сервере, скорее всего он будет заканчиваться на ::1 (2002:d040:79a1:5::1).
Пробуем пинговать с клиента на сервер и обратно. Если пингуется, осталось совсем немного.

Пробуем пинговать с клиента гугловский DNS:
ping6 2001:4860:4860::8888
не пингуется, так как IPv6 переадресацию надо разрешать аналогично IPv4. Разрешаем:
sysctl -w net.ipv6.conf.all.forwarding=1
И сохраняем в /etc/sysctl.conf строчку:
net.ipv6.conf.all.forwarding = 1

Должны пойти пинги с клиента до гугла и вообще появиться возможность использовать IPv6 с клиента. Например, попробуйте в броузере открыть ipv6.google.com.

Все? Ни в коем случае!

Прелестью IPv6 является то, что все адреса прямые. Поэтому все ваши openvpn-клиенты будут полностью доступны из большого, опасного интерента. Поэтому не забудьте настроить фаервол на сервере (для IPv6 используется ip6tables). Как минимум я сразу вписал следующее:
Прикрываем сам сервер:
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
ip6tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
ip6tables -A INPUT -j DROP


Прикрываем клиентов openvpn (так же прописывается на сервере!)
ip6tables -A FORWARD -p tcp -m conntrack --ctstate NEW -m tcp! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
ip6tables -A FORWARD -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
ip6tables -A FORWARD -i tun0 -j ACCEPT
ip6tables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -j DROP


Ну вот вроде и все. Мой Galaxy Tab 3 10.1 обрел возможность выхода в IPv6. Кстати, если кто знает как на нем включить возможность прямой работы с IPv6 через WiFi (у меня роутер раздает через radvd, все в том числе телефон с cyanogenmod адреса получают, а планшет со стоковой прошивкой нет :( ) — расскажите, пожалуйста, буду очень благодарен.

Шлите ошибки в приват, всем хорошей пятницы и выходных.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 14

    +3
    Небольшой комментарий: в соотвествии с RFC 3484, операционные системы (как минимум Windows точно) предпочитают IPv4 адресам 6to4 (хотя в остальных случаях IPv6 предпочтительней). Так что не удивляйтесь, если программы будут использовать IPv6 только тогда, когда записи A нет. Это можно изменить, но это будет отступлением от SHOULD из RFC.
      0
      Спасибо, интересно. А я то думал зачем у туннельных брокеров существуют статические маршруты, когда есть 6to4.
      В любом случае мои задачи «дать гаджетам доступ к IPv6» оно удовлетворяет. Те, кому 6to4 будет не хватать, могут использовать туннельных брокеров (SixXS, NetAssist или HurricaneElectric), получать у них /48 подсети и настраивать openvpn и маршрутизацию так же как у меня в статье. Собственно домашний вайфай у меня через NetAssist.
        0
        Я немного наврал про нарушение. RFC говорит SHOULD по отношению к ненастроенным (значения по умолчанию) и ненастраиваемым хостам. Настраивать можно как душе угодно, «if you know what are you doing».
        Вероятно, такие значения по умолчанию были приняты для обхода кривых 6to4-роутеров. Чтобы не страдали пользователи, которые и понять не могут, что происходит.
      0
      А зачем вы закрываетесь файрволлом? Разве удобно каждый раз «открывать» нужный порт? Не лучше уже на конечном устройстве файрволл настроить так, как требуется?
        +1
        Все зависит от задач. У меня клиенты VPN в основном гаджеты на андроиде или на iOS\OS X. Торренты мы там не ставим. Обращаться к ним извне не нужно. Поэтому мне проще закрыть их глобально. IPv6 лично мне нужно для доступа к IPv6 сайтам и моим серверам.
        Я недавно понял, что это прекрасно вешать тот же SSH на какой-нибудь «хрен угадаешь какой» адрес IPv6 из /48 диапазона 6to4. И ни один сканер этот ssh не найдет. А еще можно по IP сервисы лочить, так как у каждого устройства свой уникальный внешний IPv6 адрес. Или несколько.
          0
          К сожалению, атак по IPv6 дохрена и больше. Есть такой проект, thc-ipv6, и некоторые утилиты в нем позволяют быстро узнать все компьютеры в удаленной сети. Для локальной же сети есть магический адрес ff02::1, который можно пинговать, и на этот пинг ответят все машины.
            0
            А каким таким образом в теории можно вычислить, что на адресе 2001:AABB:CCDD:EEFF:0123:F200:7895:ABC3 на порту 65002 висит SSH, если ВЕСЬ остальной траф на этот IP режется фаерволом?

            А еще:
            ping6 ff02::1
            connect: Недопустимый аргумент

            в том числе и из-под рута.
              0
              если ВЕСЬ остальной траф на этот IP режется фаерволом?

              Да, действительно, как-то и не подумал об этом.

              connect: Недопустимый аргумент

              Это link-local адрес.
              Либо
              ping6 -I eth0 ff02::1

              либо
              ping6 ff02::1%eth0

              к слову, последний вариант записи работает почти везде. Нужно вам, например, подключиться к компьютеру в локальной сети, который, скажем, не успел получить IPv4 по DHCP, но у него с большой вероятностью есть IPv6-адрес, то сначала пингуете ff02::1, а затем
              ssh fe80::...%eth0
                0
                Сработало.

                к слову, последний вариант записи работает почти везде. Нужно вам, например, подключиться к компьютеру в локальной сети, который, скажем, не успел получить IPv4 по DHCP, но у него с большой вероятностью есть IPv6-адрес, то сначала пингуете ff02::1, а затем


                Не очень понял как мне найти адрес именно того компьютера, который мне нужен среди мешанины всех адресов в локалке, которые откликаются на этот пинг.
                  0
                  Не очень понял как мне найти адрес именно того компьютера, который мне нужен среди мешанины всех адресов в локалке, которые откликаются на этот пинг.

                  Теоретически можно использовать node information query. Например, если набрать что-то вроде
                  ping6 -N name -I eth0 ff02::1
                  в ответ придут адреса и хостнеймы машин в сети. На практике на такие запросы у меня дома только мак отвечает… :)
        0
        Ни одна статья, посвященная туннелям 6в4 не будет полной без пары ссылок:
        6to4
        Teredo

        Краткое содержание обеих статей: туннель хорош только если v6 адрес нужен «просто так». В деле распространения IPv6 туннель — скорее зло.
          0
          Лучше native ipv6 может быть только native ipv6. Кто бы спорил? Но вот с точки распространения… На безрыбье и рак рыба. Как вы предложите здесь и сейчас пользователю за NAT у провайдера без IPv6 подключаться к IPv6 ресурсам?
            0
            Отвечая на ваш вопрос: туннель v6 поверх v4 из-за NAT'а (кстати, много ли провайдеров занимаются трансляцией?) называется teredo. Вещь, кстати, не менее странная и удивительная чем 6to4 + openvpn. RFC по ней сознание расширяет просто феерично.

            Туннели дают возможность провайдерам откладывать внедрение v6. Типа, «на кой вам нативный, если есть туннель?» Это костыль, который местами используется очень странно: например в винде-семерке туннель включается автоматом, однако ничего не работает если не прописано v4 резолверов. В результате 95-100 процентов трафика генерится ничего не подозревающими пользователями, которым на v6 наплевать. Так что распространению v6 туннели никак не помогают.
              0
              Я спрашивал про замену не только моему решению, а туннелям вообще.

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

        Only users with full accounts can post comments. Log in, please.