Как начать работать с IPv6 там, где его нет (часть 1)

Появлением на свет этот материал обязан переводу статьи IPv6 — это катастрофа (но поправимая) (автор Mathew Duggan) и является её логическим продолжением. Если вы живёте в небольшом городе, которого в том числе нет в этом списке, и ваш провайдер в него не входит, то велика вероятность, что просто так взять и начать по-настоящему (за пределами lan) работать с IPv6 не получится. Некоторых стран СНГ это касается в полной мере, где целые государства не имеют для этого необходимого интеллектуального и материального ресурса. Однако исследовательский интерес толкает человечество вперёд, поэтому в статье будут описаны стратегии, как получить и настроить IPv6 на различных, в том числе мобильных устройствах там, где его нет, используя возможности брокеров. В материале скомпилированы разные подходы, чтобы читатель мог реализовать подходящий вариант. Если у вас ещё имеются сомнения, нужно ли это вообще, то рекомендую почитать мотивационную статью, ссылка на которую приведена выше.

▍ Введение

В настоящее время основным подходом к внедрению IPv6 является dual-stack, когда устройство одновременно настроено на функционирование обоих IP-протоколов. Это и понятно, ведь основная часть интернета работает на версии IPv4. Механизм 6to4 позволяет подключить ваше устройство IPv4 к брокеру, создав туннель в IPv6. И всё бы было легко и просто, но для такой схемы с вашей стороны необходим маршрутизируемый в wan адрес (белый IP), который в мире сarrier-grade nat провайдеры выдают только за дополнительную плату. Как с этим быть, подробно и рассмотрим в статье.

Брать в аренду у своего провайдера белый IP не хочется, тем более в случае с мобильными устройствами это вообще трудновыполнимая задача. Поэтому для подключения к брокеру воспользуемся VDS-сервером, который с минимальными характеристиками можно арендовать по цене шоколадки или задействовать уже имеющийся сервер, нарастив его необходимым функционалом. Всё по порядку. Так как впереди предстоит работа с сетевыми протоколами, то для лёгкости её восприятия лучше начать с описания настройки предназначенного для этого сетевого оборудования, например, облачного маршрутизатора на RouterOS. Покажем, как прокинуть доступ в сеть IPv6 до устройств из домашней сети, поддерживающих и не поддерживающих VPN-протоколы. Далее концептуально перенесём всё на Linux, чтобы убрать необходимость аренды целого сервера лишь для развёртывания на нём облачного роутера. И в последнюю очередь подключим смартфон к реализуемой связке. В результате если у вас уже есть в эксплуатации хотя бы один сервер в интернете, то финансовых вложений не потребуется, а IPv6 появится там, где его нет.

▍ Общая настройка CHR

Установку RouterOS на выделенном сервере провести достаточно легко. Для этого после загрузки надо запомнить настройки сетевого интерфейса, проведённые провайдером: адрес и маску сервера, адрес шлюза. Иначе gateway default придётся угадывать или открывать запрос в техническую поддержку:

cat /etc/network/interfaces

allow-hotplug eth0
iface eth0 inet static
        address ip_адреc_сервера
        netmask 255.255.252.0
        gateway ip_адрес_шлюза

После этого прямо на свежеустановленный Debian (хотя, конечно, совсем необязательно на него) скачиваем и заливаем RouterOS:

mount -t tmpfs tmpfs /tmp/
cd /tmp
wget https://download.mikrotik.com/routeros/7.11.2/chr-7.11.2.img.zip
apt install zip
unzip chr-7.11.2.img.zip
dd if=chr-7.11.2.img of=/dev/vda bs=4M oflag=sync
echo 1 > /proc/sys/kernel/sysrq 
echo b > /proc/sysrq-trigger

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

/user set admin password="абра_катабра"
/ip address add interface=ether1 address=ip_адрес_сервера/маска
/ip route add dst-address=0.0.0.0/0 gateway= ip_адрес_шлюза
/quit

Далее привожу свод рекомендуемых мной общих настроек chr. Укажем IPv4 и IPv6 сервера dns, организацию доступа, джентльменский firewall:

/interface list
add name=WAN
add name=LAN
/ip neighbor discovery-settings set discover-interface-list=WAN protocol=""
/interface list member add interface=ether1 list=WAN
/ip dns set allow-remote-requests=yes servers=77.88.8.8,77.88.8.1,1.1.1.1,2001:4860:4860::8888,2001:4860:4860::8844
/ip firewall filter
add action=accept chain=input comment="Accept established,related" connection-state=established,related
add action=drop chain=input comment="Drop invalid" connection-state=invalid
add action=accept chain=input comment="Accept ICMP" protocol=icmp
add action=accept chain=input comment="Accept SSH" dst-port=22 protocol=tcp
add action=accept chain=input comment="Accept Winbox" dst-port=8291 protocol=tcp
add action=drop chain=input comment="Drop all input"
add action=accept chain=forward comment="Accept established,related" connection-state=established,related
add action=drop chain=forward comment="Drop invalid" connection-state=invalid
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/system clock set time-zone-name=Asia/Tashkent
/system identity set name=ipv6_router
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN
/tool mac-server ping set enabled=no

