Содержание
NAT64, NAT464, DNS64, CLAT, PLAT и другие страшные слова
С начала разработки IPv6 (а это очень старый протокол, его разработка была начата в 1994 году, а в 1995 уже был выпущен RFC1883 на эту тему), было понятно, что какое-то время будут сосуществовать одновременно IPv4 и IPv6 протоколы, и нужно какое-то взаимодействие между ними. Для этого были придуманы некоторые правила трансляции адресов между IPv4 и IPv6. Так как Yggdrasil не является полноценной IPv6 сетью, а просто использует часть её адресации, в этом разделе не будет описываться «как правильно» настраивать взаимодействие «белой» IPv6 и IPv4 сети.
И да, эта статья рассказывает «как», но не рассказывает «зачем». Если вам проще поднять WireGuard over Yggdrasil - делайте, как вам удобнее.
Для использования дальнейшей информации требуется знание/понимание устройства сетей и умение работать в командной строке Linux
| DISCLAIMER |
|---|
| Всегда помните, что без настроек firewall ваша нода доступна из сети Yggdrasil всем и каждому. Если в результате через вашу ноду выйдут в «белый интернет» злые хакеры и взломают Пентагон / разместят на форуме призывы к свержению существующего строя / выложат в сеть детскую порнографию, то в первую очередь прийдут именно к вам. Не забывайте настраивать firewall (это относится не только к этой статье, а и в целом к использованию Yggdrasil). Если что - мы вас предупредили! |
Общее представление что это такое
Для начала давайте определимся, что это за страшные слова и для чего каждый из компонентов используется. Объяснение очень «на пальцах», если интересует больше подробностей очень рекомендую начать с чтения документации на Jool, про который будет ниже.
NAT64 (PLAT)
NAT64 позволяет транслировать пакет с IPv6 адресами в пакет с IPv4. Естественно не любой, а специальный. В общем случае используется какая либо выделенная для этого IPv6 сеть с префиксом /96 (в «белом» IPv6 для этого есть специальная сеть 64:ff9b::/96, но мы договорились, что мы не про «белый» IPv6). Как понятно из префикса, используется последние 32 бита для записи IPv4 адреса внутри IPv6, например всем известный 8.8.8.8 можно записать так: 64:ff9b::8.8.8.8 (Да! Так можно писать адреса! Это полностью эквивалентно адресу 64:ff9b::808:808). По сути задача NAT64 - заменить в исходящем пакете IPv6 на спрятанный там IPv4, подставить в качестве отправителя свой (или указанный в отдельной таблице трансляции) IPv4 и выполнять обычные функции NAT.
Можно встретить название PLAT для этого вида NAT, но это не совсем правильно. Термин PLAT применяется при использовании NAT464.
NAT46 (CLAT)
Как несложно догадаться - задача NAT46 ровно обратная NAT64. Его задача переделать IPv4 адрес в IPv6. Вот тут как раз чаще применяется термин CLAT, так как обычно в «свободном» виде NAT46 не встречается, а используется в NAT464
NAT464 (464XLAT)
По сути, это набор из CLAT и PLAT (NAT46 и NAT64), который позволяет прогонять IPv4 трафик внутри сети IPv6.
DNS64
Специальная версия (или специально настроенный) DNS, который умеет возвращать IPv6 запись для доменного имени, даже если её нет. Для этого он использует «специальный префикс», про который мы говорили выше. Т.е. для one.one.one.one он вернет 64:ff9b::101:101 вместо 1.1.1.1
В случае с Yggdrasil есть одна проблема - обычные DNS64 возвращают существующий IPv6, если он есть. Что нам не очень подходит, потому что у нас «серая» сеть IPv6 и к «белым» адресам доступа у нас нет. Вполне возможно, что это можно как-то победить (например в PowerDNS есть встроенный LUA, и, возможно, это поведение можно скорректировать). Либо можно взять yggdns64 который специально для этой задачи и был написан, но его нужно компилировать самостоятельно.
JOOL
Это реализация NAT64 и NAT46 под Linux. Все дальнейшие примеры настроек будут указанны именно для этой реализации. Есть ли что-то подобное под Windows (скорее всего - нет) или под FreeBSD (скорее всего - да) не проверялось.
Официальный сайт Jool: https://nicmx.github.io/Jool/en/index.html
Настройка
Так как проверялась работоспособность только на Linux Ubuntu 20.04 (и немножко на Windows в качестве клиента) и Jool 4.1.13, считается что используется именно этот комплект. Для установки Jool предварительно нужно установить DKMS.
Например, у Вас есть VDS через которую вы хотите выходить в интернет, т.е. сделать Exit Node. Глобально - рассматривается вот такой вариант сети
Но будет рассмотрен вариантf без CLAT с его плюсами и минусами.
NAT64
Начнём настройку с NAT64, потому что он нам потребуется в любом случае.
- Устанавливаем DKMS
- Скачиваем и устанавливаем Jool (в Ubuntu эта программа есть в системном репозитории)
- Добавляем в /etc/sysctl.conf две строчки
net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1
- Смотрим свой IPv6 yggdrasil адрес. Допустим, он 203:fafa:fefe:dede:1ea2:5545:73b5:bf02/7
- Создаём каталог /etc/jool и в нём такой файл:
- jool.conf
{ "comment": "Configuration for the systemd NAT64 Jool service for yggdrasil.", "instance": "default", "framework": "netfilter", "global": { "comment": "Sample pool6 prefix", "pool6": "303:fafa:fefe:dede:ff::/96", "lowest-ipv6-mtu": 20000, "maximum-simultaneous-opens": 100 }, "comment": "Sample pool4 table", "pool4": [], "bib": [] }
systemctl enable jool; systemctl start jool
Теперь проверям что у нас получилось. Сейчас, с любой другой машины с настроенным yggdrasil (обратите внимание - другой!) делаем так:
C:\>ping 303:fafa:fefe:dede:ff::1.1.1.1
Pinging 303:fafa:fefe:dede:ff:0:101:101 with 32 bytes of data:
Reply from 303:fafa:fefe:dede:ff:0:101:101: time=40ms
Reply from 303:fafa:fefe:dede:ff:0:101:101: time=41ms
Reply from 303:fafa:fefe:dede:ff:0:101:101: time=41ms
Reply from 303:fafa:fefe:dede:ff:0:101:101: time=41ms
Ping statistics for 303:fafa:fefe:dede:ff:0:101:101:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 41ms, Average = 40ms
Если вы получили такой-же результат - поздравляем. Вы настроили свой первый NAT64. Самое время перечитать дисклеймер в начале статьи. В статье Некоторые подробности установки jool в качестве NAT64 немного подробнее описана настройка Jool, какие могут встретиться подводные грабли и как их преодолеть.
Настраиваем firewall
В виду того, что Jool перехватывает пакеты данных до того, как они достигнут основных правил Фаерволла, то потребуется его дополнительная настройка. В этой секции подразумевается что используется префикс 303:fafa:fefe:dede:ff::/96, и то что на сервере с NAT64 установлен ip6tables.
Сначала мы добавляем правило, чтобы отбрасывать пакеты *до* того как их перехватит Jool:
ip6tables -t mangle -I PREROUTING -d 303:fafa:fefe:dede:ff::/96 -j DROP
Теперь нужно в следующем правиле разрешить пакеты от выбранных пользователей:
ip6tables -t mangle -I PREROUTING -s 2ff:0000:0000:0000:0000:0000:0000:0000/128 -d 303:fafa:fefe:dede:ff::/96 -j ACCEPT
для основного адреса
ip6tables -t mangle -I PREROUTING -s 3ff:0000:0000:0000::/64 -d 303:fafa:fefe:dede:ff::/96 -j ACCEPT
Используем CLAT но не используем DNS64
Вариант с отдельным роутером
Наверное это самый простой вариант, по сути практически полностью аналогичный классическому VPN. Имеет смысл использовать в том случае, если у вас несколько локальных машин, есть локальная сеть со своей адресацией и нужно весь трафик этой локалки пустить «наружу» через VPN (т.е. ровно как на картинке выше). Подразумевается, что у этого роутера настроен IPv4 адрес 192.168.0.1
И так:
- Устанавливаем DKMS
- Скачиваем и устанавливаем Jool
- Добавляем в /etc/sysctl.conf две строчки
net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1
- Смотрим свой IPv6 yggdrasil адрес. Допустим он 200:dead:beef:bebe:1424:7a39:8566:aa12/7
- Создаём каталог /etc/jool и в нём такой файл:
- jool_siit.conf
{ "comment": "Configuration for yggdrasil clat server.", "instance": "default", "framework": "netfilter", "global": { "comment": "pool6 prefix", "pool6": "303:fafa:fefe:dede:ff::/96", "lowest-ipv6-mtu": 20000 }, "comment": "EAM table", "eamt": [ { "ipv6 prefix": "300:dead:beef:bebe:ff::/96", "ipv4 prefix": "192.168.0.0/24" } ] }
systemctl enbale jool_siit; systemctl start jool_siit
Теперь проверям что у нас получилось. Сейчас, с любой другой машины (обратите внимание - другой!), у которой адрес 192.168.0.1 указан в качестве Default Gateway делаем трейсрут и проверяем, что трафик действительно пошёл через этот тунель.
Вариант без отдельного роутера
Этот вариант имеет смысл использовать когда у Вас один (или несколько стоящих разрозненно) компьютеров, в качестве операционной системы используется Linux и установлен Yggdrasil.
Есть несколько решений, они все подразумевают создание отдельного интерфейса. Один из вариантов описан в документации на сайте Jool. Но мы рассмотрим другой вариант - под него есть готовый скрипт, который всю «грязную работу» сделает за нас. Что нам потребуется:
- Командой yggdrasilctl getself нужно посмотреть какая 300/7 сеть выделена. Она потребуется ниже.
- Скачать и установить этот скрипт.
- На всякий случай - проверить что установлена Tayga, это аналог jool-siit (stateless NAT64). Если Вы устанавливали clatd методом sudo make -C clatd install installdeps - он должен сам поставить этот пакет, но лучше перепроверить. В Ubuntu он есть в системных пакетах, так что apt install tayga должно хватить.
- В каталоге /etc Создаём файл
- clatd.conf
clat-v6-addr=3XX:XXXX:XXXX:XXXX::X plat-prefix=303:fafa:fefe:dede:ff::/96 v4-conncheck-enable=no v4-defaultroute-replace=yes proxynd-enable=no ip6tables-enable=yes
systemctl enbale clatd; systemctl start clatd
В качетсве 3XX:XXXX:XXXX:XXXX::X пропишите свободный ip из той сети, что получили в пункте 2. Нужен именно свободный адрес, т.е. не назначенный никакому интерфейсу. Собственно - всё. Теперь весь IPv4 трафик пойдёт через Yggdrasil.
Используем DNS64, но не используем CLAT
Вариант тоже очень простой и применим в ситуации «yggdrasil only» конфигурации ноды. Т.е., на ней вобще нет IPv4 адреса, ну кроме 127.0.0.1, куда-же без него (желающих выпилить и его - ждёт масса очень интересного секса). Но система (Windows - сильнее, Linux - в меньшей степени) и часть софта немного «шизеют» от такого варианта. Причин несколько:
- IPv4 адреса становятся полностью недоступны. А часть софта (включая сами системы) любит проверять наличие сети методом пропингивания какого либо IPv4 адреса. А еще Гугловые поделия (например тот-же Хром), любят проверять наличие сети через резолвинг посредством своего DNS.
- При этом и белые IPv6 адреса тоже недоступны. И опять таки, часть софта (опять включая сами системы), не найдя IPv4 пытается повторить всё тоже самое посредством IPv6
- Но сеть-то есть! По крайней мере DNS работает. Софт всё больше «офигивает»…
- Но имя, которое должно резолвиться в IPv4 ВНЕЗАПНО резолвится в IPv6. Часть софта уходит в «полную несознанку» (например тот, который в принципе не умеет работать с IPv6)
Тем не менее, если у Вас на ноде есть работающий IPv4 и Вас не пугает, что часть трафика пойдёт мимо Yggdrasil - вариант работающий. Собственно, эта статья пишется именно с такой ноды. Но лучше использовать DNS64 + CLAT
Что нужно настраивать:
- Установить его где нибудь.
- В настройках ноды в качестве DNS использовать именно его.
- Для Firefox не помешает добавить такую настройку: network.manage-offline-status: false
Всё. Для проверки - достаточно сделать ping по доменному имени. Если имя резолвится в IPv6 - значит всё OK.
DNS64 + CLAT
Этот вариант хорошо использовать в ситуации, когда у вас на ноде есть и IPv4 и ygg-IPv6 адреса (т.е. у 99.9% пользователей Yggdrasil). У него плюсы обоих вариантов:
- Система и софт не дуреют от происходящего
- Весь IPv4 трафик ходит через туннель
И при этом почти нет недостатков
- Опять таки, система и софт не дуреют от происходящего. Ну кроме софта, который не умеет работать с IPv6 в принципе.
- Если используется DNS имя - трафик ходит мимо CLAT, т.е. Yggdrasil путь уменьшается на 1 хоп, что, по понятным причинам, очень хорошо сказывается на скорости.
В качестве заключения
На самом деле этим всё не ограничивается. Например, Jool можно настроить так, что бы она пробрасывала порт с внешнего IPv4 на ygg-IPv6. А еще, понятное дело, на один NAT64 можно повесить кучку CLAT. Но, как говорится, это не цель Yggdrasil. :)
