💾 Archived View for betahowto.duckdns.org › yggdrasil:tunnels:nat64 captured on 2024-02-05 at 10:04:42. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

NAT64, NAT464, DNS64, CLAT, PLAT и другие страшные слова

С начала разработки IPv6 (а это очень старый протокол, его разработка была начата в 1994 году, а в 1995 уже был выпущен RFC1883 ( https://datatracker.ietf.org/doc/html/rfc1883 ) на эту тему), было понятно, что какое-то время будут сосуществовать одновременно IPv4 и IPv6 протоколы, и нужно какое-то взаимодействие между ними. Для этого были придуманы некоторые правила трансляции адресов между IPv4 и IPv6. Так как Yggdrasil ( /yggdrasil:yggdrasil ) не является полноценной IPv6 сетью, а просто использует часть её адресации, в этом разделе не будет описываться "как правильно" настраивать взаимодействие "белой" IPv6 и IPv4 сети.

И да, эта статья рассказывает "как", но не рассказывает "зачем". Если вам проще поднять ( /wireguard ) over Yggdrasil - делайте, как вам удобнее.

:!: Для использования дальнейшей информации требуется знание/понимание устройства сетей и умение работать в командной строке Linux

^:!: DISCLAIMER^

| Всегда помните, что без настроек firewall ( /yggdrasil:firewall_setup ) ваша нода доступна из сети Yggdrasil всем и каждому. Если в результате через вашу ноду выйдут в "белый интернет" злые хакеры и взломают Пентагон / разместят на форуме призывы к свержению существующего строя / выложат в сеть детскую порнографию, то в первую очередь прийдут именно к вам. Не забывайте настраивать firewall (это относится не только к этой статье, а и в целом к использованию Yggdrasil). Если что - мы вас предупредили!|

Общее представление что это такое

Для начала давайте определимся, что это за страшные слова и для чего каждый из компонентов используется. Объяснение очень "на пальцах", если интересует больше подробностей очень рекомендую начать с чтения документации на Jool ( https://www.jool.mx/en/documentation.html ), про который будет ниже.

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 и к "белым" адресам доступа у нас нет. Вполне возможно, что это можно как-то победить (например в PowerDNS ( https://www.powerdns.com/ ) есть встроенный LUA ( https://doc.powerdns.com/authoritative/lua-records/index.html ), и, возможно, это поведение можно скорректировать). Либо можно взять yggdns64 ( https://github.com/ufm/yggdns64 ) который специально для этой задачи и был написан, но его нужно компилировать самостоятельно.

JOOL

Это реализация NAT64 и NAT46 под Linux. Все дальнейшие примеры настроек будут указанны именно для этой реализации. Есть ли что-то подобное под Windows (скорее всего - нет) или под FreeBSD (скорее всего - да) не проверялось.

Официальный сайт Jool: https://www.jool.mx/

Настройка

:!: Так как проверялась работоспособность только на Linux Ubuntu 20.04 (и немножко на Windows в качестве клиента) и Jool 4.1.7, считается что используется именно этот комплект. Для установки Jool предварительно нужно установить DKMS ( https://ru.wikipedia.org/wiki/Dynamic_Kernel_Module_Support ).

Например, у Вас есть VDS через которую вы хотите выходить в интернет, т.е. сделать Exit Node. Глобально - рассматривается вот такой вариант сети

Но будет рассмотрен вариантf без CLAT с его плюсами и минусами.

NAT64

Начнём настройку с NAT64, потому что он нам потребуется в любом случае.

Устанавливаем Yggdrasil ( https://yggdrasil-network.github.io/installation.html )
Устанавливаем 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

jool.conf

  - Создаём каталог **/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 enbale jool; systemctl start jool</code>

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

Используем CLAT но не используем DNS64

Вариант с отдельным роутером

Наверное это самый простой вариант, по сути практически полностью аналогичный классическому VPN. Имеет смысл использовать в том случае, если у вас несколько локальных машин, есть локальная сеть со своей адресацией и нужно весь трафик этой локалки пустить "наружу" через VPN (т.е. ровно как на картинке выше). Подразумевается, что у этого роутера настроен IPv4 адрес 192.168.0.1

И так:

Устанавливаем Yggdrasil ( https://yggdrasil-network.github.io/installation.html )
Устанавливаем 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

jool_siit.conf

  - Создаём каталог **/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</code>

Теперь проверям что у нас получилось. Сейчас, с любой другой машины (обратите внимание - другой!), у которой адрес 192.168.0.1 указан в качестве Default Gateway делаем трейсрут и проверяем, что трафик действительно пошёл через этот тунель.

Вариант без отдельного роутера

Этот вариант имеет смысл использовать когда у Вас один (или несколько стоящих разрозненно) компьютеров, в качестве операционной системы используется Linux и установлен Yggdrasil.

Есть несколько решений, они все подразумевают создание отдельного интерфейса.

Один из вариантов описан в документации ( https://www.jool.mx/en/node-based-translation.html ) на сайте Jool. Но мы рассмотрим другой вариант - под него есть готовый скрипт, который всю "грязную работу" сделает за нас. Что нам потребуется:

Установить Yggdrasil ( https://yggdrasil-network.github.io/installation.html )
Командой yggdrasilctl getself ( /yggdrasil:admin_api#getself ) нужно посмотреть какая 300/7 сеть выделена. Она потребуется ниже.
Скачать ( https://github.com/toreanderson/clatd ) и установить этот скрипт.
На всякий случай - проверить что установлена Tayga ( http://www.litech.org/tayga/ ), это аналог jool-siit (stateless NAT64). Если Вы устанавливали clatd методом sudo make -C clatd install installdeps - он должен сам поставить этот пакет, но лучше перепроверить. В Ubuntu он есть в системных пакетах, так что apt install tayga должно хватить.

clatd.conf

  - В каталоге **/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</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. Но, как говорится, это не цель Yggdrasil ( /hm:not_a_goal ). :)