Listen, Bind і BindSame у Tinyproxy: яка адреса перемагає

Listen вибирає адресу, яка приймає клієнтів, Bind вибирає джерело вихідних з’єднань. Жодна не встановлює маршрут, тому шлях перевіряйте окремо.

Проксі відповідає, запит завершується, і все ж призначення досі записує адресу локальної мережі. У журналі проксі ніщо не виглядає неправильно, а змінений рядок — саме той, який документація радила змінити. На хості з адресою локальної мережі й адресою тунелю три директиви вирішують, яка адреса де з’явиться, і лише одна з них стосується вихідного боку. Якщо читати їх у неправильному порядку, ви без причини потрапите до таблиці маршрутизації.

Симптом: призначення бачить адресу локальної мережі

Клієнт підключається до проксі за адресою локальної мережі, і проксі відкриває власне з’єднання до призначення. Це друге з’єднання вибирає адресу джерела за правилами ядра, і за замовчуванням нею стає та, яку вибере пошук маршруту. Тому призначення записує основну адресу хоста, хоча кожен байт пройшов через проксі. З погляду пересилання ніщо не зламано, і саме тому журналу проксі нічого сказати.

Дзеркальний варіант цієї помилки помітити простіше: закріпіть вихідне джерело на адресі тунелю, і клієнти локальної мережі взагалі перестануть досягати слухача. Той варіант сам про себе повідомляє, а перший ховається за робочим запитом. Обидва постають із того, що одну директиву розглядають так, ніби вона відповідає на обидва питання.

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

Listen називає локальну адресу, яка приймає клієнтів проксі. Bind дає адресу джерела для з’єднань, які проксі відкриває назовні, а BindSame велить повторно використати локальну адресу щойно прийнятого з’єднання. Це три окремі питання, і один рядок відповідає лише на одне з них. Плутанина між ними — звичайна причина того, що зміна видається безрезультатною.

What you observeCheck first
A client cannot connect at allListen: the local address the listener binds
The request works but the far side logs the LAN addressBind: the outgoing source is not being applied
A configured Bind appears to have no effectBindSame yes: the accepted local address overrides the Bind list
The lookup names the LAN interfaceThe route, not the proxy: the source cannot reach that destination

Прочитайте прокоментовану конфігурацію, що постачається зі встановленою версією, бо значення за замовчуванням і прийнятний синтаксис змінюються між випусками. Приклад конфігурації проєкту документує кожну директиву поряд з іншими. Порівняйте цей файл із файлом на диску, а не з посібником, написаним для іншого дистрибутива.

Налаштуйте слухач і вихідне джерело окремо

Візьміть хост, у якого адреса локальної мережі 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 вище нічого не доводить ні про одне з них.

Схожі статті