HowTo Yggdrasil - yggdrasil:tunnels

GRE-туннель

anonymous@undisclosed.example.com (Anonymous) — Wed, 22 Oct 2025 08:13:20 +0000

GRE-туннель

GRE (Generic Routing Encapsulation) - это один из простейших протоколов туннелирования, представляющий собой соединение узлов по принципу точка - точка.

Туннелирование - это, по сути, упаковка наших данных (например, протокол IP) в определенный пакет, который передаётся от узла-отправителя к узлу-получателю. На узле-получателе пакет распаковывается и изначальные данные продолжают свой путь.

GRE в чистом виде никак не защищен, нет никакого шифрования данных в пакете, и за счет этого данные в GRE-туннелях передаются с минимальными потерями в скорости и минимальным увеличением объема передаваемых данных.

Часто GRE используется совместно с протоколами защиты сетевого трафика, например IPSec. И это по сути представляет собой практически полноценное решение для организации виртуальных частных сетей (VPN).

Используя чистый GRE внутри Yggdrasil можно с различными целями легко строить туннели, аналогичные привычным VPN. Защита тахих туннелей будет обеспечена самим Yggdrasil, трафик в котором шифруется по-умолчанию.

Например, с помощью GRE туннеля внутри Yggdrasil можно настроить на удаленной машине шлюз в интернет. Т.е., вы на своей домашней машине с помощью Yggdrasil можете соединяться с удаленным сервером, который будет маршрутизировать ваши данные, упакованные GRE в интернет, и c точки зрения использования всё это будет происходить аналогично тому, как это происходит при установке OpenVPN-соединения или L2TP/IPSec.

Команды для создания GRE-туннеля можно вводить вручную, можно написать bash-скрипт, либо можно использовать /etc/network/interfaces (либо юнит systemd) для поднятия туннелей автоматически при загрузке системы.

Для примера:

#какие туннели уже есть в системе (если ранее не создавали, вывод команды будет пуст)
ip tunnel show
ip -6 tunnel show

#какие интерфейсы есть в системе
ifconfig -a

#создание туннеля 
sudo ip tunnel add tun1 mode ip6gre remote 0200:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx local 0203:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx dev tun0

#активация туннеля
sudo ip link set tun1 up

#назначение адреса
sudo ip link set dev tun1 address xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

#уничтожение туннеля
sudo ip link set tun1 down
sudo ip tunnel del tun1

Пример с gretap (второй уровень OSI):

sudo ip link add yggvpn0 type ip6gretap local 0200:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx remote 0203:xxxx:xxxx:xxxx:xxxx:xxxx:xxx:xxxx key 1
sudo ip link set dev yggvpn0 address xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
#удаление
sudo ip link del dev yggvpn0

Не забывайте открывать доступ по протоколу GRE в iptables. Интерфейс GRE можно назначить шлюзом по-умолчанию - работа будет аналогичной VPN.

Практический пример: GRE-туннель IPv4 over IPv6

Имеем две машины: t1 и t2, соединенные посредством Yggdrasil.

	t1	t2
Yggdrasil IPv6	204:f52f:7bb4:c8c2:21f9:6972:14f5:32fd	200:862d:85a4:6b85:4fc1:55a3:fa3:7b0e
Доступ в интернет	Есть	Нет

Создадим GRE-туннель и «пробросим» через него доступ в интернет для машины t2. Машины «в туннеле» будут иметь IPv4-адреса. Для доступа в интернет с t2 будем использовать NAT.

Действия на t1

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

sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv6.conf.all.forwarding=1

Чтобы эти настройки сохранились после перезагрузки в файле /etc/sysctl.conf раскомментируем:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Непосредственно, создание туннеля:

#создаем туннель
ip tunnel add tun1 mode ip6gre remote 0200:862d:85a4:6b85:4fc1:55a3:fa3:7b0e local 0204:f52f:7bb4:c8c2:21f9:6972:14f5:32fd dev tun0

#присваиваем IPv4-адрес на интерфейс туннеля и сразу добавляем маршрут ко второму концу (10.1.1.2) через этот интерфейс
ip addr add dev tun1 local 10.1.1.1 remote 10.1.1.2 #t1 будет иметь адрес 10.1.1.1, t2 - 10.1.1.2.

#поднимаем туннель
ip link set tun1 up

NAT c помощью iptables:

