ப்ராக்ஸி பதிலளிக்கிறது, கோரிக்கை முடிகிறது, இருப்பினும் இலக்கு இன்னும் LAN முகவரியையே பதிவு செய்கிறது. ப்ராக்ஸி பதிவில் எதுவும் தவறாகத் தெரியவில்லை, நீங்கள் மாற்றிய வரி ஆவணம் மாற்றச் சொன்ன அதே வரி. LAN முகவரியும் சுரங்க முகவரியும் இரண்டும் உள்ள ஹோஸ்ட்டில், எந்த முகவரி எங்கே தோன்றும் என்பதை மூன்று வழிமுறைகள் தீர்மானிக்கின்றன, அவற்றில் ஒன்று மட்டுமே வெளியேறும் பக்கத்தைப் பற்றியது. தவறான வரிசையில் படித்தால் காரணமின்றி வழிமாற்றல் அட்டவணைக்குச் செல்வீர்கள்.

அறிகுறி: இலக்கு LAN முகவரியைப் பார்க்கிறது

ஒரு வாடிக்கையாளர் LAN முகவரியில் ப்ராக்ஸியுடன் இணைகிறார், ப்ராக்ஸி இலக்கை நோக்கி தனது சொந்த இணைப்பைத் திறக்கிறது. அந்த இரண்டாம் இணைப்பு கர்னல் விதிகளின்படி மூல முகவரியைத் தேர்ந்தெடுக்கிறது, இயல்பாக வழித் தேடல் தேர்ந்தெடுப்பதே அது. எனவே ஒவ்வொரு பைட்டும் ப்ராக்ஸி வழியே சென்றாலும் இலக்கு ஹோஸ்ட்டின் முதன்மை முகவரியையே பதிவு செய்கிறது. அனுப்புதலின் அடிப்படையில் எதுவும் உடைந்திருக்கவில்லை, அதனால்தான் ப்ராக்ஸி பதிவுக்கு இதைப் பற்றிச் சொல்ல ஒன்றுமில்லை.

அந்தக் குறையின் கண்ணாடிப் பிம்பத்தை அடையாளம் காண்பது எளிது: வெளியேறும் மூலத்தை சுரங்க முகவரியில் பூட்டுங்கள், LAN வாடிக்கையாளர்கள் கேட்பவரை அணுகவே மாட்டார்கள். அந்தப் பதிப்பு தன்னைத்தானே அறிவிக்கிறது, முதல் பதிப்பு வேலை செய்யும் கோரிக்கையின் பின்னால் மறைகிறது. இரண்டும் ஒரு வழிமுறையை இரண்டு கேள்விகளுக்கும் பதிலளிப்பதாகக் கருதுவதிலிருந்து வருகின்றன.

மூன்று வழிமுறைகள், மூன்று வேறு முகவரிகள்

Listen ப்ராக்ஸி வாடிக்கையாளர்களை ஏற்கும் உள்ளூர் முகவரியைக் குறிப்பிடுகிறது. Bind வெளிநோக்கி ப்ராக்ஸி உருவாக்கும் இணைப்புகளுக்கு மூல முகவரியை வழங்குகிறது, BindSame இப்போது ஏற்றுக்கொண்ட இணைப்பின் உள்ளூர் முகவரியை மீண்டும் பயன்படுத்தச் சொல்கிறது. இவை மூன்று தனித்தனி கேள்விகள், ஒரு வரி அவற்றில் ஒன்றுக்கு மட்டுமே பதிலளிக்கிறது. இவற்றைக் கலப்பதே மாற்றம் எதுவும் செய்யாதது போல் தோன்றுவதற்கான வழக்கமான காரணம்.

What you observeCheck first
A client cannot connect at allListen: the local address the listener binds
The request works but the far side logs the LAN addressBind: the outgoing source is not being applied
A configured Bind appears to have no effectBindSame yes: the accepted local address overrides the Bind list
The lookup names the LAN interfaceThe route, not the proxy: the source cannot reach that destination

நிறுவப்பட்ட பதிப்புடன் வரும் விளக்கக் கட்டமைப்பைப் படியுங்கள், ஏனெனில் இயல்பு மதிப்புகளும் ஏற்கப்படும் தொடரியலும் வெளியீடுகளுக்கு இடையே மாறுகின்றன. திட்டத்தின் மாதிரி கட்டமைப்பு ஒவ்வொரு வழிமுறையையும் மற்றவற்றுக்கு அருகில் ஆவணப்படுத்துகிறது. அந்தக் கோப்பை வட்டில் உள்ள கோப்புடன் ஒப்பிடுங்கள், வேறு விநியோகத்திற்காக எழுதப்பட்ட வழிகாட்டியுடன் அல்ல.

