Yet another Rust VPN (TUN-QUIC-TUN)

В сфере искусственного интеллекта произошло заметное событие. veshutov 17 минут назад Yet another Rust VPN (TUN-QUIC-TUN) 10 мин 291 Rust * Сетевые технологии * Программирование * Изучение языков На поделке из предыдущей статьи вдохновение не закончилось, решил написать VPN. Был опыт разработки shadowsocks сервера, что не понравилось: под каждое TCP соединение, открываемое каким-нибудь браузеров, VPN клиент открывает отдельное TCP cоединение к серверу, а тот в свою очередь столько же до конечной точки + пришлось руками шифровать/дешифровать payload. Захотелось сделать что-то более простое + самим написать и клиент.

Дисклеймер: проект и статья исключительно в образовательных целях, разобраться в сетях и попрактиковаться на Rust, ничего не рекламирую, ни к чему не призываю. Поток данныхПосле небольшого ресерча остановился на следующей схеме:Трафик до сайта в интернетеДавайте разбираться, что здесь происходит. В моем случае клиент – Mac OS, сервер – Ubuntu, в основном это влияет лишь на то, какими инструментами будут настроены правила маршрутизации (route, nftables, etc).

Технические детали

Со стороны клиента, VPN:Поднимает TUN интерфейс utun1Добавляет маршршуты:route add -net 0. 0/1 -interface utun1 + route add -net 128. 0/1 -interface utun1 заворачивают весь исходящий трафик через созданный интерфейс (два маршрута, чтобы не трогать дефолтный 0.

0/0)route add -host 1. 1 {default_gw} позволяет трафик до VPN сервера напрямую, чтобы не зацикливаться на utun1 (вместо default_gw подставляется адрес шлюза по умолчанию)Перенаправляет весь получаемый на utun1 трафик на VPN сервер, инкапсулируя в QUIC датаграммы, а получаемый по QUIC трафик обратно в utun1Сервер:Поднимает TUN интерфейс utun1Чтобы utun1 мог ходить в интернет, будто он en0 (дефолтный интерфейс), добавляет следующий ruleset в nftables (вместо vpn_net подставляется соответствующая подсеть, подробнее про нее будет ниже):table ip vpn_nat flush table ip vpn_nat table ip vpn_nat {{ chain postrouting {{ type nat hook postrouting priority 100; ip oifname en0 masquerade }} }}Перенаправляет весь получаемый по QUIC трафик в utun1, а из него обратно по QUICНюансыТрафик между VPN клиентом и сервером отправляем через QUIC датаграммы, а значит гарантий доставки нет (зато есть TLS). Это не проблема для клиентского трафика, т.

ретраи будет обеспечивать инкапсулированный протокол (если поддерживает). Однако для контрольного трафика потери критичны, например, для аутентификации, здесь воспользуемся QUIC bidirectional stream. Сервер и клиент никак не меняют инкапсулированный трафик, т.

Отраслевые последствия

source IP у пользовательских пакетов будет от их TUN интерфейса. Так как мы заранее загружаем ruleset для nftables, необходимо, чтобы этот IP был из подсети vpn_net. Помимо этого, когда сервер получит обратный трафик, по destination IP пакета надо будет определить, кому из подключенных клиентов его направить.

Вывод: IP TUN интерфейсов должны быть уникальны, принадлежать одной подсети + сервер должен знать соответствие клиент - IP.

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