iptables -A FORWARD -i tun1 -j ACCEPT
iptables -A FORWARD -o tun1 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Действия на t2

Симметричные действия для поднятия туннеля:

ip tunnel add tun1 mode ip6gre remote 0204:f52f:7bb4:c8c2:21f9:6972:14f5:32fd local 0200:862d:85a4:6b85:4fc1:55a3:fa3:7b0e dev tun0
ip addr add dev tun1 local 10.1.1.2 remote 10.1.1.1
ip link set tun1 up

Добавим маршрут по умолчанию для доступа в интернет:

route add default gw 10.1.1.1

Примечание: если на t2 доступ в интернет уже есть и Yggdrasil на t2 подключен к публичным пирам, а вы просто настраиваете VPN c использованием Yggdrasil, необходимо будет прописать муршрут к пирам в обход туннеля, иначе соединение с ними прервётся. Пример добавления маршрута до публичного пира, в обход туннеля: sudo ip route add 62.210.85.80/32 via 192.168.1.1 dev wlo1; 62.210.85.80 - адрес публичного пира, 192.168.1.1 - адрес шлюза в интернет (домашнего роутера), wlo1 - имя интерфейса, через который подключаетесь к шлюзу.

В /etc/resolv.conf можно прописать DNS-сервер:

nameserver 8.8.8.8

На обеих машинах в iptables разрешаем GRE, если оно запрещено:

ip6tables -I INPUT -p gre -j ACCEPT

Вот, собственно, и всё.

Получили почти классическую схему VPN-сервера (в роли которого выступает t2) для доступа к ошибочно заблокированным РКН сайтам.

Кроме того, так можно обеспечить выход в интернет устройства, подключенного к Yggdrasil, например, с помощью 802.11s (Wi-Fi Mesh).

А еще, такой туннель можно использовать для коммуникации приложений, которые не поддерживают IPv6, если вы соединены только через Yggdrasil.

Примечание: читайте так же о настройке IPIP-туннеля через Yggdrasil: IPIP-туннель.

Ссылки

АйТи бубен: GRE https://wiki.dieg.info/gre
Сети для самых маленьких. Часть седьмая. VPN https://habr.com/ru/post/170895/
Linux Advanced Routing & Traffic Control HOWTO. Глава 5. GRE и другие тоннели https://docstore.mik.ua/manuals/ru/LARTC/x418.html
Знакомство с виртуальными интерфейсами Linux: туннели https://temofeev.ru/info/articles/znakomstvo-s-virtualnymi-interfeysami-linux-tunneli/
Простой Ethernet-туннель на Linux в четыре-шесть команд https://habr.com/ru/post/227859/

IPIP-туннель

anonymous@undisclosed.example.com (Anonymous) — Wed, 22 Oct 2025 08:13:20 +0000

IPIP-туннель

Давным-давно в далекой галактике… в одном из чатов сообщества кто-то поделился PDF-файлом, в котором описывалось создание IPIP-туннеля поверх Yggdrasil. Автор использовал эти технологии для организации VPN-сервера на VPS, когда используемый им ранее протокол Wireguard начала блокировать тёмная сторона…

Здесь будет краткое изложение этой статьи. Ссылка на сам PDF-файл будет приведена в разделе Ссылки. К сожалению, не нашел оригинального сообщения с этим файлом в чате и не помню имени автора, иначе обязательно бы назвал его (e-mail автора есть в PDF-файле).

Да, здесь уже есть статья о настройке GRE-туннеля (технологии похожи), но решил опубликовать и про IPIP, просто для того, чтобы было [в одном месте].

Основные отличия (с точки зрения пользователя) GRE от IPIP - GRE поддерживает Multicast и инкапсулирование любого протокола третьего уровня, IPIP не поддерживает Multicast и инкапсулирует только IP (IPIP - IP over IP).

Примечание: Под IPIP здесь подразумевается IPIP6 (работаем с IPv6 адресами Yggdrasil).

Итак…

VPN c помощью Yggdrasil и IPIP

Настройка клиента

Примечание: подразумевается, что Yggdrasil уже установлен и на клиенте и на сервере (VPS), пиры прописаны, доступ к сети есть; Yggdrasil использует интерфейс tun0.

Для начала необходимо уточнить наши IPv6-адреса Yggdrasil.

Выполним команду на клиенте:

ip -br a show tun0

