Listen, Bind и BindSame в Tinyproxy: какой адрес побеждает

Прокси отвечает, запрос завершается, и всё же назначение по-прежнему записывает адрес локальной сети. В журнале прокси ничего не выглядит неправильно, а изменённая строка — та самая, которую документация советовала изменить. На хосте с адресом локальной сети и адресом туннеля три директивы решают, какой адрес где появится, и только одна из них относится к исходящей стороне. Если читать их в неверном порядке, вы без причины попадёте в таблицу маршрутизации.

Симптом: назначение видит адрес локальной сети

Клиент подключается к прокси по адресу локальной сети, и прокси открывает собственное соединение к назначению. Это второе соединение выбирает адрес источника по правилам ядра, и по умолчанию им становится тот, который выберет поиск маршрута. Поэтому назначение записывает основной адрес хоста, хотя каждый байт прошёл через прокси. С точки зрения пересылки ничего не сломано, и именно поэтому журналу прокси нечего сказать.

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

Три директивы, три разных адреса

Listen называет локальный адрес, который принимает клиентов прокси. Bind задаёт адрес источника для соединений, которые прокси открывает наружу, а BindSame велит повторно использовать локальный адрес только что принятого соединения. Это три отдельных вопроса, и одна строка отвечает лишь на один из них. Путаница между ними — обычная причина того, что изменение выглядит бесполезным.

Прочитайте прокомментированную конфигурацию, поставляемую с установленной версией, потому что значения по умолчанию и допустимый синтаксис меняются между выпусками. Пример конфигурации проекта документирует каждую директиву рядом с остальными. Сравните этот файл с файлом на диске, а не с руководством, написанным для другого дистрибутива.

Настройте слушатель и исходящий источник по отдельности

Возьмите хост, у которого адрес локальной сети 192.168.50.10, а адрес туннеля 10.90.0.3. Если клиенты локальной сети должны достигать прокси, а их запросы выходить через туннель, это два независимых решения, и оба нужно записать. Фрагмент ниже выражает именно это и ничего больше.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

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

Проверьте маршрут, который подразумевает источник

Выбор адреса источника не создаёт путь, поэтому спросите ядро, что оно сделает с этим источником и этим назначением. Поиск, называющий интерфейс туннеля, — минимальное доказательство, а называющий интерфейс локальной сети означает, что источник не может работать так, как записан. Поиск контекстен: он оценивает правила политики и таблицу, действующие в этом пространстве имён. Это не соединение, и он ничего не говорит о том, что нижестоящий NAT покажет службе.

ip -4 route get 203.0.113.25 from 10.90.0.3

Используйте в примере документационный адрес и подставьте службу, которую вам разрешено проверять. Выполняйте поиск внутри пространства имён прокси, когда прокси работает в контейнере, потому что правила хоста — не те правила, которые видит процесс. Если нужного маршрута через туннель нет, пусть владелец сети его исправит, вместо того чтобы добавлять на хост прокси правила под конкретное назначение. Не очищайте маршруты хоста и не отключайте маршруты, присылаемые сервером, чтобы поиск прошёл, даже если старый справочник так делал, потому что такие изменения смещают всё утверждённое поведение VPN хоста ради исправления одного пути прокси.

Подтвердите источник на назначении

Читайте источник там, куда запрос приходит, а не откуда уходит. Журнал приложения на назначении или пограничное устройство перед ним записывает адрес, который оно действительно увидело, а прокси может сообщить только о своём намерении. Сделайте один новый запрос через нужный слушатель после изменения, потому что кэшированное соединение ничего не доказывает о новой привязке. Затем сравните записанный адрес с настроенным.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl — только генератор трафика; проверять стоит адрес, который записал удалённый край, а не партнёр, к которому curl случайно подключился. Если они расходятся, определите, происходит ли разница от выбора источника или от преобразования дальше, потому что это исправляется в разных местах. Планируйте изменения адресов и перезапуски прокси вместе, потому что привязка адреса, которым туннель больше не владеет, после переподключения тихо проваливается. Поведение DNS и IPv6 тоже определите отдельно, потому что фрагмент IPv4 выше ничего не доказывает ни о том, ни о другом.