Listen, Bind и BindSame у Tinyproxy-ју: која адреса побеђује
Listen бира адресу која прихвата клијенте, Bind бира извор одлазних веза. Ниједна не поставља руту, зато пут проверите одвојено.
Прокси одговара, захтев се завршава, а ипак одредиште и даље бележи адресу из локалне мреже. Ништа у дневнику проксија не изгледа погрешно, а линија коју сте изменили је тачно она коју вам је документација рекла да измените. На хосту који има и адресу локалне мреже и адресу тунела, три директиве одлучују која се адреса где појављује, а само једна од њих се односи на одлазну страну. Ако их читате у погрешном редоследу, без разлога завршите у табели рутирања.
Симптом: одредиште види адресу из локалне мреже
Клијент се повезује са проксијем на адреси локалне мреже, а прокси отвара сопствену везу према одредишту. Та друга веза бира изворну адресу по правилима језгра, а подразумевано је то она коју одабере претрага руте. Зато одредиште бележи примарну адресу хоста иако је сваки бајт прошао кроз прокси. У смислу прослеђивања ништа није покварено, и зато дневник проксија нема шта да каже о томе.
Огледална страна те грешке лакше се примећује: причврстите одлазни извор на адресу тунела и клијенти из локалне мреже потпуно престају да достижу слушаоца. Та верзија сама се објављује, док се прва крије иза захтева који ради. Обе настају из тога што се једна директива третира као да одговара на оба питања.
Три директиве, три различите адресе
Listen именује локалну адресу која прихвата клијенте проксија. Bind даје изворну адресу за везе које прокси отвара према споља, а BindSame му налаже да поново искористи локалну адресу везе коју је управо прихватио. То су три одвојена питања, а једна линија одговара само на једно од њих. Њихово мешање је уобичајен разлог због којег измена изгледа без учинка.
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The 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Ово није потпуна конфигурација, зато задржите одобрени порт, аутентикацију, контролу приступа клијената и ограничења одредишта. Обе адресе морају припадати овом хосту унутар мрежног простора имена проксија, јер вредност 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 -sScurl је само генератор саобраћаја; адреса која заслужује проверу је она коју је забележила далека страна, а не партнер са којим се curl случајно повезао. Ако се две не слажу, одредите да ли разлика долази од избора извора или од превођења даље на путу, јер се то поправља на различитим местима. Планирајте измене адреса и рестартовање проксија заједно, јер повезивање са адресом коју тунел више не држи тихо не успева после поновног повезивања. Одвојено дефинишите и понашање DNS-а и IPv6, јер фрагмент IPv4 изнад ништа не доказује ни о једном од њих.