Рекомендую оставлять службу winbox активной только на период администрирования роутера, так она позволяет очень наглядно производить контроль применяемых настроек и состояния маршрутизатора. Хотя программ для брутфорса winbox, работающих с актуальными версиями RouterOS, мне не известно, но лишний раз демонстрировать интернету, что это не просто сервер, а маршрутизатор, я бы не стал из этических соображений и переживаний за уязвимости нулевого дня. Всё остальное время следует оставлять активным только ssh-сервер. При этом добавить пользователю публичный ключ. Доступ по паролю будет автоматически отключён (настройка по умолчанию always-allow-password-login: no):

/ip ssh print

forwarding-enabled: both
always-allow-password-login: no
strong-crypto: no
allow-none-crypto: no
host-key-size: 2048
host-key-type: rsa

Удобнее всего это сделать через winbox, перетащив публичный ключ в раздел Files, после чего импортировать:

/user ssh-keys add user=admin key="ssh.pub"

После этого подключение по ssh будет выглядеть примерно так:

ssh -o "PubkeyAcceptedAlgorithms=ssh-rsa" admin@ip_адрес_вашего_сервера

Я уделил настройке и безопасности достаточное внимание в статье, хотя на эту тему хватает информации, чтобы устройство неподготовленного читателя не стало частью работы какого-нибудь ботнета. С учётом того, что единожды настроенный роутер в режиме прокси IPv4 в IPv6 может годами вообще не администрироваться. Важно чёткое понимание, что безопасность доступа облачного маршрутизатора должна быть обеспечена на таком же уровне, как и до любого другого сервера (ровно как и сервиса) в интернете, подвергающегося регулярному сканированию из сети. Отсутствие возможности залогиниться паролем снимает переживания за попытки несанкционированного доступа, вроде этих:

(1516 messages not shown)
2023-09-07 06:38:16 system,error,critical login failure for user admin from 193.201.9.109 via ssh
2023-09-07 06:54:31 system,error,critical login failure for user ubnt from 31.41.244.61 via ssh
2023-09-07 07:14:22 system,error,critical login failure for user ubnt from 141.98.11.11 via ssh
2023-09-07 07:43:14 system,error,critical login failure for user ftp from 31.41.244.62 via ssh
2023-09-07 08:17:19 system,error,critical login failure for user admin from 31.41.244.62 via ssh
2023-09-07 08:48:21 system,error,critical login failure for user ubnt from 141.98.11.11 via ssh
2023-09-07 09:13:56 system,error,critical login failure for user support from 67.211.208.198 via ssh
2023-09-07 09:32:41 system,error,critical login failure for user uucp from 141.98.11.90 via ssh

▍ IPv4 to IPv6 на CHR

Первым делом проходим регистрацию на сайте любого брокера, например, Hurricane Electrik. В личном кабинете указываем IPv4-адрес своего выделенного сервера, после чего backend сервиса опросит его по icmp, и если ответ устроит, то сконфигурирует себя и будет ждать подключения. Настойки туннеля будут выглядеть примерно так:

IPv6 Tunnel Endpoints
Server IPv4 Address:216.66.80.90
Server IPv6 Address:2001:470:27:230::1/64
Client IPv4 Address:185.87.48.14
Client IPv6 Address:2001:470:27:230::2/64
Routed IPv6 Prefixes
Routed /64:2001:470:28:231::/64
Routed /48:Assign /48

Видно, что сервер Hurricane Electrik ожидает подключение с IPv4 вашего VDS по протоколу 6to4 и сконфигурировал у себя на туннельном интерфейсе статический IPv6-адрес 2001:470:27:230::1. В своей таблице маршрутизации указал, что с нашей стороны туннеля будет функционировать сеть 2001:470:28:231::/64. Можно сказать, что делегировал администрирование её нам. Повторюсь, это всё бесплатно, по крайней мере, пока. Осталось сконфигурировать chr. Поднимем туннель со статическим адресом и настроим шлюз по умолчанию в IPv6 часть интернета:

