Tinyproxy માં Listen, Bind અને BindSame: કયું સરનામું જીતે છે
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 ટુકડો બંનેમાંથી કંઈ સાબિત કરતો નથી.