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

PAC முகவரியும் ப்ராக்ஸியும் எங்கு வேறுபடுகின்றன

https://config.corp.example/proxy.pac போன்ற ஒரு முகவரி பதிவிறக்க வேண்டிய ஆவணத்தைக் குறிக்கிறது, அந்த ஆவணம் போக்குவரத்தை அனுப்ப வேண்டிய சேவையகத்தைக் குறிக்கிறது. URL-ஐ ப்ராக்ஸி ஹோஸ்ட் புலத்தில் ஒட்டுவது, அத்தகைய இணைப்பை ஒருபோதும் கேட்காத கோப்பு சேவையகத்திற்கு ப்ராக்ஸி இணைப்பைத் திறக்கச் சொல்கிறது. கோப்பின் உள்ளே கிளையண்ட் ஒவ்வொரு கோரிக்கைக்கும் அழைக்கும் ஒரு செயல்பாடு உள்ளது, அதன் திரும்பும் மதிப்பே அந்த ஒரு இலக்கிற்கான அடுத்த ஹாப். இந்த மறைமுகத்தன்மையே ஒரே வலைய சேவையில் உள்ள இரண்டு இயந்திரங்கள், இரண்டும் சரியான URL வைத்திருந்தும், வேறுபட்டு நடந்துகொள்ளக் காரணம். ப்ராக்ஸியை யாரும் தொடாமலேயே கொள்கை மாற்றம் நடைமுறைக்கு வருவதையும் இது விளக்குகிறது.

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

எதையும் தீர்மானிக்கும் முன் ஸ்கிரிப்டைப் பெற வேண்டும்

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

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

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

முதல் கட்டளை செயலில் உள்ள சேவைக்கான ப்ராக்ஸி அகராதியை அச்சிடுகிறது, கணினி வைத்திருக்கும் தானியங்கி உள்ளமைவு URL உட்பட. இரண்டாவது ஒரு பெயரிடப்பட்ட சேவையுடன் இணைக்கப்பட்ட URL-ஐ தெரிவிக்கிறது, இது Wi-Fi மற்றும் Ethernet இடையே நகரும் மடிக்கணினியில் முக்கியம். மூன்றாவது கோப்பை வழங்காமலேயே கொண்டு வருகிறது, எனவே 404, நேரம் முடிவு, தீர்வி தோல்வி ஆகியவை வேறுபடுத்தக்கூடியதாகவே இருக்கும். அந்தக் கடைசி கட்டளை ஸ்கிரிப்டைத் திருப்பித் தந்தாலும் பயன்பாடுகள் இன்னும் தோல்வியடைந்தால், சிக்கல் ஏற்கனவே கொண்டு வருவதைத் தாண்டிவிட்டது.

DIRECT பதில் உண்மையில் எதைத் தவிர்க்கிறது

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

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

ஒரே பிழைப் பக்கமாகத் தோன்றும் மூன்று தோல்விகள்

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

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

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

டிக்கெட்டுடன் என்ன ஒப்படைக்க வேண்டும்

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

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

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