В результате увидим:

tun0 UNKNOWN 200:d4a5:ec3f:5914:274c:8f70::660/7

где 200:d4a5:ec3f:5914:274c:8f70::660 наш IPv6 адрес Yggdrasil.

Выполним ту же команду на сервере, увидим:

tun0 UNKNOWN 200:d4a5:ec3f:5914:274c:8f70::1/7

Здесь, соответственно, видим адрес Yggdrasil на сервере.

Создаём туннель на клиенте:

sudo ip link add name ipip6 type ip6tnl local 200:d4a5:ec3f:5914:274c:8f70::660 remote 200:d4a5:ec3f:5914:274c:8f70::1 mode ipip6

После создания туннеля у нас появятся два новых интерфейса:

ip -br a

ip6tnl0@NONE DOWN
tun0 UNKNOWN 200:d4a5:ec3f:5914:274c:8f70::660/7
ipip6@NONE DOWN

Работать мы будем с интерфейсом ipip6.

Включим этот интерфейс:

sudo ip link set ipip6 up

Далее вам нужно будет определиться с адресом подсети IPv4 , которая будет работать внутри туннеля. Это может быть например 192.168.44.0/30. Из этой подсети с такой маской мы можем взять только два адреса (а больше в нашем случае и не нужно). Первый для конца туннеля на локальной машине, второй для конца туннеля на удаленном VPS.

Пускай это будут:

192.168.44.1 #Для удаленного vps
192.168.44.2 #Для локальной машины

Назначим адрес IPv4 для нашего туннеля:

sudo ip address add 192.168.44.2/30 dev ipip6

Маршрутизация

Теперь нам нужно отправить наш IPv4 трафик на VPS. На локальной машине нам нужно будет создать пару маршрутов.

По первому маршруту нужно пояснить. У вас в Yggdrasil прописан как минимум один peer через которого вы выходите в сеть. Так вот нам нужно что-бы соединение с этим пиром шло обязательно через интернет, не через сеть Yggdrasil. Потому-что мы не можем соединиться с сетью Yggdrasil через неё же саму, получается зацикливание. Из-за этого ничего работать не будет. Поэтому нам и нужен маршрут, который будет всегда «роутить» соединение до пира через обычный интернет. Как раз это правило маршрутизации нам в этом поможет.

Подставьте вместо XX.XX.XX.XX/32 IP-адрес вашего клирнет пира yggdrasil, а вместо YY.YY.YY.YY IP-адрес вашего домашнего роутера, wifi0 - замените на интерфейс на котором у вас ваша домашняя сеть.

sudo ip route add XX.XX.XX.XX/32 via YY.YY.YY.YY dev wifi0

Далее прописываем следующий маршрут. Этот маршрут будет отправлять весь остальной трафик через наш туннель на VPS.

sudo ip route add 0.0.0.0/0 via 192.168.44.2 dev ipip6

Настройка сервера (VPS)

Настройка будет такая же, разница только в IP-адресах. При создании туннеля нужно поменять IPv6 адреса местами Local IP ←→ Remote IP

sudo ip link add name ipip6 type ip6tnl local 200:d4a5:ec3f:5914:274c:8f70::1 remote 200:d4a5:ec3f:5914:274c:8f70::660 mode ipip6

Назначение IPv4-адреса на интерфейс:

sudo ip address add 192.168.44.1/30 dev ipip6

Настройка iptables

Теперь мы напишем правила для iptables , которые проведут наш трафик из туннеля в интернет.

Вместо eth0 подставьте интерфейс, с которого у вас выход в интернет.

# Эти два правила разрешат пересылку пакетов между интерфейсами
sudo iptables -A FORWARD -i eth0 -o ipip6 -j ACCEPT
sudo iptables -A FORWARD -i ipip6 -o eth0 -j ACCEPT
# Это правило подменит локальный ip адрес (192.168.44.2) при выходе из интерфейса eth0 на внешний ip
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Проверка работоспособности

Всё, туннель у нас должен работать. Для проверки работоспособности «попингуйте» друг друга через туннельные ip:

ping 192.168.44.1 #На локальной машине
ping 192.168.44.2 #На удаленной машине

Если всё «пингуется» в обе стороны, то туннель успешно работает. Далее проверьте, что интернет работает именно через туннель.

