{{indexmenu_n>5}}
====== NAT64, NAT464, DNS64, CLAT, PLAT и другие страшные слова ======
С начала разработки IPv6 (а это очень старый протокол, его разработка была начата в 1994 году, а в 1995 уже был выпущен [[https://datatracker.ietf.org/doc/html/rfc1883|RFC1883]] на эту тему), было понятно, что какое-то время будут сосуществовать одновременно IPv4 и IPv6 протоколы, и нужно какое-то взаимодействие между ними. Для этого были придуманы некоторые правила трансляции адресов между IPv4 и IPv6. Так как [[yggdrasil:yggdrasil|Yggdrasil]] не является полноценной IPv6 сетью, а просто использует часть её адресации, в этом разделе не будет описываться "как правильно" настраивать взаимодействие "белой" IPv6 и IPv4 сети. \\
И да, эта статья рассказывает "как", но не рассказывает "зачем". Если вам проще поднять [[:wireguard]] over Yggdrasil - делайте, как вам удобнее.
:!: **Для использования дальнейшей информации требуется знание/понимание устройства сетей и умение работать в командной строке Linux**
^:!: DISCLAIMER^
| Всегда помните, что без [[yggdrasil:firewall_setup|настроек firewall]] ваша нода доступна из сети Yggdrasil всем и каждому. Если в результате через вашу ноду выйдут в "белый интернет" злые хакеры и взломают Пентагон / разместят на форуме призывы к свержению существующего строя / выложат в сеть детскую порнографию, то в первую очередь прийдут именно к вам. Не забывайте настраивать firewall (это относится не только к этой статье, а и в целом к использованию Yggdrasil). Если что - мы вас предупредили!|
===== Общее представление что это такое =====
Для начала давайте определимся, что это за страшные слова и для чего каждый из компонентов используется. Объяснение очень "на пальцах", если интересует больше подробностей очень рекомендую начать с чтения [[https://www.jool.mx/en/documentation.html|документации на 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 запись для доменного имени, даже если её нет. Для этого он использует "специальный префикс", про который мы [[yggdrasil:tunnels:nat64#nat64_plat|говорили выше]]. Т.е. для **one.one.one.one** он вернет **64:ff9b::101:101** вместо **1.1.1.1**
В случае с Yggdrasil есть одна проблема - обычные DNS64 возвращают существующий IPv6, если он есть. Что нам не очень подходит, потому что у нас "серая" сеть IPv6 и к "белым" адресам доступа у нас нет. Вполне возможно, что это можно как-то победить (например в [[https://www.powerdns.com/|PowerDNS]] есть встроенный [[https://doc.powerdns.com/authoritative/lua-records/index.html|LUA]], и, возможно, это поведение можно скорректировать). Либо можно взять [[https://github.com/ufm/yggdns64|yggdns64]] который специально для этой задачи и был написан, но его нужно компилировать самостоятельно.
==== JOOL ====
Это реализация NAT64 и NAT46 под Linux. Все дальнейшие примеры настроек будут указанны именно для этой реализации. Есть ли что-то подобное под Windows (скорее всего - нет) или под FreeBSD (скорее всего - да) не проверялось.
Официальный сайт Jool: https://www.jool.mx/
===== Настройка =====
:!: Так как проверялась работоспособность только на **Linux Ubuntu 20.04** (и немножко на Windows в качестве клиента) и **Jool 4.1.7**, считается что используется именно этот комплект. Для установки **Jool** предварительно нужно установить **[[wpru>Dynamic_Kernel_Module_Support|DKMS]]**.
Например, у Вас есть **VDS** через которую вы хотите выходить в интернет, т.е. сделать Exit Node. Глобально - рассматривается вот такой вариант сети
{{ :yggdrasil:nat464-1.png |}}
Но будет рассмотрен вариантf без CLAT с его плюсами и минусами.
==== NAT64 ====
Начнём настройку с NAT64, потому что он нам потребуется в любом случае.
- [[https://yggdrasil-network.github.io/installation.html|Устанавливаем Yggdrasil]]
- Устанавливаем DKMS
- [[https://www.jool.mx/en/download.html|Скачиваем]] и [[https://www.jool.mx/en/documentation.html#installation|устанавливаем]] 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** и в нём такой файл:
{
"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**. Самое время перечитать дисклеймер в начале статьи. В статье [[yggdrasil:tunnels:jool]] немного подробнее описана настройка 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 для [[yggdrasil:network_connection_variants|маршрутизируемой подсети /64]]
==== Используем CLAT но не используем DNS64 ====
=== Вариант с отдельным роутером ===
Наверное это самый простой вариант, по сути практически полностью аналогичный классическому **VPN**. Имеет смысл использовать в том случае, если у вас несколько локальных машин, есть локальная сеть со своей адресацией и нужно весь трафик этой локалки пустить "наружу" через **VPN** (т.е. ровно как на картинке выше). Подразумевается, что у этого роутера настроен IPv4 адрес **192.168.0.1**
И так:
- [[https://yggdrasil-network.github.io/installation.html|Устанавливаем Yggdrasil]]
- Устанавливаем DKMS
- [[https://www.jool.mx/en/download.html|Скачиваем]] и [[https://www.jool.mx/en/documentation.html#installation|устанавливаем]] 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** и в нём такой файл:
{
"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.
Есть несколько решений, они все подразумевают создание отдельного интерфейса.
Один из вариантов описан в [[https://www.jool.mx/en/node-based-translation.html|документации]] на сайте Jool. Но мы рассмотрим другой вариант - под него есть готовый скрипт, который всю "грязную работу" сделает за нас. Что нам потребуется:
- [[https://yggdrasil-network.github.io/installation.html|Установить Yggdrasil]]
- Командой **[[yggdrasil:admin_api#getself|yggdrasilctl getself]]** нужно посмотреть какая **300/7** сеть выделена. Она потребуется ниже.
- [[https://github.com/toreanderson/clatd|Скачать]] и установить этот скрипт.
- На всякий случай - проверить что установлена [[http://www.litech.org/tayga/|Tayga]], это аналог jool-siit (stateless NAT64). Если Вы устанавливали clatd методом **sudo make -C clatd install installdeps** - он должен сам поставить этот пакет, но лучше перепроверить. В **Ubuntu** он есть в системных пакетах, так что **apt install tayga** должно хватить.
- В каталоге **/etc** Создаём файл
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**
Что нужно настраивать:
- [[https://github.com/ufm/yggdns64|Скачать]] и скомпилировать (он написано на [[go:go|Go]]) yggdns64 (или найти и настроить его аналог).
- Установить его где нибудь.
- В настройках ноды в качестве 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**. Но, как говорится, [[hm:not_a_goal|это не цель Yggdrasil]]. :)
~~DISCUSSION~~