ஹோஸ்டின் URL உடன் விருந்தினர் VM இல் PAC ப்ராக்ஸி ஏன் தோல்வியடைகிறது

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

PAC URL ஒரு ஸ்கிரிப்ட், ப்ராக்ஸி அல்ல

கோப்பில் URL மற்றும் ஹோஸ்ட்டைப் பெற்று ப்ராக்ஸி விவரத்தை அல்லது DIRECT என்ற சொல்லைத் திருப்பித் தரும் சார்பு உள்ளது. URL இல் பயன்பாட்டுக்கு டிராஃபிக்கை எங்கு அனுப்ப வேண்டும் என்று சொல்வது எதுவும் இல்லை; அந்த முடிவு இயக்க நேரத்தில், ஸ்கிரிப்ட்டுக்குள், ஸ்கிரிப்ட் தளத்திடம் கேட்கும் தரவுகளுடன் எடுக்கப்படுகிறது. PAC URL ஐ ஏற்கும் அமைப்பு உரையாடல் ஒரு முடிவு நடைமுறைக்கான சுட்டியை ஏற்கிறது.

அந்த வேறுபாடே URL ஐ நகலெடுப்பது வேலை செய்ததைப் போலத் தோன்றுவதற்கான காரணம். புலம் நிரப்பப்படுகிறது, அமைப்பு சேமிக்கப்படுகிறது, தோல்வி பின்னரே, ஸ்கிரிப்ட்டைப் பெற முடியாதபோது அல்லது விருந்தினர் அடைய முடியாத ப்ராக்ஸியைத் திருப்பித் தரும் போது மட்டுமே தோன்றுகிறது.

நான்கு படிகளும் வெவ்வேறு வழிகளில் தோல்வியடைகின்றன

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

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

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

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

அதே ஸ்கிரிப்ட் VM இல் வித்தியாசமாக முடிவு செய்கிறது

PAC சார்புகள் கோரப்பட்ட ஹோஸ்ட்டையும் மதிப்பீடு செய்யும் இயந்திரம் பற்றிய தகவலையும் பரிசோதிக்க முடியும். வாடிக்கையாளரின் சொந்த முகவரியின் மீது கட்டப்பட்ட விதி, எடுத்துக்காட்டாக இடைமுக முகவரி அல்லது துணை வலையமைப்பு உறுப்பினர் நிலையைச் சரிபார்ப்பது, இயற்பியல் ஹோஸ்ட்டின் முகவரியை அல்ல, விருந்தினரின் முகவரியைப் பார்க்கும். ஹோஸ்ட் பக்க NAT க்குப் பின்னால் இவை வெவ்வேறு முகவரிகள், எனவே அதே ஸ்கிரிப்ட் வேறு ப்ராக்ஸியைத் தேர்ந்தெடுக்கலாம் அல்லது VM இல் DIRECT க்குத் திரும்பலாம்.

இது ஸ்கிரிப்ட்டில் உள்ள குறைபாடு அல்ல. ஸ்கிரிப்ட் எதற்காக எழுதப்பட்டதோ அதை வேறு உள்ளீட்டுடன் செய்கிறது, அதுவே ஹோஸ்ட் ப்ராக்ஸியைப் பயன்படுத்தி விருந்தினர் நேரடியாக இணைக்கும் குழப்பமான அறிக்கையை விளக்குகிறது. முடிவைப் பற்றி யோசிப்பதற்குப் பதிலாக அதை மீண்டும் உருவாக்குங்கள்: முகவரியையும் URL ஐயும் எடுக்கும் PAC மதிப்பீட்டாளர், உங்கள் விநியோகத்தில் இருந்தால், ஒரே கட்டளையில் கேள்வியைத் தீர்க்கிறது. இல்லையெனில் உண்மையில் பயன்படுத்தப்படும் பயன்பாட்டுடன் சோதிக்கவும், ஊகிப்பதற்குப் பதிலாக அதன் ப்ராக்ஸி பதிவைப் படிக்கவும்.

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

PAC ஐ சிறிதும் படிக்காத கருவிகள்

கட்டளை வரி கருவிகள் தனி எல்லை, இங்குதான் நிறைய நேரம் வீணாகிறது. curl PAC கோப்புகளை இயக்காது, அதன் ப்ராக்ஸி ஆவணங்கள் தெளிவாகக் கூறுவது போல. ப்ராக்ஸி மாறியை PAC பதிவிறக்க URL க்குச் சுட்டுவது ஸ்கிரிப்ட்டை ப்ராக்ஸி இறுதிப் புள்ளியாக மாற்றாது; கருவி JavaScript கோப்புடன் HTTP பேச முயற்சிக்கும், வலையமைப்பு பிரச்சினை போலத் தோன்றும் விதத்தில் தோல்வியடையும்.

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

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

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT உம் ஒரு முடிவு

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

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

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