Прозрачный прокси Linux получает трафик без явного выбора прокси в каждом приложении. REDIRECT меняет назначение пакета на локальный слушатель, TPROXY сочетает прозрачные сокеты с policy routing, а TUN передаёт направленные в него IP-пакеты программе. Выбор зависит от принадлежащего вам трафика, поддерживаемых протоколов и возможности безопасно восстановить сеть.［1］［2］［3］

Ключевые выводы

Захват, доставка по маршруту и обработка протокола — разные обязанности.

Слушателю TPROXY нужны маршрутизация и поддержка приложения, а не только порт.

TUN — IP-интерфейс, не гарантия шифрования или полного охвата.

Предпочтительны изолированное сетевое пространство имён и независимое управление.

Что должен учитывать прозрачный прокси Linux?

Начните с одного разрешённого Linux-хоста или шлюза, одного клиента и собственного назначения. Разделяйте трафик локальных процессов и пересылаемый трафик LAN. Prerouting шлюза и output приложения на хосте — разные точки входа; конфигурация одной не становится подходящей для другой автоматически.

Планирование самостоятельной инфраструктуры помогает определить владельца, окно обслуживания и канал восстановления. Если нужно лишь направить поддерживаемые приложения в прокси устройства, сравните охват системного прокси и TUN, прежде чем брать ответственность за firewall и policy routing. Отдельно оцените разницу между туннелем устройства и прокси приложения.

Это сравнение механизмов, а не универсальный установщик. Оно опирается на документацию ядра Linux о TPROXY и TUN и socket options Xray для пояснения границ реализации. Авторский сквозной эксперимент, измеренная производительность и проверенная матрица дистрибутивов не заявляются. Перед применением инструкций реализации проверьте ядро, firewall backend, версию прокси и доступные возможности.［1］［2］［3］

Как устроена маршрутизация прозрачного прокси Linux?

Рассматривайте соединение как передачу между тремя слоями. Захват выбирает пакеты для прокси. Маршрутизация доставляет их нужному слушателю или интерфейсу и обеспечивает согласованный возврат. Прокси должен поддерживать транспорт и устанавливать разрешённое исходящее соединение.

Обязанность	Вопрос администратора	Какие данные собрать
Захват	Какие источник, цель, протокол и hook совпадают?	Ограниченные счётчики правил и выбранный клиент
Локальная доставка	Почему пакет попадёт именно этому процессу?	Адрес слушателя, policy rule, маршрут, namespace
Обработка	Поддерживает ли реализация нужный транспорт?	Версионная конфигурация и диагностика потока
Возврат	Как ответ достигает исходного клиента?	Ответ клиента и предусмотренный маршрут
Исключения	Какие потоки управления и прокси обходят захват?	Неизменное управление и ограниченные счётчики

Рост счётчика подтверждает совпадение правила, но не успешную пересылку прокси. Открытый порт подтверждает сокет, но не доставку к нему. Рабочий TCP-запрос подтверждает собственный путь, но не UDP, DNS и поведение приложения, выбравшего другой маршрут.

Нарисуйте роли до выбора полей. DNS обозначьте отдельно: клиент может обращаться к резолверу маршрутизатора, собственному DNS приложения или сервису синтетических соответствий. Диагностика режимов DNS Mihomo объясняет, почему видимый клиенту адрес отличается от конечной исходящей цели.

Когда подходят REDIRECT и TPROXY?

REDIRECT применяет преобразование назначения для доставки потока локальному слушателю. Принимающая программа должна корректно восстановить или иначе получить исходную цель. Документация ядра описывает ограничения преобразования назначения: смена порта не означает, что любая программа сохранит правильное назначение.［1］

TPROXY доставляет пакеты прозрачному сокету без такого же переписывания назначения. При этом нужны policy routing для локальной доставки и поддержка прозрачных сокетов приложением. Примеры ядра показывают эти зависимости, но не составляют безопасный законченный firewall для каждого сервера. Чужая метка или номер таблицы могут конфликтовать с действующим владельцем.［1］