# Здесь мы видим что трафик уходит через ip нашего туннеля
> traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.100.44.1 93.791 ms 98.394 ms 98.443 ms
2 49.11.8.1 98.441 ms 98.434 ms 98.419 ms
...

Заключение

После этого у нас на локальной машине должен работать интернет через туннель, который проходит через сеть Yggdrasil.

Стоит напомнить что все эти настройки сбросятся после перезагрузки. Так что, вам необходимо их прописать в конфигурационные файлы ваших дистрибутивов Linux. Для интерфейсов это можно сделать через Systemd-Networkd с помощью файлов netdev. А с помощью файлов network можно назначить IP-адреса на интерфейсы. Для iptables правила можно прописать в файле /etc/iptables/iptables.conf

Ссылки

Оригинальная статья в PDF (RU): VPN через Yggdrasil

Некоторые подробности установки jool в качестве NAT64

anonymous@undisclosed.example.com (Anonymous) — Wed, 22 Oct 2025 08:13:20 +0000

Некоторые подробности установки jool в качестве NAT64

В статье NAT64, NAT464, DNS64, CLAT, PLAT и другие страшные слова при описании установки и настройки jool в качестве NAT64 был использован очень «наивный» конфиг. В 99.9% случаев он будет работать, но иногда возможны некоторые проблемы. Плюс, там не описана возможность обратного (из clearnet в yggnet) проброса портов. В этой статье мы постараемся исправить этот недостаток.

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

DISCLAIMER

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

Общая настройка системы

Перед использованием nat64 необходимо выполнить следующее:

Посмотреть и запомнить/записать какие есть запущенные сервисы и на каких портах они слушают.
Выполнить команду sysctl net.ipv4.ip_local_port_range и запомнить/записать диапазон портов.

Настройка sysctl.conf

В /etc/sysctl.conf нужно добавить три строчки

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv4.ip_local_port_range=50000 65500

Значения в третьей строчке нужно выбирать из Ваших потребностей. Если на сервере, на котором вы поднимаете NAT64, много локальных сервисов, которые активно ходят в интернет - возможно Вам придётся увеличить этот диапазон. Если при выполнении команды sysctl net.ipv4.ip_local_port_range вы получили диапазон 32768 - 60999 и Вы не планируете большого количества сессий через Ваш NAT64 - вобще не вводите третью строчку. Следующее предупреждение настолько важное, что оно будет написано дважды, в этом разделе и в следующем:

ВАЖНО: Диапазон портов выводимый командой sysctl net.ipv4.ip_local_port_range и список портов, которые «слушают» другие программы никогда не должен пересекаться с диапазоном портов используемых NAT64!!!

Настройка jool.conf

Базово файл /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": []
}

Это - минимально-достаточный конфиг, при котором, скорее всего, обычный NAT64 будет работать без каких либо проблем. Проблемы будут в трёх случаях:

Если диапазон, который вывела команда sysctl net.ipv4.ip_local_port_range пересекается с диапазоном 61001 - 65535, используемый jool по умолчанию (и Вы его не поменяли) или/и в этом диапазоне «слушает» какая либо программа.
Если Вы хотите выпустить в публичную сеть через этот NAT64 много yggdrasil узлов, например офис или домашнюю сетку. Штатного диапазона Вам может просто не хватить.
Если Вы планируете обратный проброc портов, которые не попадают в диапазон 61001 - 65535

Если ни один из этих случаев не касается Вас, и вы пришли сюда из статьи NAT64, NAT464, DNS64, CLAT, PLAT и другие страшные слова - можете спокойно вернуться к чтению той статьи. Никаких проблем у Вас не будет.

Решение проблем

И так, Вы прочитали предыдущий раздел и поняли, что у вас какие-то проблемы всё таки есть. Дальше будет написано как их решать.

Проблема: пересекаются диапазоны портов

Если пересекается только вывод net.ipv4.ip_local_port_range, то самый простой способ решения - поменять диапазон портов используемыйх системой.

Внесение в /etc/sysctl.conf строчки net.ipv4.ip_local_port_range = 32768 60999 скорее всего решит Вашу проблему. Это диапазон, используемый, например, в Ubuntu по умолчанию. Хватает им, хватит и Вам. Или назначьте свой диапазон. Главное - он не должен пересекаться с используемым диапазоном NAT64 по умолчанию.

Если-же, пересекается порт, который «слушает» какя либо программа - читайте дальше.

