howto-db/data/pages/yggdrasil/tunnels/nat64.txt

====== 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** две строчки <code>net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1</code>
  - Смотрим свой IPv6 yggdrasil адрес. Допустим, он **203:fafa:fefe:dede:1ea2:5545:73b5:bf02/7**
  - Создаём каталог **/etc/jool** и в нём такой файл: <file - 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": []
}

</file>
  - <code>systemctl enbale jool; systemctl start jool</code>

Теперь проверям что у нас получилось. Сейчас, с любой **другой** машины с настроенным yggdrasil (обратите внимание - **другой**!) делаем так:
<code>
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
</code>

Если вы получили такой-же результат - поздравляем. Вы настроили свой первый **NAT64**. Самое время перечитать дисклеймер в начале статьи. В статье [[yggdrasil:tunnels:jool]] немного подробнее описана настройка Jool, какие могут встретиться подводные грабли и как их преодолеть.

==== Используем 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** две строчки <code>net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1</code>
  - Смотрим свой IPv6 yggdrasil адрес. Допустим он **200:dead:beef:bebe:1424:7a39:8566:aa12/7**
  - Создаём каталог **/etc/jool** и в нём такой файл: <file - 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"
                }
        ]
}
</file>
  - <code>systemctl enbale jool_siit; systemctl start jool_siit</code>

Теперь проверям что у нас получилось. Сейчас, с любой **другой** машины (обратите внимание - **другой**!), у которой адрес **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** Создаём файл <file - 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
</file>
  - <code>systemctl enbale clatd; systemctl start clatd</code>

В качетсве **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~~