Через Meshtastic можно реализовать IP тунель.

Важно помнить, что в таком режиме работы MTU равен всего лишь 200 и большого профита от подобного тунеля вы не получите. Вариантов реального применения подобного тунелирования нет. Также важно не использовать основным каналом тот, что является общим (в Туле это LogFast). Также делательно сменить частотный слот на отличный от того, что используется сообществом во избежание возрастания нагрузки на сеть.

Но раз спортивный интерес имеется - расскажу как это можно реализовать.

Данный трюк можно проделать, оперевшись на документацию (а именно, на утилиту python cli meshtastic). Ознакомиться с оригиналом можно тут - https://meshtastic.org/docs/software/python/cli/#tunnel-arguments

После того, как частотный слот и основной канал изменены можно опробовать функцию IP-туннелирования:

$ sudo meshtastic --tunnel
Connected to radio
INFO file:tunnel.py __init__ line:83 Starting IP to mesh tunnel (you must be root for this *pre-alpha* feature to work).  Mesh members:
INFO file:tunnel.py __init__ line:95 Node !5687b499 has IP address None.180.153
INFO file:tunnel.py __init__ line:95 Node !148bfdc5 has IP address None.253.197
sh: line 1: ifconfig: command not found
Aborting due to: 

Первый запуск неудачный. На моем компьютере не был установлен ifconfig . ifconfig — это старый инструмент, который раньше использовался для настройки сети. Однако в настоящее время рекомендуется использовать другой инструмент ip.

После установки ifconfig я повторил всю процедуру заново:

$ sudo meshtastic --tunnel
Connected to radio
INFO file:tunnel.py __init__ line:83 Starting IP to mesh tunnel (you must be root for this *pre-alpha* feature to work).  Mesh members:
INFO file:tunnel.py __init__ line:95 Node !5687b499 has IP address None.180.153
INFO file:tunnel.py __init__ line:95 Node !148bfdc5 has IP address None.253.197
None.180.153: Unknown host
ifconfig: `--help' gives usage information.
Aborting due to: ifconfig command failed.

По всей видимости, команда ifconfig запрашивает IP-адрес None.180.153. Это происходит из-за ошибки в приложении (https://github.com/meshtastic/python/issues/468). Дело в том, что аргумент командной строки используется для указания подсети. Однако, если подсеть не указана, используется аргумент None. Возможный обходной путь:

$ sudo meshtastic --tunnel --subnet 10.115

После этого можно было запустить интерфейс:

$sudo meshtastic --tunnel --subnet 10.115
Connected to radio

Еще одним препятствием для IP-туннелирования с помощью Meshtastic является небольшой размер MTU в 200 байт. Это автоматически препятствует работе с IPv6, поскольку для IPv6 требуется MTU не менее 1280 байт. Однако туннелирование IPv6 возможно через IPv4 (GRE, WireGuard и др.).

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

• Если в качестве основного канала указать частный канал со случайным паролем, IP-пакеты будут зашифрованы, но другие узлы больше не будут получать информацию о других узлах, которая также распространяется широковещательно.
• Если вы туннелируете IP-пакеты по общедоступному стандартному каналу, вы по-прежнему обмениваетесь информацией об узле и получаете её, но IP-пакеты не шифруются. Один из способов обойти эту проблему и использовать IPv6 — это использовать туннель WireGuard (или аналогичный).

Ещё одна проблема IP-туннелирования через Meshtastic — высокая задержка и потеря пакетов:

Если в качестве основного канала указать частный канал со случайным паролем, IP-пакеты будут зашифрованы, но другие узлы больше не будут получать информацию о других узлах, которая также распространяется широковещательно. Если вы туннелируете IP-пакеты по общедоступному стандартному каналу, вы по-прежнему обмениваетесь информацией об узле и получаете её, но IP-пакеты не шифруются. Один из способов обойти эту проблему и использовать IPv6 — это использовать туннель WireGuard (или аналогичный). Ещё одна проблема IP-туннелирования через Meshtastic — высокая задержка и потеря пакетов:

$ time ping 10.115.253.197 -c 20 -W 600
PING 10.115.253.197 (10.115.253.197) 56(84) bytes of data.
64 bytes from 10.115.253.197: icmp_seq=1 ttl=64 time=12612 ms
64 bytes from 10.115.253.197: icmp_seq=2 ttl=64 time=15457 ms
64 bytes from 10.115.253.197: icmp_seq=4 ttl=64 time=14536 ms
64 bytes from 10.115.253.197: icmp_seq=5 ttl=64 time=14669 ms
64 bytes from 10.115.253.197: icmp_seq=6 ttl=64 time=14803 ms
64 bytes from 10.115.253.197: icmp_seq=8 ttl=64 time=17756 ms
64 bytes from 10.115.253.197: icmp_seq=9 ttl=64 time=19245 ms
64 bytes from 10.115.253.197: icmp_seq=10 ttl=64 time=19234 ms
64 bytes from 10.115.253.197: icmp_seq=11 ttl=64 time=19280 ms
64 bytes from 10.115.253.197: icmp_seq=12 ttl=64 time=19564 ms
64 bytes from 10.115.253.197: icmp_seq=14 ttl=64 time=21571 ms
64 bytes from 10.115.253.197: icmp_seq=16 ttl=64 time=21286 ms
64 bytes from 10.115.253.197: icmp_seq=17 ttl=64 time=21525 ms
64 bytes from 10.115.253.197: icmp_seq=20 ttl=64 time=29039 ms

--- 10.115.253.197 ping statistics ---
20 packets transmitted, 14 received, 30% packet loss, time 19209ms
rtt min/avg/max/mdev = 12611.611/18612.706/29038.582/4040.933 ms, pipe 16

real	0m50.196s
user	0m0.007s
sys	0m0.068s

Передача данных по протоколу UDP также осуществлялась без каких-либо проблем:

$ ncat --verbose --wait 10m --udp 10.115.180.153 8886
Ncat: Version 7.94 ( https://nmap.org/ncat )
Ncat: Connected to 10.115.180.153:8886.
Hello World!
^C

$ ncat --listen --verbose --udp --source-port 8886
Ncat: Version 7.94 ( https://nmap.org/ncat )
Ncat: Listening on [::]:8886
Ncat: Listening on 0.0.0.0:8886
Ncat: Connection from 10.115.253.197:47920.
Hello World!
^C

Однако установить простое TCP-соединение оказалось невозможно. Тем не менее, должны быть возможны простые чат-приложения, основанные на UDP и допускающие высокие задержки.

$ ncat --verbose --wait 10m 10.115.180.153 8886
Ncat: Version 7.94 ( https://nmap.org/ncat )
Ncat: Connection timed out.