Проблема: диапазон слишком маленький

Придётся внести дополнительные настройки в файл /etc/jool/jool.conf в секцию pool4

        "pool4": [
                {
                        "protocol": "TCP",
                        "prefix": "1.1.1.1/32",
                        "port range": "20000-49999"
                }, {
                        "protocol": "UDP",
                        "prefix": "1.1.1.1/32",
                        "port range": "20000-49999",
                }, {
                        "protocol": "ICMP",
                        "prefix": "1.1.1.1/32",
                        "port range": "1000-2000"
                }

        ],

(вместо 1.1.1.1 Вам нужно указать тот «белый» IPv4, через который вы делаете NAT64) и внести изменения в /etc/sysctl.conf, добавив строчку net.ipv4.ip_local_port_range=50000 65500.

Проблема: я хочу пробрасывать порты

Собственно, вся эта статья затевалась именно для того, что бы написать про эту возможность (кто сказал, что использование данной вики в качестве личной записной книжки - плохая идея? ). Допустим, необходимо все пакеты приходящие на 100-й и 105-й порт «белого» IPv4 адреса пробрасывать на 100-й и 105-й порт какого либо yggdrasil адреса. Нам потребуется внести следующие изменения в файл /etc/jool/jool.conf

        "pool4": [
                {
                        "protocol": "TCP",
                        "prefix": "1.1.1.1/32",
                        "port range": "100"
                },{
                        "protocol": "TCP",
                        "prefix": "1.1.1.1/32",
                        "port range": "105"
                },{
                        "protocol": "TCP",
                        "prefix": "1.1.1.1/32",
                        "port range": "20000-49999",
                }, {
                        "mark": 0,
                        "protocol": "UDP",
                        "prefix": "1.1.1.1/32",
                        "port range": "20000-49999",
                }, {
                        "mark": 0,
                        "protocol": "ICMP",
                        "prefix": "1.1.1.1/32",
                        "port range": "1000-2000"
                }

        ],
        "bib": [
                {
                        "protocol": "TCP",
                        "ipv6 address": "312:f7fc:fafe:d0d5:1::dead#80",
                        "ipv4 address": "1.1.1.1#100"
                },{
                        "protocol": "TCP",
                        "ipv6 address": "312:f7fc:fafe:d0d5:1::dead#443",
                        "ipv4 address": "1.1.1.1#105"
                }

        ]
}

(вместо 1.1.1.1 указываем свой белый адрес, вместо 312:f7fc:fafe:d0d5:1::dead адрес, куда нам нужно пробрасывать порт), и не забываем внести изменения в /etc/sysctl.conf, добавив строчку net.ipv4.ip_local_port_range=50000 65500.

Резюме

Jool - это очень мощное средство, когда Вам необходимо связать между собой IPv6 и IPv4 сети. И тривиальным NAT64 оно не ограничивается. Настоятельно рекомендуется сходить к ним на сайт и почитать документацию.

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

anonymous@undisclosed.example.com (Anonymous) — Wed, 22 Oct 2025 08:13:20 +0000

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). Если что - мы вас предупредили!

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, потому что он нам потребуется в любом случае.

Устанавливаем Yggdrasil
Устанавливаем 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

для маршрутизируемой подсети /64

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

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

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

И так:

Устанавливаем Yggdrasil
Устанавливаем 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. Но мы рассмотрим другой вариант - под него есть готовый скрипт, который всю «грязную работу» сделает за нас. Что нам потребуется:

Установить Yggdrasil
Командой 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

Что нужно настраивать:

Скачать и скомпилировать (он написано на 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. :)

Проброс соединений 6-4 (4-6) с помощью socat

anonymous@undisclosed.example.com (Anonymous) — Tue, 21 Apr 2026 13:26:27 +0000

Проброс соединений 6-4 (4-6) с помощью socat

Socat - это утилита на основе командной строки, которая устанавливает два двунаправленных потока байтов и передает данные между ними. Поскольку потоки могут быть сконструированы из большого набора различных типов приемников данных и источников, а также поскольку к потокам может быть применено множество вариантов адресации, socat можно использовать для самых разных целей.

Ниже будет пара примеров использования утилиты socat для проброса соединений с IPv4 на IPv6 и обратно.