கேட்பவரையும் வெளியேறும் மூலத்தையும் தனித்தனியாக அமைக்கவும்

LAN முகவரி 192.168.50.10, சுரங்க முகவரி 10.90.0.3 உள்ள ஹோஸ்ட்டை எடுத்துக்கொள்ளுங்கள். LAN வாடிக்கையாளர்கள் ப்ராக்ஸியை அடைய வேண்டும், அவர்களின் கோரிக்கைகள் சுரங்கம் வழியே வெளியேற வேண்டும் என்றால், இவை இரண்டு சுயாதீன முடிவுகள், இரண்டையும் எழுத வேண்டும். கீழே உள்ள பகுதி சரியாக அதை மட்டுமே கூறுகிறது.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

இது முழுமையான கட்டமைப்பு அல்ல, எனவே அங்கீகரிக்கப்பட்ட துறைமுகம், அங்கீகாரம், வாடிக்கையாளர் அணுகல் கட்டுப்பாடுகள், இலக்கு வரம்புகளை வைத்திருங்கள். இரண்டு முகவரிகளும் Tinyproxy-இன் பிணையப் பெயர்வெளிக்குள் இந்த ஹோஸ்ட்டுக்கு உரியதாக இருக்க வேண்டும், ஏனெனில் செயல்முறை வைத்திருக்க முடியாத Bind மதிப்பு தொடங்கும்போது அல்ல, இணைக்கும்போது தோல்வியடைகிறது. BindSame yes வேறு கொள்கையை விவரிக்கிறது, அங்கு ஏற்றுக்கொள்ளப்பட்ட இணைப்பின் உள்ளூர் முகவரியே வெளியேறும் மூலமாகிறது. தற்போதைய வெளியீடுகளில் அந்தக் கிளை Bind பட்டியலை விட முன்னுரிமை பெறுகிறது, அப்படித்தான் கட்டமைக்கப்பட்ட மூலம் பிழையின்றி மறைகிறது.

மூலம் குறிக்கும் வழியைச் சரிபார்க்கவும்

மூல முகவரியைத் தேர்ந்தெடுப்பது வழியை உருவாக்காது, எனவே அந்த மூலத்துடனும் அந்த இலக்குடனும் கர்னல் என்ன செய்யும் என்று கேளுங்கள். சுரங்க இடைமுகத்தைக் குறிக்கும் தேடல் குறைந்தபட்ச சான்று, LAN இடைமுகத்தைக் குறிப்பது மூலம் எழுதியபடி செயல்பட முடியாது என்பதைக் குறிக்கிறது. தேடல் சூழல் சார்ந்தது: அந்தப் பெயர்வெளிக்கு செல்லுபடியாகும் கொள்கை விதிகளையும் அட்டவணையையும் மதிப்பிடுகிறது. இது இணைப்பு அல்ல, கீழ்நிலை 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 -sS

curl வெறும் போக்குவரத்து உருவாக்கி; சரிபார்க்கத் தகுந்த முகவரி தொலைப் பக்கம் பதிவு செய்ததே, curl தற்செயலாக இணைந்த துணையல்ல. இரண்டும் பொருந்தவில்லை என்றால், வேறுபாடு மூலத் தேர்விலிருந்து வருகிறதா அல்லது மேலும் மாற்றத்திலிருந்து வருகிறதா எனத் தீர்மானியுங்கள், ஏனெனில் அவை வெவ்வேறு இடங்களில் சரிசெய்யப்படுகின்றன. முகவரி மாற்றங்களையும் ப்ராக்ஸி மறுதொடக்கங்களையும் ஒன்றாகத் திட்டமிடுங்கள், ஏனெனில் சுரங்கம் இனி வைத்திராத முகவரியைப் பிணைப்பது மீண்டும் இணைந்த பிறகு அமைதியாகத் தோல்வியடைகிறது. DNS மற்றும் IPv6 நடத்தையையும் தனித்தனியாக வரையறுங்கள், ஏனெனில் மேலே உள்ள IPv4 பகுதி இரண்டில் எதைப் பற்றியும் எதையும் நிரூபிக்கவில்லை.

தொடர்புடைய கட்டுரைகள்