Listen, Bind и BindSame во Tinyproxy: која адреса победува

Проксито одговара, барањето се завршува, а сепак одредиштето се уште ја запишува адресата од LAN. Ништо во дневникот на проксито не изгледа погрешно, а линијата што ја сменивте е токму таа што документацијата ви рече да ја смените. На домаќин со и LAN-адреса и адреса на тунел, три директиви одлучуваат која адреса каде ќе се појави, а само една од нив се однесува на излезната страна. Ако ги прочитате по погрешен редослед, без причина завршувате во табелата за рутирање.

Симптомот: одредиштето ја гледа адресата од LAN

Клиент се поврзува со проксито на LAN-адресата, а проксито ја отвора сопствената врска кон одредиштето. Таа втора врска избира изворна адреса според правилата на јадрото, а по стандард тоа е онаа што ја избира пребарувањето на рутата. Затоа одредиштето ја запишува примарната адреса на домаќинот, иако секој бајт помина низ проксито. Во смисла на проследување ништо не е скршено, и затоа дневникот на проксито нема што да каже за тоа.

Огледалната страна на таа грешка е полесно забележлива: прицврстете го излезниот извор на адресата на тунелот и LAN-клиентите воопшто престануваат да го достигнуваат слушачот. Таа верзија сама се објавува, додека првата се крие зад барање што работи. И двете произлегуваат од третирање на една директива како да одговара на двете прашања.

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

Listen ја наведува локалната адреса што ги прифаќа клиентите на проксито. Bind обезбедува изворна адреса за врските што проксито ги отвора кон надвор, а BindSame му наредува повторно да ја искористи локалната адреса на врската што штотуку ја прифатил. Тоа се три одделни прашања, а една линија одговара само на едно од нив. Нивното мешање е вообичаената причина зошто промената изгледа како ништо да не прави.

Прочитајте ја коментираната конфигурација што доаѓа со инсталираната верзија, бидејќи стандардните вредности и прифатената синтакса се менуваат меѓу изданијата. Примерната конфигурација на проектот ја документира секоја директива покрај другите. Споредете ја таа датотека со онаа на дискот, а не со водич напишан за друга дистрибуција.

Поставете го слушачот и излезниот извор одделно

Земете домаќин чија LAN-адреса е 192.168.50.10, а адресата на тунелот 10.90.0.3. Ако LAN-клиентите треба да го достигнат проксито, а нивните барања да излегуваат низ тунелот, тоа се две независни одлуки и двете мора да бидат запишани. Фрагментот подолу го изразува точно тоа и ништо друго.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Ова не е целосна конфигурација, затоа задржете го одобрениот порт, автентикацијата, контролата на пристапот на клиентите и ограничувањата на одредиштата. Двете адреси мора да му припаѓаат на овој домаќин во мрежниот именски простор на Tinyproxy, бидејќи вредноста Bind што процесот не може да ја поседува не успева при поврзување, а не при стартување. BindSame yes опишува друга политика, каде локалната адреса на прифатената врска станува излезен извор. Во тековните изданија таа гранка има предност пред списокот Bind, и така конфигурираниот извор исчезнува без грешка.

Проверете ја маршрутата што ја подразбира изворот

Изборот на изворна адреса не создава патека, затоа прашајте го јадрото што би направило со тој извор и тоа одредиште. Пребарувањето што го именува интерфејсот на тунелот е минимален доказ, а она што го именува интерфејсот на LAN значи дека изворот не може да работи како што е напишан. Пребарувањето е контекстуално: ги оценува правилата на политиката и табелата што важат за тој именски простор. Тоа не е врска и не кажува ништо за тоа што 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 погоре не докажува ништо за ниту едно од двете.