Что такое Tun2Socks Инструкция для Windows Инструкция для Linux В бытовом случае в сетевых настройках вашего компьютера указан шлюз по умолчанию. Чаще всего устройство, являющееся шлюзом, называют "роутер" или "маршрутизатор" — через него идут все запросы на IP-адреса, которые не входят в вашу локальную сеть. Прокси-сервер (от англ. "уполномоченный" или "доверенный") также выступает посредником между вами и целевым сетевым ресурсом, но не является шлюзом по умолчанию, то есть для его использования в приложении нужно явно указать соответствующие параметры. Самый простой пример — доступ в сети I2P или Tor. Всю внутреннюю логику этих сетей обеспечивает отдельное приложение, которое предоставляет пользователю прокси-интерфейс для подключения. Указав нужный прокси в настройках веб-браузера, мы можем посещать сайты с доменными именами ".i2p" и ".onion", о которых обычный маршрутизатор даже не догадывается. Также прокси-сервисы набирают популярность для обхода блокировок: прописал в настройках браузера какой-нибудь прокси из либеральной страны и открываешь любые сайты, не зная духоскрепного маразма. Современные прокси-серверы имеют исчерпывающий функционал для контроля и мониторинга трафика — хорошее решение для офисов и государственных учреждений, в которых нужно огородить работников от нежелательных ресурсов, а также предоставлять доступ в интернет с дополнительной авторизацией и различной пропускной способностью канала для разных пользователей. Какой бы сценарий использования прокси у вас ни был, использовать шлюз по умолчанию в большинстве случаев удобнее. Хотя бы потому, что некоторые приложения не умеют работать через прокси. Tun2Socks — свободный кроссплатформенный проект (GPL-3.0), написанный на Golang. Костяк команды разработчиков составляют китайцы. Приложение не имеет графической оболочки и конфигурируется незамысловатыми параметрами при запуске. Название Tun2Socks (Tunnel to SOCKS) трактуется как "туннель через SOCKS-прокси". Почему именно SOCKS, когда есть HTTP-прокси? Ответ прост: работать через HTTP-прокси Tun2Socks тоже умеет, но протокол HTTP не поддерживает передачу UDP-трафика. Через UDP идет большинство информации, доставка которой требует максимальной скорости (аудио- и видеозвонки, онлайн игры, а также DNS-запросы, разрешающие человекочитаемые имена сетевых ресурсов в IP-адреса). Поэтому поддержку UDP нельзя недооценивать. Суть работы Tun2Socks сводится к созданию виртуального сетевого адаптера, который операционная система будет воспринимать как обычный сетевой интерфейс. Вся информация, пришедшая на такой виртуальный адаптер, фактически будет передана внутрь Tun2Socks, который обеспечит необходимую логику дальнейшей передачи информации на прокси-сервер. Информация об использовании утилиты при запуске с параметром --help: Всё может показаться ясным с первого взгляда только бывалому админу, либо тому, кто ничего на самом деле не понял. При практическом знакомстве с Tun2Socks встает вопрос: если в системе создастся виртуальный сетевой адаптер, то как он станет шлюзом по умолчанию и нужно ли вручную задавать ему адрес. На помощь приходит документация. Дублировать здесь официальное описание проекта и всю документацию не имеет смысла, поэтому перейдем к сути — к практической конфигурации шлюза с пояснением каждого шага. Для начала необходимо скачать свежую версию Tun2Socks. Бинарники распространяются на странице релизов в официальном гит-репозитории проекта. Выберите один из пакетов, название которого начинается на tun2socks-windows. Если у вас 64-разрядная Windows на стареньком железе, вам наверняка подойдет tun2socks-windows-amd64.zip (так как архитектура ARM на старых машинах с Windows мне еще не встречалась).  После загрузки распакуйте архив в любое удобное место. Tun2Socks создает виртуальный сетевой адаптер, но драйвер для этого (Wintun) нужно скачать отдельно. Вот прямая ссылка для загрузки версии Wintun 0.11. Рекомендую именно эту версию, так как с более новыми версиями в моем случае Tun2Socks v2.3.1 работать отказался. При желании, свежий релиз драйвера можно найти на официальной странице. Из всего архива вам понадобится только один файл wintun.dll, который надо взять из нужной директории в зависимости от вашей операционной системы. В случае архитектуры amd64, путь до нужной библиотеки выглядит так: wintun/bin/amd64/wintun.dll. Положите подходящий файл wintun.dll в директорию, где находится исполняемый файл Tun2Socks. Tun2Socks запускается с передаваемыми значениями через командную строку (команды, приведенные ниже, должны быть выполнены с правами администратора). Команда для простого запуска имеет следующий вид:  tun2socks-windows-amd64.exe является именем исполняемого файла Tun2Socks; -device tun://gatewaytun определяет название нового виртуального сетевого интерфейса (gatewaytun); -proxy socks5://10.10.100.1:1080 сообщает протокол (в моем случае это SOCKS5) и адрес прокси-сервера. Этого достаточно, чтобы создать в системе новый сетевой интерфейс, но работать, как нам хочется, он пока что не будет. Для этого необходимо вручную присвоить новому сетевому интерфейсу IP-адрес и объяснить операционной системе, что он является шлюзом.  Присвоить интерфейсу IP-адрес и указать маску подсети можно через стандартный графический интерфейс Windows, но воспользуемся благами командной строки: В примере виртуальному интерфейсу присваивается адрес 127.254.254.1, но фактически это может быть любой частный адрес из подсети, которая, во-первых, не используется другими сетевыми адаптерами вашей операционной системы, во-вторых, не используется в локальной сети вашего предприятия или дома (иначе будет нарушена локальная маршрутизация). В большинстве случаев адрес из примера будет корректным значением (так как используется диапазон 127.0.0.1/8). В некоторых тестах Windows 10 отказывалась применять подобный адрес к интерфейсу. Если отказалась и у вас — воспользуйтесь чем-нибудь вроде 10.254.254.1.Итак, будем считать, что адрес виртуальному сетевому интерфейсу присвоен. Теперь нужно сообщить операционной системе новый интерфейс в качестве шлюза: Внимание! Если прокси-сервер находится не в локальной сети с той же подсетью, что и один из сетевых интерфейсов вашего компьютера, т.е. обращение к прокси-серверу осуществляется через уже существующий шлюз, необходимо оставить доступ к прокси-серверу в прежнем виде, иначе приведенная конфигурация работать не будет — согласитесь, что попытка подключения к прокси-серверу через сам же прокси-сервер является абсурдом. На практике это означает, что для подключения к прокси-серверу нужно добавить еще один маршрут: В примере указано правило маршрутизации в подсеть 10.10.100.0/24, которая должна идти не через общий шлюз (gatewaytun), а через сетевой интерфейс, имеющий доступ к устройству с адресом 10.10.5.25 (которое является шлюзом в нужную подсеть). Это правило справедливо, во-первых, если нужно сохранить доступ в подсеть локальной сети, которая недоступна непосредственно и, во-вторых, что более важно — если в заданной подсети находится сам прокси-сервер, через который в дальнейшем пойдет весь наш трафик.  При домашнем использовании, когда нет никаких локальных подсетей, и всё, что требуется, это подключение к прокси-серверу через интернет-провайдера, приведенная выше команда заменяется этой: 11.11.11.11 — адрес прокси-сервера в интернете; 255.255.255.255 — маска, означающая, что в правило входит только адрес прокси-сервера; 10.10.5.25 — адрес шлюза в локальной сети, который вам предоставляет интернет-провайдер. Если вы используете не HTTP-, а SOCKS-прокси (который поддерживает UDP), в настройках виртуального сетевого интерфейса можно указать адрес DNS-сервера, через который мы хотим резолвить доменные имена. Это возможно сделать как через графический интерфейс Windows, так и через командную строку: В примере адрес 1.1.1.1 является адресом DNS-сервера. В итоге получается следующий набор команд: Большинству пользователей ручное выполнение всех команд может показать неудобным. Такие люди могут поэкспериментировать с автоматизированными сценариями (батниками). Например, вписать все нужные команды в какой-нибудь start.bat и добавить его в автозагрузку. В батниках и правах доступа Windows я не силён. В напутствие лишь замечу, что все команды должны быть исполнены с правами администратора. Возможно, кто-то поделится красивым скриптом в комментариях. Пользователи GNU/Linux (и других *nix-систем) в своем большинстве являются более компетентными в вопросах командной строки и системных настроек, поэтому местами пояснения будут более скудные (тем более, что суть происходящего уже подробно описана чуть выше). Практическая инструкция дана на примере Debian. Бинарники для Linux есть среди прочих на странице релизов. Например, для Debian amd64 подойдет вариант tun2socks-linux-amd64.zip. Внутри архива находится один файл. После извлечения присвойте ему флаг исполняемости (chmod +x tun2socks-linux-amd64) и положите в удобное место, например, /usr/sbin/.  Дополнительные драйвера для создания туннеля WireGuard в Linux не требуются — современные дистрибутивы поддерживают технологию на уровне ядра. Все приведенные ниже команды нужно выполнять с правами суперпользователя. Команда запуска выглядит следующим образом: -device tun://gatewaytun определяет название нового виртуального сетевого интерфейса (gatewaytun); -proxy socks5://10.10.100.1:1080 сообщает протокол (в моем случае это SOCKS5) и адрес прокси-сервера. После запуска Tun2Socks в системе создается новый сетевой интерфейс с заданным именем. Теперь необходимо откорректировать правила маршрутизации: Настройки DNS в *nix-системах, как правило, являются глобальными, поэтому нет нужды указывать их явно для каждого интерфейса. Однако, кому нужно, тот знает не только про /etc/resolv.conf, но и про возможность явного указания DNS-сервера в конфиге сетевых подключений. На этом останавливаться не будем.  Автоматизация — второе имя любого админа. Для Debian я напишу сервис systemd, который будет запускать Tun2Socks и поднимать интерфейс gatewaytun, а в конфигурации данного сетевого интерфейса укажу команды, которые нужно выполнять при его включении. При необходимости вы можете адаптировать данный подход под другие операционные системы с учетом их специфики. Файл сервиса, который ляжет в /etc/systemd/system/tun2socks.service: Обратите внимание на путь до Tun2Socks и адрес прокси-сервера в строке ExecStart. Измените эти параметры под себя. После амперсанда указана пауза в три секунды, следом за которой осуществляется включение нового сетевого интерфейса. Пауза задается на случай высокой загрузки системы, чтобы дать время на создание интерфейса перед попыткой его включения. Указываем в /etc/network/interfaces параметры интерфейса и дополнительные инструкции для исполнения после его включения. Строки добавляются в конец файла: Теперь, когда всё готово, запускать и отключать шлюз можно двумя простыми командами: Если Tun2Socks нужен на постоянной основе, созданную службу можно добавить в автозагрузку: Мотивом для статьи послужило отсутствие адекватной поисковой выдачи по запросам вроде "шлюз через прокси", "как пустить весь трафик через прокси" и тому подобные. Полагаю, материал будет полезен самой широкой аудитории. С автоматизацией на Windows долго, честно говоря, не разбирался. Из коробки не завелось и — пусть отдыхает. Не люблю я винду, простите. Да и как любить ее, если для исполнения команды из bat-файла с правами администратора нужно создать ярлык этого батника и поставить в нем галочку "Запускать с правами администратора". Ярлык и галочка, Карл! Да и более того, команда добавления маршрута все равно не хотела отрабатывать. Спасибо за внимание. Энтузиаст отказоустойчивых и скрытых сетей