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 по-горе не доказва нищо за нито едно от двете.