Некоторое время назад я обнаружил, что мой доселе чистый и светлый интернет стал подвержен проблеме, которую лично я охарактеризовал как "подзатупы". Суть "подзатупов" заключается в сериях из пауз передачи пакетов длиной в 1-4 секунды (в отдельных случаях - до 10 секунд), время от времени происходящих на протяжении дня. Поскольку работать с SSH в таких условиях не очень-то комфортно, я решил переключиться на мобильный интернет от другого провайдера. Однако, оказалось, что теперь данная проблема и там имеет место быть:

$ ping 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=135 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=70.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=558 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=2581 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=115 time=1553 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=115 time=529 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=115 time=210 ms

Добавлял фрустрации тот факт, что после каждого переключения каналов мне приходилось заново переустанавливать все SSH и SFTP соединения. Хоть я и пользуюсь SSH-ключами там, где это возможно (и менеджером паролей там, где это малореально), тем не менее, мороки было немало. В принципе, на этом месте можно было бы начать затевать смену провайдера, либо прицениваться к местным "серым" продавцам Starlink. Однако, нет никакой гарантии, что у другого провайдера не будет этой же проблемы, а Starlink еще надо ухитриться затащить на крышу многоквартирного дома. Да и как раз на днях местный регулятор грозился что всех какбэ покарае, если только Маск вдруг не получит у него лицензию на оказание услуг связи.

Повыдирав волосы некоторое время, в мою голову пришла идея: а что, если дублировать IP-пакеты через оба сетевых интерфейса? Поскольку "подзатупы" разных провайдеров не коррелируют между собой, то даже если один из провайдеров в данный момент "тупит", то хотя бы одна из копий все равно наверняка должна добраться. А даже если в моменте все хорошо, мы хотя бы снижаем RTT до минимального по обоим провайдерам.

Очевидным тут является тот факт, что без внешнего сервера ничего не "выгорит": поскольку в TCP/IP используется так называемый 5-tuple для идентификации TCP-соединений, если мы будем менять source address в процессе, то ни один внешний хост нас не поймет. Поэтому я взял VDS в датацентре с пингом получше, и принялся за дело.

Смахиваем пыль с TUN/TAP

Я решил пойти путем, отработанным многочисленными VPN-клиентами. Мы создадим виртуальное сетевое устройство, который будет инкапсулировать приходящие IP-пакеты в UDP, и реплицировать их на VDS-ку через каждый из внешних сетевых интерфейсов. В свою очередь, серверная часть на VDS-ке будет отбрасывать "лишние" пакеты - но запоминать, с каких IP и портов они пришли, и форвардить пакеты туда. А в целях аутентификации (ну и дополнительной прослойки безопасности) мы будем шифровать исходящие пакеты по схеме AES256-GCM.

Как известно, TUN/TAP фактически разделен на 2 разных части - а именно, собственно, TUN и TAP. Обе из них реализуют концепцию виртуального сетевого устройства - однако, TUN оперирует IP-пакетами (таким образом, работая на 3-м уровне модели OSI), а TAP - Ethernet-фреймами (что соответствует 2-му уровню). Поскольку работать с Ethernet-фреймами было бы для нас избыточно, в дальнейшем речь будет идти именно о TUN, но не о TAP.

И так, добавляем крейт tun-rs, а так же pnet_packet для парсинга пакетов:

$ cargo new hello-tun && cd hello-tun/
$ cargo add tun-rs pnet_packet

В main.rs создаем виртуальное сетевое устройство и логируем поступающие из сетевого стека ОС пакеты. Для простоты сразу задаем IP-адрес, подсеть и MTU:

use tun_rs::DeviceBuilder;
use pnet_packet::ipv4::Ipv4Packet;

fn main() -> std::io::Result<()> {
    let dev = DeviceBuilder::new()
        .name("hellotun0")
        .mtu(1500)
        .ipv4("10.199.0.2", 24, None)
        .build_sync()?;

    println!("Created TUN interface: {}", dev.name()?);
    let mut buf = vec![0u8; 65535];

    loop {
        let n = dev.recv(&mut buf)?;
        println!("Packet bytes: {:?}", &buf[0..n]);
        let Some(packet) = Ipv4Packet::new(&buf[0..n]) else { continue };
        println!("Parsed packet: {:?}", packet);
    }
}

Далее запускаем и пробуем пропинговать любой IP-адрес в подсети 10.199.0.0/24 - кроме нашего локального адреса 10.199.0.2. Если все хорошо, то в stdout должны появиться наши логи. В качестве небольшого proof of concept можно добавить ответы на пинги:

    loop {
        let n = dev.recv(&mut buf)?;
        println!("Packet bytes: {:?}", &buf[0..n]);
        let Some(mut packet) = MutableIpv4Packet::new(&mut buf[0..n]) else { continue };
        println!("Parsed packet: {:?}", packet);

        let src = packet.get_source();
        let dst = packet.get_destination();
        packet.set_source(dst);
        packet.set_destination(src);
        dev.send(&buf[..n])?;
    }

Теперь мы можем пропинговать любой из адресов нашей виртуальной подсети - и нам будет возвращен корректный ответ.

Мучаем ChatGPT