Это может понадобиться, например, если у вас есть очень старое устройство, которое не поддерживает протокол IPv6, но вы хотите вывести его в Yggdrasil.

Установка

Установить утилиту в дистрибутиве на базе Debian можно так:

sudo apt install socat

Для Windows socat можно скачать, например, отсюда: https://sourceforge.net/projects/unix-utils/files/socat/1.7.3.2/

4-6

socat TCP4-Listen:4321,fork TCP6:[222:a8e4:50cd:55c:788e:b0a5:4e2f:a92c]:80

Допустим, мы выполнили эту команду на устройстве, подключенном к Yggdrasil и имеющим локальный IPv4-адрес: 192.168.1.3

На устройстве, которое не подключено к Yggdrasil, но так же подключено к локальной сети IPv4, запускаем браузер, вбиваем в адресную строку: http://192.168.1.3:4321 и что же видим?

А увидим мы стартовую страницу этого ресурса.

Браузер устанавливает TCP-соединение c 192.168.1.3:4321, на этом адресе и порте слушает socat, который «перебрасывает» соединение на [222:a8e4:50cd:55c:788e:b0a5:4e2f:a92c]:80.

Ключ fork означает, что после установки соединения оно переносится в дочерний процесс, а родительский процесс (socat) после этого будет готов принимать новые соединения.

Как видите, всё довольно просто :)

6-4

socat TCP6-Listen:4321,fork TCP4:192.168.1.10:5000

Выполняем эту команду на устройстве, подключенном к Yggdrasil.

На другом устройстве (так же подключенном к Yggdrasil) открываем браузер, вбиваем в адресной строке http://[203:52a2:a8fa:3f22:71cd:8310:6f4:f771]:4321 (Yggdrasil-адрес первого устройства) и попадаем в Web-интерфейс устройства с адресом ЛВС 192.168.1.10 [как бы, не подключенного к Yggdrasil] (естественно, адреса и порты должны быть правильные, рабочие (на устройствах должны быть запущены соответствующие сервисы)).

6-4 & 4-6

Ну, и напоследок строка для запуска экземпляров socat для проброса соединений с 4 на 6 и с 6 на 4 одновременно. Команды выполняем на устройстве, подключенном к Yggdrasil, имеющим адреса: 192.168.1.3 и 203:52a2:a8fa:3f22:71cd:8310:6f4:f771.

socat TCP4-LISTEN:4322,fork TCP6:[202:421a:2eb5:40a4:fa32:f4a4:9b42:d4e4]:3202|socat TCP6-Listen:4321,fork TCP4:192.168.1.10:16881

Для проверки того, что у нас получилось выполним:

sudo netstat -natup |grep socat

tcp        0      0 0.0.0.0:4322            0.0.0.0:*               LISTEN      8428/socat          
tcp6       0      0 :::4321                 :::*                    LISTEN      8429/socat

Слушаем IPv4 на 4322 и IPv6 на 4321.

4322 перенаправляем на [202:421a:2eb5:40a4:fa32:f4a4:9b42:d4e4]:3202; 4321 перенаправляем в обратную сторону - на 192.168.1.10:16881.

Автозапуск socat

Запускать socat можно из системного планировщика.

В Linux с systemd надежнее будет создать простенький юнит, например, такой:

[Unit]
Description=socat-forwarding
Documentation=http://www.dest-unreach.org/socat/doc/socat.html
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/socat TCP4-LISTEN:4322,fork TCP6:[202:421a:2eb5:40a4:fa32:f4a4:9b42:d4e4]:3202|/usr/bin/socat TCP6-Listen:4321,fork TCP4:192.168.1.10:16881 2>&1
Restart=always
RestartSec=1
TimeoutStopSec=0

[Install]
WantedBy=multi-user.target

Юнит можно поместить в /usr/lib/systemd/system/.

Ссылки

Страница socat в Интернет (EN): http://www.dest-unreach.org/socat/

YDN64

anonymous@undisclosed.example.com (Anonymous) — Tue, 28 Jul 2026 14:53:24 +0000

YDN64

Свежий взгляд на построение серверной части для DNS64/NAT64-туннеля
Не требует root, не создаёт tun-устройство и, следовательно, не требует настройки файрвола для Yggdrasil-трафика на серверной стороне
Имеются готовые сборки и Docker-контейнер

Ссылки

Репозиторий проекта: https://github.com/DrewCyber/ydn64