Tun2socks решает неприятную задачу, с которой обычный прокси справляется плохо. Браузер, мессенджер, пакетный менеджер, игровой клиент или собственная программа могут по-разному относиться к прокси-настройкам системы. Одни приложения поддерживают SOCKS5, другие понимают только HTTP, третьи вообще игнорируют параметры окружения и идут напрямую. Tun2socks переносит задачу ниже, на уровень маршрутизации: операционная система отправляет пакеты в виртуальный TUN-интерфейс, а программа уже превращает TCP и UDP-потоки в соединения через выбранный прокси.
По смыслу tun2socks ближе не к «еще одному прокси-клиенту», а к прослойке между таблицей маршрутов и прокси-сервером. Такой подход полезен в лабораториях, корпоративных сетях, тестировании приложений, работе с изолированными стендами и отладке сетевого поведения. Но есть важное ограничение: tun2socks не делает чужой прокси безопасным, не шифрует трафик сам по себе и не отменяет законы, правила сервисов и сетевые политики. Материал предназначен для легального и ответственного использования. Не применяйте такие инструменты для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода блокировок, особенно с учетом законодательства своей страны, включая Россию.
Что делает tun2socks простыми словами
Обычный прокси работает на уровне приложения. Программа должна знать адрес прокси, тип протокола, логин, пароль и уметь отправлять запросы через нужную схему. Tun2socks работает иначе: система думает, что перед ней обычный сетевой интерфейс, а маршруты отправляют трафик в этот интерфейс. Дальше tun2socks забирает пакеты из TUN-устройства и передает соединения через HTTP, SOCKS4, SOCKS5, Shadowsocks, SSH или relay-прокси. В официальном репозитории проект описан как tun2socks на базе сетевого стека gVisor.
Главный выигрыш дает прозрачность. Приложению не нужно знать про прокси. Приложение просто открывает соединение, операционная система выбирает маршрут, а tun2socks берет трафик на себя. Поэтому через один механизм можно пустить браузер, консольные утилиты, системные обновления и программы без встроенной поддержки прокси.
Но прозрачность не означает «все само настроится». Нужно создать или выбрать TUN-интерфейс, правильно назначить адрес, добавить маршруты, не потерять маршрут до самого прокси-сервера, отдельно разобраться с DNS и проверить UDP. Большинство проблем с tun2socks возникает не из-за самой программы, а из-за неверной таблицы маршрутизации.
Как устроен путь трафика
Типовая схема выглядит так: приложение отправляет пакет, ядро операционной системы смотрит таблицу маршрутов, пакет уходит в TUN-интерфейс, tun2socks читает пакет в пользовательском пространстве, сетевой стек gVisor обрабатывает соединение, затем tun2socks открывает исходящее соединение к прокси и передает данные дальше.
Приложение → таблица маршрутов ОС → TUN-интерфейс → tun2socks → прокси-сервер → целевой ресурс
Важная деталь прячется в последнем шаге. Само соединение до прокси-сервера не должно снова попасть в TUN-интерфейс, иначе получится петля. Клиент пытается подключиться к прокси, маршрут отправляет соединение обратно в tun2socks, tun2socks снова пытается открыть прокси-соединение, и трафик зацикливается. Поэтому в реальных конфигурациях либо привязывают tun2socks к основному сетевому интерфейсу, либо добавляют отдельный маршрут до адреса прокси через обычный шлюз.
gVisor здесь нужен не ради контейнерной моды. Проект использует пользовательский сетевой стек, который помогает обрабатывать пакеты без написания собственного TCP/IP-стека с нуля. Такой подход удобен для кроссплатформенности и контроля над сетевым поведением, но добавляет слой, где могут проявляться ограничения производительности, памяти и совместимости с нестандартными сценариями.
Какие прокси поддерживаются и где начинаются ограничения
В документации tun2socks перечислены HTTP, SOCKS4, SOCKS5, Shadowsocks, SSH, relay, direct и reject-модели. Но поддержка в списке не означает одинаковые возможности. HTTP-прокси должен поддерживать метод CONNECT, иначе прозрачная передача произвольных TCP-соединений не получится. SOCKS4 проще, но ограничен по аутентификации и не подходит для многих современных задач. SOCKS5 практичнее, потому что может работать с именем пользователя и паролем, а также поддерживает UDP в рамках возможностей сервера. Shadowsocks и relay тоже могут передавать UDP, а HTTP и SOCKS4 в таблице проекта UDP не поддерживают.
| Модель | Для чего подходит | Что проверить заранее |
|---|---|---|
| HTTP CONNECT | TCP-трафик через корпоративный или внешний HTTP-прокси | Поддержку CONNECT и правила доступа на сервере |
| SOCKS5 | Универсальный вариант для TCP и части UDP-сценариев | Аутентификацию, UDP associate и DNS-поведение |
| Shadowsocks | Туннелирование трафика через совместимый сервер | Метод шифрования, пароль, поддержку UDP |
| SSH | Работу через SSH-доступ к серверу без отдельного SOCKS-сервиса | Ключи, пароль, порт и сетевые ограничения на SSH-сервере |
| Relay | Специальные схемы через совместимые прокси-узлы | Совместимость с актуальной версией GOST |
Отдельно стоит сказать про DNS. Tun2socks не является DNS-резолвером. Документация проекта прямо описывает задачу как прием TCP и UDP-пакетов через TUN-интерфейс и проксирование через сервер, а настройку DNS оставляет пользователю. На практике значит следующее: если DNS-запросы идут напрямую к провайдеру, часть приватности и предсказуемости маршрута теряется. Если приложение использует DNS-over-HTTPS, простая подмена UDP-запросов на 53-м порту не сработает. Если DNS настроен на интерфейсе неправильно, сайты будут «не открываться», хотя сам туннель может работать нормально.
Установка и быстрый запуск
Самый простой путь - скачать готовый архив под свою систему со страницы релизов. На момент проверки на GitHub последним релизом значился v2.6.0 от 7 июня 2025 года. В релизах есть сборки под Linux, macOS, Windows, FreeBSD и разные архитектуры. Альтернативный путь - собрать из исходников через Go. В wiki проекта указаны зависимости Go 1.22 или новее, git и make.
go install github.com/xjasonlyu/tun2socks/v2@latest
Или сборка из исходников:
git clone https://github.com/xjasonlyu/tun2socks.git
cd tun2socks
make tun2socks
sudo cp ./build/tun2socks /usr/local/bin
Базовый пример из wiki выглядит коротко:
tun2socks --device tun://tun0 --proxy socks5://1.2.3.4:1080
Но одной команды обычно мало. Перед запуском нужно подготовить интерфейс и маршруты. На Linux пример может выглядеть так, если основной интерфейс называется eth0, обычный шлюз находится на 172.17.0.1, а прокси доступен как socks5://host:port:
sudo ip tuntap add mode tun dev tun0
sudo ip addr add 198.18.0.1/15 dev tun0
sudo ip link set dev tun0 up
sudo ip route add default via 198.18.0.1 dev tun0 metric 1
sudo ip route add default via 172.17.0.1 dev eth0 metric 10
tun2socks -device tun0 -proxy socks5://host:port -interface eth0
Сеть 198.18.0.0/15 часто используют для тестовых и промежуточных сетевых схем, потому что диапазон зарезервирован для бенчмарков и не должен конфликтовать с обычными публичными адресами. В домашней или офисной сети все равно стоит проверить пересечения с локальными маршрутами.
Если Linux начинает отбрасывать пакеты, проверьте reverse path filtering. В wiki приведен пример отключения rp_filter для всех интерфейсов и основного интерфейса:
sudo sysctl net.ipv4.conf.all.rp_filter=0
sudo sysctl net.ipv4.conf.eth0.rp_filter=0
На Windows нужен Wintun. Документация советует поместить драйвер в папку с tun2socks или в системный PATH, после чего запуск может выглядеть так:
tun2socks -device wintun -proxy socks5://host:port -interface "WIFI"
netsh interface ipv4 set address name="wintun" source=static addr=192.168.123.1 mask=255.255.255.0
netsh interface ipv4 set dnsservers name="wintun" static address=8.8.8.8 register=none validate=no
netsh interface ipv4 add route 0.0.0.0/0 "wintun" 192.168.123.1 metric=1
На macOS порядок другой: сначала запускают tun2socks, чтобы система создала utun-интерфейс, затем поднимают интерфейс через ifconfig и добавляют маршруты. Детальные примеры для Linux, macOS и Windows собраны в официальной wiki.
Gateway mode: когда один компьютер становится прокси-шлюзом
Gateway mode звучит заманчиво: настраиваем tun2socks на одном устройстве, а остальные устройства в сети отправляют трафик через него как через шлюз. Например, есть мини-ПК или сервер в лабораторной сети, где поднят tun2socks, а тестовые устройства используют IP этого сервера как gateway. Такой режим удобен, когда на самих устройствах нельзя поставить клиент или менять прокси-настройки. Типичный пример - тестирование сетевого поведения умных устройств, мобильных приложений, приставок, старых систем или изолированных стендов.
Технически такой режим требует не только tun2socks, но и маршрутизации на хосте. На Linux обычно включают ip_forward, настраивают правила трансляции адресов, прописывают клиентам шлюз и внимательно следят, куда уходит DNS. Без этих шагов клиент отправит трафик на сервер, а сервер не станет полноценным маршрутизатором.
sudo sysctl net.ipv4.ip_forward=1
Команда выше только включает пересылку IPv4-пакетов до перезагрузки и не делает безопасную конфигурацию сама по себе. Для постоянной работы нужны системные настройки, правила межсетевого экрана, контроль доступа с локальной сети и мониторинг. Открытый gateway без фильтрации быстро превращается в источник проблем: соседи по сети смогут отправлять через него трафик, администратор потеряет понимание, какие устройства пользуются маршрутом, а журналы прокси станут беспорядочными.
IPv6 и туннелирование между версиями IP
Проект заявляет полную поддержку IPv6 и сценарии, где IPv4 может идти через IPv6 и наоборот. На бумаге звучит просто, но на практике IPv6 часто ломает ожидания. Операционная система может предпочесть AAAA-запись, приложение может открыть IPv6-соединение напрямую, DNS может вернуть адреса в неожиданном порядке, а межсетевой экран может фильтровать IPv6 иначе, чем IPv4.
Если цель - контролируемый маршрут всего трафика, проверять нужно обе версии протокола. Недостаточно выполнить curl к IPv4-адресу и решить, что схема работает. Проверьте IPv4, IPv6, DNS, UDP и маршрут до самого прокси. В противном случае часть соединений пойдет через tun2socks, а часть тихо обойдет виртуальный интерфейс.
Где tun2socks реально полезен
Первый практичный сценарий - тестирование приложений, которые не умеют прокси. Разработчик может направить весь трафик стенда через контролируемый узел и смотреть, как приложение ведет себя при задержках, фильтрации, смене маршрута или недоступности отдельных адресов.
Второй сценарий - единая проксификация системных утилит. Переменные окружения HTTP_PROXY и HTTPS_PROXY помогают не всегда. Пакетные менеджеры, контейнерные инструменты, собственные агенты обновления и старые программы могут вести себя по-разному. Маршрут через TUN-интерфейс делает поведение ближе к системному, а не к настройке каждого процесса.
Третий сценарий - лабораторный gateway для устройств, где нельзя поставить клиент. Такой подход удобен при анализе IoT-устройств и мобильных тестов, но требует отдельной этики и правовой чистоты: анализируйте только свои устройства, тестовые стенды или инфраструктуру, где у вас есть прямое разрешение.
Четвертый сценарий - сетевые эксперименты с IPv6, прокси-цепочками и нестандартными маршрутами. Здесь tun2socks интересен именно как инструмент инженера, а не как кнопка «сделать интернет другим». Чем сложнее маршрут, тем выше шанс ошибиться с DNS, MTU, UDP и обратным путем пакетов.
Типичные ошибки при настройке
- Петля маршрутизации: маршрут до прокси-сервера уходит в TUN-интерфейс, поэтому tun2socks не может подключиться к самому прокси.
- DNS идет напрямую: приложения резолвят домены через обычный интерфейс, хотя основной трафик уже идет через туннель.
- HTTP-прокси не поддерживает CONNECT: TCP-соединения не проходят, хотя адрес и порт прокси выглядят правильными.
- Ожидание полной UDP-поддержки от неподходящего прокси: HTTP и SOCKS4 не решат задачи, где нужен UDP.
- Неверный основной интерфейс: параметр -interface указывает не туда, и исходящие соединения до прокси выбирают неправильный путь.
- Забытый IPv6: IPv4 проверили, но IPv6-соединения продолжают ходить мимо TUN-интерфейса.
- Слишком общий gateway mode: сервер принимает трафик от лишних устройств, потому что администратор не ограничил доступ правилами firewall.
Как проверять, что трафик действительно идет через tun2socks
Начните с таблицы маршрутов. На Linux помогут ip route и ip -6 route, на macOS - route -n get и netstat -rn, на Windows - route print. Нужно увидеть, что маршрут по умолчанию или нужные сети действительно указывают на TUN-интерфейс, а маршрут до прокси-сервера остается через обычный шлюз.
Затем проверьте внешний адрес и DNS. Для TCP хватит curl или браузера, но лучше смотреть не только «какой IP видит сайт», а еще tcpdump или Wireshark на физическом интерфейсе. Если на физическом интерфейсе видны соединения к конечным сайтам, значит часть трафика идет в обход. В нормальной схеме физический интерфейс должен видеть в основном соединения к прокси-серверу и служебный трафик.
UDP проверяйте отдельно. Успешная загрузка страницы не доказывает, что UDP работает. Многие схемы отлично гонят TCP и при этом ломают QUIC, игровые протоколы, голосовые приложения или DNS. Иногда правильное решение состоит не в том, чтобы «починить весь UDP», а в том, чтобы осознанно отключить QUIC в браузере или выбрать прокси-модель, где UDP поддерживается сервером.
Производительность: где ждать узкое место
Tun2socks позиционируется как производительный инструмент, а в репозитории есть бенчмарки. Но скорость в реальной сети определяет не только tun2socks. Влияют задержка до прокси, пропускная способность сервера, шифрование, CPU на клиенте, параметры TCP-буферов, потери пакетов, MTU и тип прокси. Если сервер находится далеко или перегружен, оптимизация маршрутизации на клиенте не спасет.
Отдельная тема - пользовательское пространство. Пакеты проходят через TUN-интерфейс и обрабатываются процессом tun2socks, а не только ядром ОС. За гибкость приходится платить переключениями контекста и памятью. На обычном ноутбуке разница может быть незаметной, а на gateway для нескольких устройств или при большом числе соединений нагрузка станет видимой. Поэтому для постоянного использования стоит добавить системный сервис, лимиты, журналы, метрики и понятную процедуру отката маршрутов.
Безопасность и приватность без иллюзий
Tun2socks не превращает плохой прокси в хороший. Если прокси не шифрует транспорт или принадлежит неизвестному оператору, владелец прокси может видеть метаданные и часть содержимого незашифрованного трафика. HTTPS защищает содержимое соединения между клиентом и сайтом, но не скрывает сам факт подключения к прокси и не решает вопрос доверия к промежуточному узлу.
Еще одна зона риска - учетные данные. Прокси-URL часто содержит логин, пароль, путь к ключу или passphrase. Не вставляйте такие строки в публичные скрипты, историю shell, скриншоты и issue на GitHub. Для рабочих стендов лучше хранить секреты в переменных окружения, файлах с ограниченными правами или системных хранилищах секретов.
При работе в организации согласуйте схему с сетевыми администраторами и службой безопасности. Прозрачная маршрутизация может конфликтовать с корпоративным мониторингом, DLP, межсетевыми экранами, требованиями журналирования и политиками доступа. Даже легитимный технический эксперимент может выглядеть как попытка скрыть трафик, если команда не предупредила ответственных людей.
Можно ли использовать tun2socks как замену VPN?
Технически tun2socks может направить системный трафик через прокси и внешне напоминать часть VPN-поведения, но полноценной заменой VPN инструмент не становится. VPN обычно поднимает шифрованный туннель, управляет адресацией, маршрутизацией, DNS и политиками доступа как единая система. Tun2socks зависит от выбранного прокси и ручной сетевой настройки.
Почему сайты открываются, а часть приложений не работает?
Чаще всего мешают UDP, DNS, IPv6 или жестко заданные сетевые настройки внутри приложения. Браузер может успешно работать по TCP, а голос, игры, QUIC или собственный протокол приложения при этом ломаются. Проверьте поддержку UDP у прокси и посмотрите реальные соединения через tcpdump или Wireshark.
Нужно ли менять DNS отдельно?
Да, почти всегда DNS требует отдельной проверки. Tun2socks не задуман как DNS-резолвер. Система или приложение могут отправлять DNS-запросы напрямую, через UDP 53, через TCP или DNS-over-HTTPS. Для контролируемой схемы настройте DNS осознанно и проверьте, куда уходят запросы.
Почему после настройки пропал интернет?
Вероятные причины - удалили старый default route без запасного маршрута, не оставили прямой маршрут до прокси, указали неверный интерфейс или создали петлю. Перед экспериментами сохраните текущую таблицу маршрутов и держите под рукой команды отката.
Tun2socks хорош там, где нужен инженерный контроль над маршрутом всего трафика, а не настройка прокси в каждом приложении. Инструмент особенно полезен для тестовых стендов, лабораторий, систем без встроенной поддержки прокси и gateway-сценариев для своих устройств. Границы тоже ясны: DNS придется настраивать отдельно, UDP зависит от прокси-модели, IPv6 надо проверять явно, а безопасность определяется не названием инструмента, а всей цепочкой от клиента до прокси и дальше. Начинайте с минимальной схемы на одном хосте, фиксируйте маршруты, проверяйте утечки DNS и только потом переносите конфигурацию в gateway mode или постоянный сервис.