/interface 6to4 add comment="Hurricane Electric IPv6 Tunnel Broker" disabled=no local-address=ip_адрес_сервера mtu=1280 name=ipv6_tunnel remote-address=216.66.80.90
/ipv6 address add address=2001:470:27:230::2/64 advertise=no interface=ipv6_tunnel
/ipv6 route add disabled=no distance=1 dst-address=2000::/3 gateway=2001:470:27:230::1 scope=30 target-scope=10
/interface list member add interface=ipv6_tunnel list=WAN 

После этого можно тестировать доступ в новый мир:

/ping 2001:4860:4860::8888
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 2001:4860:4860::8888                       56 120 23ms591us  echo reply
    1 2001:4860:4860::8888                       56 120 23ms283us  echo reply

Установлено соединение с брокером по протоколу packet tunneling ipv6 over ipv4 — 41 (ipv6-encap) в терминологии mikrotik. Так как роутер является инициатором соединения, то оно попадает под первое правило настроенного firewall, а не под следующее за ним drop rule:

/ip firewall filter
add action=accept chain=input comment="Accept established,related" connection-state=established,related
…
add action=drop chain=input comment="Drop all input"

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

▍ Туннелирование IPv6 до устройств домашней сети

Начнём с простого и запустим прямой туннель по устаревшему, но примитивному в настройке протоколу pptp от устройств из домашней сети до chr. Для этого определим, какие IPv4-адреса будем использовать на концах туннеля, логин и пароль пользователя, и прибьём его гвоздями к статическому интерфейсу vpn, который будет активироваться после установки соединения:

/ip pool add name=pool_for_tunnel_in_lan ranges=192.168.99.1-192.168.99.2
/ppp profile add local-address=pool_for_tunnel_in_lan name=my_ppp_tunnels remote-address=pool_for_tunnel_in_lan use-encryption=required
/ppp secret add name=user01 profile=my_ppp_tunnels service=pptp password="123"
/interface pptp-server add name=pptp-in1 user=user01
/interface pptp-server server set authentication=mschap2 default-profile=my_ppp_tunnels enabled=yes

Это нужно, так как далее указанный интерфейс будет задействован при назначении IPv6-адресации. А именно при включении режима автоматического конфигурирования интерфейса под выданный брокером префикс. Остановлюсь подробнее: указанный advertise=yes режим является частью работы IPv6-протокола. Он может быть использован для префикса не больше /64, предназначен для удобства использования, позволяет обходиться без dhcpv6-сервера. Посредством его можно передать только маршруты и адреса сетей. Протокол имеет расширение для раздачи адресов серверов dns, но для анонсирования дополнительной информации вроде серверов ntp или вовсе произвольных опций без dhcpv6, конечно, не обойтись. Коротко его работу можно описать так — активировал на интерфейсе сервера, и клиенты сами настроят туннельные интерфейсы для работы с анонсированным префиксом в IPv6:

/ipv6 address add address=2001:470:28:231::/64 interface=pptp-in1 advertise=yes

Подкрутим правила в firewall. После добавления их нужно расставить в правильном порядке: сначала разрешающие, потом только запрещающие для каждой из цепочек (input и forward). Настройка src-nat позволит клиентам выходить в интернет через chr в IPv4-сети:

/ip firewall filter
add action=accept chain=input comment="Accept PPTP" dst-port=1723 protocol=tcp
add action=drop chain=forward comment="Drop all from WAN to !DSTNAT" connection-nat-state=!dstnat connection-state=new in-interface=ether1
/ip firewall nat add action=src-nat chain=srcnat comment="For ipv4 works" out-interface=ether1 src-address=192.168.99.0/24 to-addresses=ip_адрес_вашего_chr

Настройки pptp-клиентов тривиальны на всех операционных системах. Указываются аутентификация mschap2, логин и пароль пользователя vpn, IPv4-адрес до VDS-сервера. Автоматическое получение IPv6-адреса активировано по умолчанию, тот самый advertise=yes всё сделает в автоматическом режиме. После установления pptp-туннеля клиентская машина выйдет в интернет:

Алгоритм назначения IPv6-адреса различен у операционных систем, к практической части вопроса это отношение не имеет. Windows сгенерировал его с фонаря, сеть /64, есть где разойтись. Администратору в этой части можно голову не ломать.

▍ Промежуточные выводы

В этой части цикла статей для получения доступа в IPv6 часть интернета мы взяли в аренду VDS. С целью более лёгкого восприятия тонкостей сетевой настройки установили и сконфигурировали на нём облачный маршрутизатор от mikrotik. Уделили при этом особое внимание вопросу информационной безопасности. Организовали взаимосвязь между IPv6-брокером, арендованным сервером и устройствами из домашней сети, подключёнными к chr посредством простого протокола vpn. Дальше постепенно будем прокачивать подготовленное решение. Если хотите остановиться на достигнутом результате, то настоятельно рекомендую прочитать последующие материалы, так как будет интереснее.