На этом этапе я решил скормить собранные требования в качестве промпта ChatGPT. Помучав гптшку некоторое время, мне удалось получить компилирующийся и почти рабочий вариант. Вкратце разберем некоторые основные моменты выданного ChatGPT решения:

• Протокол максимально простой: каждый UDP-пакет состоит из 12-байтного nonce и следующего за ним зашифрованного IP-пакета. Какие бы то ни было служебные команды и/или машины состояний полностью отсутствуют

• Для отбрасывания "лишних" пакетов ChatGPT решил использовать DefaultHasher из стандартной библиотеки. Пусть остается так - хотя криптографически стойкие хэши в данном случае и не то, чтобы требуются, испытания показали, что наша производительность является более чем приемлимой. Поэтому я не стал дергаться и пытаться подключить более быстрые ahash или fxhash. В принципе, можно было быть еще эффективнее и вместо хэшей использовать sequence number из TCP-заголовка - но и ходить тогда будет только TCP.

• Серверная и клиентская части кода фактически представляют из себя полный копипаст друг друга (WET) - хотя отличаются, по сути, только стратегией отправки UDP-пакетов: клиент реплицирует пакеты на IP-адрес внешнего сервера через каждый из прописанных в конфиге сетевых интерфейсов, а внешний сервер - на все IP-адреса, с которых ему приходили успешно аутентифицированные пакеты. Мне так и не удалось заставить ChatGPT зарефакторить этот момент, не сломав при этом все. Поэтому "осушаем" вручную

• Для чтения из UDP-сокета использовалась весьма противная схема с переводом в неблокирующий режим с последующим опросом опросом раз в n миллисекунд - в клиентском копипасте кода, к тому же, оказавшаяся неработоспособной

Запускаем

Отполировав эти а так же еще некоторые моменты, я решил попробовать установить свое первое соединение. Прежде всего генерируем ключ для шифрования на сервере:

$ tuxburst gen-key
[2026-01-01 16:03:07][INFO] AES-256 key generated: 5543E0FF97FB85B2A5033043DF53FDA62C8B907AAF5FEB0F0C3C89F162C64F17
[2026-01-01 16:03:07][INFO] Wrote server.key

Заполняем client.toml и server.toml:

[common]
tun_name = "tuxburst0"
tun_addr = "10.99.0.2/30"
mtu = 1400
debug = false

[client]
host = "1.2.3.4:40000"
key = "5543E0FF97FB85B2A5033043DF53FDA62C8B907AAF5FEB0F0C3C89F162C64F17"
interfaces = ["wlo1", "enxf221672bb6de"]

[client.routes]
tun_gateway = "10.99.0.1"
metric = 5

[common]
tun_addr = "10.99.0.1/30"
tun_name = "tuxburst0"
debug = false
mtu = 1400

[server]
listen = "0.0.0.0:40000"

Настраиваем NAT на сервере и запускаем процессы на обоих концах:

$ sysctl -w net.ipv4.ip_forward=1
$ iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
$ iptables -A FORWARD -i tuxburst0 -o ens3 -j ACCEPT
$ iptables -A FORWARD -i ens3 -o tuxburst0 -m state --state RELATED,ESTABLISHED -j ACCEPT

server$ sudo tuxburst serve -c server.toml
client$ sudo tuxburst connect -c client.toml

При старте мы автоматически добавляем правило route, перенаправляющиее весь трафик на гейтвей в нашей виртуальной сети по дефолту. Поскольку наше правило имеет наименьший metric, оно превалирует над аналогичными правилами, полученными при получении настроек по DHCP для остальных каналов. И наоборот - поскольку роут ассоциирован с нашим виртуальным сетевым устройством, при завершении процесса он будет "бесплатно" подчищен операционной системой - и, таким образом, прежний роутинг будет восстановлен:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Ifa
default         _gateway        0.0.0.0         UG    5      0        0 tuxburst0
default         _gateway        0.0.0.0         UG    100    0        0 enx62c0701601f2
default         wifi-router     0.0.0.0         UG    600    0        0 wlo1
10.12.7.0       0.0.0.0         255.255.255.0   U     100    0        0 enx62c0701601f2
10.99.0.0       0.0.0.0         255.255.255.252 U     0      0        0 tuxburst0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.3.0     0.0.0.0         255.255.255.0   U     600    0        0 wlo1

Теперь самое время проверить соединение, запустив curl https://api.ipify.org. Как мы видим, возвращаемый IP действительно равен внешнему IP нашей внешней VDS-ки. Эксперименты с попарным отключением каждого из каналов показали устойчивость связи - а стало быть, схема работает.

Итоги

Опыт эксплуатации в течение недели показал, что мои волосы стали мягкими и шелковистыми проблема полностью решена. Я рад, что в итоге мне не потребовалось затевать смену провайдера, равно как и возиться с установкой Starlink на крышу многоквартирного дома. Отдельно бы хотелось отметить то, что TCP-соединения не прерываются даже если получилось так, что мне пришлось перезапустить процесс - поскольку мы не храним никаких состояний, которые могли бы негативно повлиять на существующие коннекты.

Если данный проект мог бы быть полезен еще кому-либо, или просто интересно глянуть код - вот ссылка на репозиторий: https://github.com/vdudouyt/tuxburst/