How to Wiki Database (change log)
http://[222:a8e4:50cd:55c:788e:b0a5:4e2f:a92c]
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
136 lines
10 KiB
136 lines
10 KiB
9 months ago
|
====== Cryptokey Routing ======
|
||
|
|
|
||
|
|
^ :!: Обратите внимание ^
|
||
|
|
| В статье описывается механизм [[https://yggdrasil-network.github.io/2018/11/06/crypto-key-routing.html|Crypto-Key Routing]], предназначавшийся для создания «нативных» туннелей «поверх» [[yggdrasil:yggdrasil|Yggdrasil]], похожих на туннели [[:wireguard|Wireguard]]. Данный механизм [[https://yggdrasil-network.github.io/2021/06/19/preparing-for-v0-4.html|был удален]] из Yggdrasil версии 0.4. Т.о., данная статья частично потеряла актуальность. В конфигурационном файле Yggdrasil больше нет возможности настроить маршрутизацию. Вместо этого разработчики рекомендуют использовать [[yggdrasil:tunnels:gre-tunnel|GRE]], [[wpru>IP_in_IP|IPIP]], [[:wireguard|WireGuard]] и другие технологии, назначая IP-адреса Yggdrasil в качестве адресов конечных точек туннелей. \\ \\ Описанная ниже возможность туннелирования трафика осталась в альтернативной версии Yggdrasil от одного из разработчиков [[https://github.com/neilalexander|@neilalexander]]: https://github.com/neilalexander/yggdrasilckr \\ \\ Так же, CKR был восстановлен в [[wpru>Форк|форке]] Yggdrasil [[yggdrasil:alt_clients:riv-mesh|RiV-mesh]] и присутствует там по настоящее время. |
|
||
|
|
|
||
|
|
Как известно, [[yggdrasil:yggdrasil|Yggdrasil]] позволяет дополнительную маршрутизацию IPv4 и IPv6 сетей, помимо сети 0200::/7. Т.е. позволяет “пробросить” любые подсети через сеть Yggdrasil между двумя хостами. Тут описывается, как это сделать на Linux-машинах.
|
||
|
|
|
||
|
|
Скажем, у нас есть схема ниже и нужно через Ygg-туннель наладить связь между хостами А (интерфейс lo с адресом 172.20.18.97/28) и С (интерфес ens18 с адресом 10.0.0.5/24). Хосты B и C в одной локальной сети, а по Yggdrasil есть связь между хостами А и B.
|
||
|
|
|
||
|
|
{{:ygg_aux_routing.png?700}}
|
||
|
|
===== Настройка =====
|
||
|
|
**На узле A**
|
||
|
|
|
||
|
|
Часть конфигурации в Yggdrasil, которая отвечает за дополнительную маршрутизацию, находится в секции //TunnelRouting//. Рассмотрим конфиг на стороне узла A:
|
||
|
|
<code>
|
||
|
|
TunnelRouting:
|
||
|
|
{
|
||
|
|
Enable: true
|
||
|
|
IPv6RemoteSubnets: {}
|
||
|
|
IPv6LocalSubnets: []
|
||
|
|
IPv4RemoteSubnets:
|
||
|
|
{
|
||
|
|
10.0.0.5/32: ca68ae394a1c03bd65642c5da9f28195650e576dceeec5165a12d2d1a62f2c15
|
||
|
|
}
|
||
|
|
IPv4LocalSubnets:
|
||
|
|
[
|
||
|
|
172.20.18.97/32
|
||
|
|
]
|
||
|
|
}
|
||
|
|
</code>
|
||
|
|
__По пунктам:__
|
||
|
|
* Enable - для включения дополнительной маршрутизации нужно поставить в true.
|
||
|
|
* IPv6RemoteSubnets - удаленные IPv6-сети, которые нужно маршрутизировать через ygg. Заполняется в виде сеть/маска: EncryptionPublicKey. То, что тут не заполнено, не будет маршрутизироваться через ygg.
|
||
|
|
* IPv6LocalSubnets - локальные IPv6-сети, которые нужно принимать через ygg. Заполняется в виде сеть/маска. То, что тут не заполнено, будет отброшено.
|
||
|
|
* IPv4RemoteSubnets - удаленные IPv4-сети, которые нужно маршрутизировать через ygg. Заполняется в виде сеть/маска: EncryptionPublicKey. То, что тут не заполнено, не будет маршрутизироваться через ygg.
|
||
|
|
* IPv4LocalSubnets - локальные IPv4-сети, которые нужно принимать через ygg. Заполняется в виде сеть/маска. То, что тут не заполнено, будет отброшено.
|
||
|
|
__Более конкретно:__
|
||
|
|
<code>
|
||
|
|
IPv4RemoteSubnets:
|
||
|
|
{
|
||
|
|
10.0.0.5/32: ca68ae394a1c03bd65642c5da9f28195650e576dceeec5165a12d2d1a62f2c15
|
||
|
|
}
|
||
|
|
</code>
|
||
|
|
|
||
|
|
* 10.0.0.5/32 - сеть, которую необходимо маршрутизаровать через Yggdrasil в сторону определенного узла. В нашем случае это только один хост 10.0.0.5.
|
||
|
|
* ca68ae394a1c03bd65642c5da9f28195650e576dceeec5165a12d2d1a62f2c15 - EncryptionPublicKey удаленного узла, в сторону которого маршрузируется IPv4-сеть. В нашем случае это EncryptionPublicKey узла B, который можно посмореть в конфиге на узле B.
|
||
|
|
<code>
|
||
|
|
IPv4LocalSubnets:
|
||
|
|
[
|
||
|
|
172.20.18.97/32
|
||
|
|
]
|
||
|
|
</code>
|
||
|
|
172.20.18.97/32 - это адрес, который есть на интефейсe lo на узле A.
|
||
|
|
<code>
|
||
|
|
~# ip addr
|
||
|
|
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
|
||
|
|
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
||
|
|
inet 127.0.0.1/8 scope host lo
|
||
|
|
valid_lft forever preferred_lft forever
|
||
|
|
inet 172.20.18.97/28 brd 172.20.18.111 scope global lo:42
|
||
|
|
valid_lft forever preferred_lft forever
|
||
|
|
inet6 ::1/128 scope host
|
||
|
|
valid_lft forever preferred_lft forever
|
||
|
|
</code>
|
||
|
|
Вроде бы на стороне узла A все настроено, но только вот маршрутизатор системы ничего про какую-то там маршрутизацию в Yggdrasil сам не знает, поэтому для “пробрасываемых” сетей еще необходимо добавлять маршруты прямо в туннельный интерфейс Yggdrail. Один из вариантов, как это сделать:
|
||
|
|
<code>
|
||
|
|
ip route add 10.0.0.5/32 dev tun-ygg
|
||
|
|
</code>
|
||
|
|
Где,
|
||
|
|
|
||
|
|
* ip route add - команда для добавления маршрута;
|
||
|
|
* 10.0.0.5/32 - наш пробрасываемый хост;
|
||
|
|
* dev tun-ygg - указывает, что хост доступен через интерфейс tun-ygg. В вашем случае название интерфейса для Yggddrail может быть другой.
|
||
|
|
|
||
|
|
Не забываем перезапустить Yggdrasil, чтобы настройки пришли в силу.
|
||
|
|
|
||
|
|
**На узле B**
|
||
|
|
|
||
|
|
Теперь переходим к узлу B.\\
|
||
|
|
На этой стороне по сути своей конфигурация будет зеркальной и выглядеть так:
|
||
|
|
<code>
|
||
|
|
TunnelRouting:
|
||
|
|
{
|
||
|
|
Enable: true
|
||
|
|
IPv6RemoteSubnets: {}
|
||
|
|
IPv6LocalSubnets: []
|
||
|
|
IPv4RemoteSubnets:
|
||
|
|
{
|
||
|
|
172.20.18.97/32: 06aac0753717863b01e4ceac0467e72ba168d42dc1c06ff338acf866a3ee9b6b
|
||
|
|
}
|
||
|
|
[
|
||
|
|
10.0.0.5/32
|
||
|
|
]
|
||
|
|
}
|
||
|
|
</code>
|
||
|
|
Маршрут добавляется так же зеркально:
|
||
|
|
<code>
|
||
|
|
ip route add 172.20.18.97/32 dev tun-ygg
|
||
|
|
</code>
|
||
|
|
Единственно, что нужно на этом узле вспомнить, что он будет не передавать/принимать пакеты от себя, а маршрутировать между интейфейсами ens18 и tun-ygg, поэтому **должна быть включена IPv4 и/или IPv6 маршуратизация**. Обычно на Linux-машинах это включается в файле /etc/sysctl.conf.
|
||
|
|
<code>
|
||
|
|
# sysctl net.ipv4.ip_forward
|
||
|
|
net.ipv4.ip_forward = 1
|
||
|
|
|
||
|
|
# sysctl net.ipv6.conf.all.forwarding
|
||
|
|
net.ipv6.conf.all.forwarding = 1
|
||
|
|
</code>
|
||
|
|
Если на машине настроен iptables, то посмотрите нет ли ограничений в цепочке FORWARD. Не забываем перезапустить Yggdrasil, чтобы настройки пришли в силу.
|
||
|
|
|
||
|
|
**На узле С**
|
||
|
|
|
||
|
|
Тут все совсем просто. Нужно просто указать, что хост A находится за узлом B:
|
||
|
|
<code>
|
||
|
|
ip route add 172.20.18.97/32 via 10.0.0.10
|
||
|
|
</code>
|
||
|
|
|
||
|
|
===== Какие могут быть проблемы =====
|
||
|
|
Самое неприятное, что может быть - это добавление маршрутов при старте Yggdrasil. Есть несколько вариантов, но проще всего в юните systemd для Yggdrail сделать что-то вроде такого:
|
||
|
|
<code>
|
||
|
|
ExecStart=/usr/bin/yggdrasil -useconffile /etc/yggdrasil.conf && /sbin/ip route add 10.0.0.5/32 dev tun-ygg
|
||
|
|
</code>
|
||
|
|
Т.е. после старта самого Yggdrail, будет добавлен маршрут в туннельный интерфейс. Только вот тогда и Yggdrasil должен либо стартовать под рутом, либо юзер, под которым он стартует, должен иметь разрешение на добавление маршрутов.
|
||
|
|
|
||
|
|
Не забывайте проверять iptables, если он есть, после добавления новых маршрутов.
|
||
|
|
|
||
|
|
===== Как еще использовать? =====
|
||
|
|
Собственно, Yggdrasil можно использовать как полноценный VPN, достаточно пробросить маршрут 0.0.0.0/0 и на стороне узла-выхода в Интернет настроить NAT.
|
||
|
|
|
||
|
|
Отдельные IPv4-адреса и сети между узлами можно пробросить для приложений, которые не “понимают” IPv6. Например, это может быть замена Hamachi для онлайн-игр. Только не RealTime-игр, потому что задержки и джиттер через ygg могут быть ужасными.
|
||
|
|
|
||
|
|
====== Ссылки ======
|
||
|
|
|
||
|
|
Crypto-Key Routing (EN): https://yggdrasil-network.github.io/2018/11/06/crypto-key-routing.html
|
||
|
|
|
||
|
|
~~DISCUSSION~~
|