Listen, Bind at BindSame sa Tinyproxy: aling address ang mananalo

Sumasagot ang proxy, natatapos ang request, at gayunman itinatala pa rin ng destinasyon ang address ng LAN. Walang mukhang mali sa log ng proxy, at ang linyang binago mo ay siya ring linya na sinabi ng dokumentasyon na baguhin. Sa host na may address ng LAN at address ng tunnel, tatlong direktiba ang nagpapasya kung aling address ang lalabas saan, at isa lang sa kanila ang tungkol sa palabas na panig. Kung babasahin mo sila sa maling pagkakasunod-sunod, mapupunta ka sa routing table nang walang dahilan.

Ang sintomas: nakikita ng destinasyon ang address ng LAN

Kumokonekta ang isang client sa proxy sa address ng LAN, at binubuksan ng proxy ang sarili nitong koneksyon patungo sa destinasyon. Ang pangalawang koneksyong iyon ay pumipili ng source address ayon sa mga tuntunin ng kernel, at bilang default ito ang pinipili ng paghahanap ng ruta. Kaya itinatala ng destinasyon ang pangunahing address ng host kahit dumaan ang bawat byte sa proxy. Wala namang sira sa pagpapasa, at iyon ang dahilan kung bakit wala ring masasabi ang log ng proxy tungkol dito.

Ang salamin ng sirang iyon ay mas madaling makita: i-pin ang palabas na pinagmulan sa address ng tunnel at hindi na maabot ng mga client ng LAN ang tagapakinig. Ang bersyong iyon ay nagpapahayag ng sarili, samantalang ang una ay nagtatago sa likod ng gumaganang request. Pareho silang nagmumula sa pagtrato sa isang direktiba na parang sinasagot ang dalawang tanong.

Tatlong direktiba, tatlong magkaibang address

Pinangalanan ng Listen ang lokal na address na tumatanggap ng mga client ng proxy. Nagbibigay ang Bind ng source address para sa mga koneksyong ginagawa ng proxy patungo sa labas, at iniuutos ng BindSame na gamitin muli ang lokal na address ng koneksyong katatanggap lang. Tatlong magkaibang tanong iyon, at isang linya lang ang sinasagot sa isa. Ang paghahalo sa kanila ang karaniwang dahilan kung bakit parang walang ginagawa ang isang pagbabago.

Basahin ang naka-comment na configuration na kasama ng naka-install na bersyon, dahil nagbabago ang mga default at tinatanggap na syntax sa pagitan ng mga release. Ang halimbawang configuration ng proyekto ay nagdodokumento sa bawat direktiba kasama ng iba. Ihambing ang file na iyon sa nasa disk, hindi sa gabay na isinulat para sa ibang distribusyon.

Itakda nang hiwalay ang tagapakinig at ang palabas na pinagmulan

Kumuha ng host na ang address ng LAN ay 192.168.50.10 at ang address ng tunnel ay 10.90.0.3. Kung kailangang maabot ng mga client ng LAN ang proxy habang lumalabas ang kanilang mga request sa tunnel, dalawang magkaibang desisyon iyon at kailangang isulat ang dalawa. Ang bahagi sa ibaba ay nagsasaad ng eksaktong iyon at wala nang iba.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Hindi ito kumpletong configuration, kaya panatilihin ang aprubadong port, authentication, mga kontrol sa access ng client at mga paghihigpit sa destinasyon. Kailangang pag-aari ng host na ito ang dalawang address sa loob ng network namespace ng Tinyproxy, dahil ang halaga ng Bind na hindi kayang angkinin ng proseso ay nabibigo sa pagkonekta, hindi sa pagsisimula. Inilalarawan ng BindSame yes ang ibang patakaran, kung saan ang lokal na address ng tinanggap na koneksyon ang nagiging palabas na pinagmulan. Sa kasalukuyang mga release, ang sangay na iyon ay may priyoridad sa listahan ng Bind, at ganoon nawawala ang naka-configure na pinagmulan nang walang error.

Suriin ang rutang ipinapahiwatig ng pinagmulan

Ang pagpili ng source address ay hindi lumilikha ng landas, kaya itanong sa kernel kung ano ang gagawin nito sa pinagmulang iyon at sa destinasyong iyon. Ang paghahanap na tumutukoy sa interface ng tunnel ang pinakamababang ebidensya, at ang tumutukoy sa interface ng LAN ay nangangahulugang hindi gagana ang pinagmulan ayon sa nakasulat. Ang paghahanap ay kontekstuwal: sinusuri nito ang mga tuntunin ng patakaran at ang talahanayang may bisa sa namespace na iyon. Hindi ito koneksyon, at wala itong sinasabi tungkol sa ihaharap ng NAT sa ibaba ng landas sa serbisyo.

ip -4 route get 203.0.113.25 from 10.90.0.3

Gumamit ng address para sa dokumentasyon sa halimbawa at palitan ito ng serbisyong may pahintulot kang subukan. Patakbuhin ang paghahanap sa loob ng namespace ng proxy kapag tumatakbo ang proxy sa container, dahil ang mga tuntunin ng host ay hindi ang mga tuntuning nakikita ng proseso. Kapag wala ang inaasahang ruta ng tunnel, hayaang ayusin ito ng may-ari ng network sa halip na magdagdag ng mga tuntuning partikular sa destinasyon sa host ng proxy. Huwag linisin ang mga ruta ng host at huwag i-disable ang mga rutang itinutulak ng server para magtagumpay ang isang paghahanap, kahit ginawa ito ng lumang gabay, dahil inililipat ng gayong mga pagbabago ang buong aprubadong pag-uugali ng VPN ng host para ayusin ang isang landas ng proxy.

Kumpirmahin ang pinagmulan sa destinasyon

Basahin ang pinagmulan sa lugar kung saan dumarating ang request, hindi kung saan ito umaalis. Itinatala ng log ng aplikasyon ng destinasyon, o ng edge device sa harap nito, ang address na aktuwal nitong nakita, samantalang ang proxy ay makapagsasabi lamang ng intensyon nito. Gumawa ng isang bagong request sa pamamagitan ng inaasahang tagapakinig pagkatapos ng pagbabago, dahil walang pinatutunayan ang naka-cache na koneksyon tungkol sa bagong pagkakatali. Pagkatapos, ihambing ang naitalang address sa address na itinakda mo.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

Ang curl ay tagalikha lang ng trapiko; ang address na dapat i-verify ay ang naitala ng malayong panig, hindi ang peer na hindi sinasadyang nakonekta ng curl. Kung hindi magtugma ang dalawa, tukuyin kung ang pagkakaiba ay nagmumula sa pagpili ng pinagmulan o sa pagsasalin sa dakong huli, dahil iba ang lugar kung saan inaayos ang mga iyon. Planuhin nang sabay ang mga pagbabago ng address at ang mga restart ng proxy, dahil ang pagtali sa isang address na wala nang hawak ang tunnel ay tahimik na nabibigo pagkatapos ng muling pagkonekta. Tukuyin din nang hiwalay ang pag-uugali ng DNS at IPv6, dahil wala ring pinatutunayan ang bahagi ng IPv4 sa itaas tungkol sa alinman sa dalawa.