Критерий	REDIRECT	TPROXY	TUN
Объект захвата	Поток с преобразованным назначением	Выбранный пакет к прозрачному сокету	Пакет, направленный виртуальному IP-интерфейсу
Исходная цель	Реализация должна восстановить её	Сохраняется в адресации пакета	Доступна в IP-пакете userspace
TCP и UDP	Зависит от слушателя; Xray redirect описывает TCP	Xray tproxy описывает TCP и UDP	Зависит от стека и outbound программы
Владение маршрутами	Netfilter и локальный слушатель	Метки, policy rules, локальная доставка	Маршруты интерфейса и исключения
Права	Firewall и соответствующие сокеты	Firewall, policy routing, прозрачные сокеты	Создание интерфейса и доступ программы
Типовой сбой	Неверная цель или неподдержанный транспорт	Нет маршрута доставки или возник цикл	Слишком широкий маршрут либо неподдержанные пакеты

Поддержка TPROXY UDP зависит от реализации: справочник Xray описывает redirect для TCP IPv4/IPv6, а tproxy — для TCP и UDP IPv4/IPv6 в Linux; требуются root или CAP_NET_ADMIN. Это граница конкретно Xray, а не утверждение об одинаковой поддержке во всех программах с REDIRECT. Привязывайте вывод о реализации к соответствующему источнику.［2］

Что даёт TUN и чего он не решает?

TUN предоставляет интерфейс чтения и записи IP-пакетов пользовательской программой. Ядро отличает его от TAP, работающего с Ethernet-кадрами. Создание интерфейса и назначение маршрутов отличаются от реализации рабочего прокси-транспорта.［3］

Один userspace-стек переводит выбранные TCP/UDP-потоки в прокси-соединения, другой реализует иную туннельную схему. Имя интерфейса и переключатель tun не доказывают охват DNS, пересылку IPv6, шифрование или аварийную блокировку. Проверяйте свойства выбранной программы и наблюдаемый путь.

При направлении default route в интерфейс особенно важно владение маршрутами. Исходящий поток прокси должен достигать удалённого endpoint без повторного попадания в себя. Управление, локальные ресурсы и обратный путь должны оставаться преднамеренными. Захват управляющего канала способен лишить доступа раньше, чем начнётся диагностика.

Предпочтительны временная VM или отдельный network namespace с известными владельцами клиента, слушателей, интерфейсов и маршрутов. Namespace уменьшает пересечение, но firewall хоста, forwarding и физические интерфейсы остаются отдельной ответственностью. Изоляция не даёт разрешения менять общую сеть хоста.

Как безопасно оценить один разрешённый путь?

До правок опишите эксперимент: хост, namespace, один источник, своё назначение, протокол, ожидаемый маршрут, исключения, наблюдение и обратные изменения. Управляющее соединение оставьте вне выбранного источника или интерфейса. Если нет независимой консоли и надёжного отката, остановитесь на сравнении.

Инвентаризация Linux может начинаться с команд только чтения. Они не создают прокси; права и видимость вывода зависят от среды. Адреса, правила и сведения о процессах не следует публиковать без необходимости.

uname -r
ip -brief address
ip rule show
ip route show table all
ss -lntup

Для firewall выберите инспектор действующего backend, не смешивая legacy iptables с nftables. До резервирования объектов запишите существующие таблицы, метки, приоритеты и маршруты. Занятые порт или метка принадлежат существующей службе: не затирайте их и не завершайте процесс ради опыта.

Исключите исходящие сокеты самого прокси документированным способом реализации. Это может зависеть от процесса, метки, интерфейса или назначения и должно согласовываться с доставкой маршрутов. Быстрый рост счётчиков, повторяющиеся цели и расход ресурсов могут означать цикл. Остановите тест и выполните обратные изменения вместо увеличения лимитов.

Готовых firewall-команд здесь намеренно нет: сначала необходимо совместно зафиксировать топологию, backend, namespace, поддерживаемую конфигурацию и восстановление. Предпочтение механизма в таблице не оправдывает импровизированное глобальное правило.

Какие наблюдения подтверждают успех и отказ?

Используйте положительные и отрицательные проверки только в согласованной области. Для UDP выберите собственную службу; DNS-обмен подтверждает конкретный обмен, а не все UDP-приложения. Ограничьте журналы тестовыми метаданными и не захватывайте чужое содержимое.

