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Гэта не поўная канфігурацыя, таму захавайце зацверджаны порт, аўтэнтыфікацыю, кантроль доступу кліентаў і абмежаванні прызначэнняў. Абодва адрасы павінны належаць гэтаму хосту ў межах сеткавай прасторы імёнаў 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 -sScurl — гэта толькі генератар трафіку; адрас, які варта праверыць, — той, што запісаў далёкі бок, а не суразмоўца, да якога curl выпадкова падключыўся. Калі яны не супадаюць, вызначце, ці розніца ідзе ад выбару крыніцы, ці ад пераўтварэння далей на шляху, бо гэта выпраўляецца ў розных месцах. Плануйце змены адрасоў і перазапускі проксі разам, бо прывязванне адраса, якім тунэль ужо не валодае, ціха правальваецца пасля перападключэння. Вызначце паводзіны DNS і IPv6 асобна, бо прыведзены фрагмент IPv4 нічога не даказвае ні пра адно з іх.