Listen, Bind na BindSame katika Tinyproxy: anwani ipi inashinda

Proksi hujibu, ombi hukamilika, na bado lengo huendelea kurekodi anwani ya LAN. Hakuna kitu kwenye kumbukumbu ya proksi kinachoonekana kibaya, na mstari ulioubadilisha ndio ule ambao nyaraka zilikuambia ubadilishe. Kwenye mwenyeji mwenye anwani ya LAN na anwani ya handaki, maagizo matatu huamua anwani ipi inaonekana wapi, na moja tu kati yao linahusika na upande unaotoka. Ukiyasoma kwa mpangilio usiofaa, utaingia kwenye jedwali la uelekezaji bila sababu.

Dalili: lengo linaona anwani ya LAN

Mteja huunganisha na proksi kwenye anwani ya LAN, na proksi hufungua muunganisho wake mwenyewe kuelekea lengo. Muunganisho huo wa pili huchagua anwani ya chanzo kwa kanuni za kerneli, na kwa kawaida ni ile inayochaguliwa na utafutaji wa njia. Kwa hiyo lengo hurekodi anwani kuu ya mwenyeji ingawa kila baiti ilipitia proksi. Kwa upande wa upelekaji hakuna kilichovunjika, na ndiyo sababu kumbukumbu ya proksi haina la kusema.

Kioo cha hitilafu hiyo ni rahisi kuona: bamba chanzo kinachotoka kwenye anwani ya handaki na wateja wa LAN hawatafika kabisa kwa msikilizaji. Toleo hilo hujitangaza lenyewe, wakati la kwanza hujificha nyuma ya ombi linalofanya kazi. Yote mawili yanatoka katika kuchukulia agizo moja kana kwamba linajibu maswali yote mawili.

Maagizo matatu, anwani tatu tofauti

Listen hutaja anwani ya ndani inayopokea wateja wa proksi. Bind hutoa anwani ya chanzo kwa miunganisho ambayo proksi huifanya kuelekea nje, na BindSame huimuru kutumia tena anwani ya ndani ya muunganisho ambao umepokelewa hivi punde. Haya ni maswali matatu tofauti, na mstari mmoja hujibu moja tu. Kuyachanganya ndiyo sababu ya kawaida ya badiliko kuonekana kutofanya kitu.

Soma usanidi wenye maelezo unaokuja na toleo lililosakinishwa, kwa sababu thamani za msingi na sintaksia inayokubalika hubadilika kati ya matoleo. Usanidi wa mfano wa mradi huo hurekodi kila agizo kando ya mengine. Linganisha faili hilo na lile lililo kwenye diski, si na mwongozo ulioandikwa kwa usambazaji mwingine.

Weka msikilizaji na chanzo kinachotoka kwa njia tofauti

Chukua mwenyeji ambaye anwani yake ya LAN ni 192.168.50.10 na anwani ya handaki ni 10.90.0.3. Ikiwa wateja wa LAN wanapaswa kufikia proksi wakati maombi yao yanatoka kupitia handaki, haya ni maamuzi mawili huru na yote mawili yanapaswa kuandikwa. Kipande hapa chini kinaeleza hilo hasa na si kingine.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Huu si usanidi kamili, kwa hiyo hifadhi lango lililoidhinishwa, uthibitishaji, udhibiti wa ufikiaji wa wateja na vikwazo vya lengo. Anwani zote mbili lazima ziwe za mwenyeji huyu ndani ya nafasi ya majina ya mtandao ya Tinyproxy, kwa sababu thamani ya Bind ambayo mchakato hauwezi kuimiliki hushindwa wakati wa kuunganisha, si wakati wa kuanza. BindSame yes hufafanua sera nyingine, ambapo anwani ya ndani ya muunganisho uliopokelewa inakuwa chanzo kinachotoka. Katika matoleo ya sasa tawi hilo lina kipaumbele juu ya orodha ya Bind, na hivyo chanzo kilichosanidiwa hupotea bila hitilafu.

Angalia njia ambayo chanzo kinadokeza

Kuchagua anwani ya chanzo hakuundi njia, kwa hiyo uliza kerneli itafanya nini na chanzo hicho na lengo hilo. Utafutaji unaotaja kiolesura cha handaki ni ushahidi wa chini kabisa, na ule unaotaja kiolesura cha LAN unamaanisha chanzo hakiwezi kufanya kazi kama kilivyoandikwa. Utafutaji ni wa muktadha: hutathmini kanuni za sera na jedwali linalotumika kwa nafasi hiyo ya majina. Si muunganisho, na haisemi chochote kuhusu kile ambacho NAT ya chini itawasilisha kwa huduma.

ip -4 route get 203.0.113.25 from 10.90.0.3

Tumia anwani ya nyaraka katika mfano na badilisha huduma ambayo umeidhinishwa kuijaribu. Endesha utafutaji ndani ya nafasi ya majina ya proksi wakati proksi inaendeshwa kwenye kontena, kwa sababu kanuni za mwenyeji si zile ambazo mchakato unaziona. Ikiwa njia ya handaki iliyokusudiwa haipo, acha mmiliki wa mtandao airekebishe badala ya kuongeza kanuni maalum za lengo kwenye mwenyeji wa proksi. Usifute njia za mwenyeji na usizime njia zinazosukumwa na seva ili utafutaji ufanikiwe, hata kama mwongozo wa zamani ulifanya hivyo, kwa sababu mabadiliko kama hayo huhamisha tabia yote ya VPN iliyoidhinishwa ya mwenyeji ili kurekebisha njia moja ya proksi.

Thibitisha chanzo kwenye lengo

Soma chanzo mahali ombi linafika, si mahali linatoka. Kumbukumbu ya programu kwenye lengo, au kifaa cha ukingo kilicho mbele yake, hurekodi anwani iliyoiona kweli, wakati proksi inaweza kukuambia nia yake tu. Fanya ombi moja jipya kupitia msikilizaji uliokusudiwa baada ya badiliko, kwa sababu muunganisho uliohifadhiwa kwenye akiba hauthibitishi chochote kuhusu uunganishaji mpya. Kisha linganisha anwani iliyorekodiwa na ile uliyosanidi.

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

curl ni kizalishaji cha trafiki tu; anwani inayostahili kuthibitishwa ni ile iliyorekodiwa na upande wa mbali, si mwenzake ambao curl iliunganisha naye kwa bahati. Ikiwa hizo mbili hazipatani, amua kama tofauti inatoka kwa uchaguzi wa chanzo au kwa tafsiri zaidi mbele, kwa sababu hizo hurekebishwa sehemu tofauti. Panga mabadiliko ya anwani na kuanzisha upya proksi pamoja, kwa sababu kufunga anwani ambayo handaki haina tena hushindwa kimya baada ya kuunganishwa upya. Fafanua pia tabia ya DNS na IPv6 kwa njia tofauti, kwa sababu kipande cha IPv4 hapo juu hakithibitishi chochote kuhusu yoyote kati yao.