Метод	Ожидаемый признак	Действие при ошибке
Одно выбранное TCP-соединение	Правило, слушатель, outbound и ответ согласованы	Проследить каждую передачу отдельно
Один разрешённый UDP-обмен	Транспорт поддержан, ответ приходит клиенту	Проверить реализацию и возврат
Запрос управления из исключения	Управление остаётся вне захвата	Снять тестовый захват до продолжения
Исходящий поток самого прокси	Нет рекурсивного входа в прокси	Остановить опыт и исправить исключение
Свежая проверка DNS и IPv6	Каждый путь соответствует собственной политике	Отметить непроверенное и ограничить внедрение
Остановка тестового прокси	Отказ или прямой fallback соответствует плану	Отклонить непреднамеренный прямой выход

Если опыт включает интернет-выход, проверьте публичный адрес конкретного запроса, отдельно тестируя DNS, IPv6, UDP и разрыв. При сравнении только локального захвата страница IP не заменяет маршруты. Проблемы системного резолвера вне захвата разбирайте через проверки владельца DNS в Ubuntu.

Как восстановление влияет на выбор?

Предпочтителен механизм, чьи объекты можно назвать и удалить без воздействия на другую службу. Запишите все тестовые правила, маршруты, policy rules, интерфейсы, процессы и временные настройки вместе с namespace и постоянным владельцем. Удаляйте и runtime, и источник автозапуска, иначе опыт вернётся после перезагрузки.

Снимайте только созданные тестом объекты в обратном порядке с учётом зависимостей. Не используйте nft flush ruleset, очистку всех policy rules или сброс default route как универсальную уборку. Если объект получил другого владельца, остановитесь и согласуйте состояние, а не удаляйте вслепую.

После отката сравните управление, обычные маршруты, DNS и исходную запись. Убедитесь, что тестовых слушателей и маршрутов не осталось, а нужный постоянный прокси восстановлен. Повседневный прокси- или VPN-клиент и сторонние клиенты оставьте неизменными. Открывшийся браузер полезен, но не заменяет сравнение инвентаризации.

Итоги

Выбирайте по протоколам, доставке и восстанавливаемому владению объектами.
Наблюдайте захват, маршруты, DNS и обработку отдельно.
Ограничьте опыт одним разрешённым путём и исключите управление.
Удаляйте именованные объекты и проверяйте восстановление до расширения охвата.

Часто задаваемые вопросы (FAQ)

Всегда ли TPROXY лучше REDIRECT?

TPROXY предлагает иную семантику назначения и доставки, но добавляет обязанности policy routing. Выбирайте его, когда реализация и транспорт оправдывают сложность и вы можете восстановить состояние.

Поддерживает ли REDIRECT UDP в любом прокси?

Поддержка зависит от принимающей программы и обработки исходного назначения. Документированный redirect Xray рассчитан на TCP; имя возможности Netfilter не доказывает возможности другой программы.

Шифрует ли TUN перехваченный трафик?

TUN доставляет IP-пакеты в userspace, а шифрование зависит от программы и outbound. Наличие интерфейса на хосте не подтверждает установку защищённого туннеля.

Почему счётчик растёт, но слушатель ничего не получает?

Совпадение правила подтверждает лишь захват. Отсутствующая policy routing, неверный адрес слушателя или другой namespace могут нарушить доставку даже при растущем счётчике.

Можно ли взять таблицу 100 из примера ядра?

Используйте таблицу только после проверки её владельца и требований реализации. Пример документации показывает зависимости, но не резервирует номер в вашей системе.

Доказывает ли веб-страница охват UDP и IPv6?

Веб-запрос подтверждает собственный путь и протокол. Отдельно проверьте разрешённый UDP, маршруты IPv6, DNS и отказ до заявления о более широком охвате.

Достаточно ли удалить network namespace для восстановления?

Удаление namespace не отменяет автоматически правила хоста и постоянные настройки. Перечислите изменённых владельцев и подтвердите исходное управление, маршруты и DNS после удаления.

Отказ от ответственности: Выводы основаны на перечисленных публичных материалах реализаций. Полный авторский опыт не заявляется; изменения требуют разрешения, фиксированной топологии и независимого канала восстановления.

Источники:

Linux kernel — Transparent proxy support — https://cdn.kernel.org/doc/html/latest/networking/tproxy.html
Project X — Sockopt — https://xtls.github.io/en/config/transports/sockopt.html
Linux kernel — Universal TUN/TAP device driver — https://docs.kernel.org/networking/tuntap.html

Sources checked 11 октября 2026 г.

Статьи по теме:

Прозрачный прокси Linux: REDIRECT, TPROXY или TUN?