curl உங்கள் PAC கோப்பைப் படிக்க முடியாது: அதற்கு பதிலாக proxy அனுப்புங்கள்
PAC ஒரு JavaScript கொள்கை; curl ஒரு இறுதிப் புள்ளியை விரும்புகிறது. கொள்கை உங்கள் URL-க்கு எந்த proxy தேர்ந்தெடுக்கிறது எனக் கேட்டு அதை அனுப்புங்கள், NO_PROXY மற்றும் TLS-ஐக் கவனியுங்கள்.
கட்டமைப்புக் கோப்பில் PAC கோப்பின் முகவரியும் proxy-யின் இறுதிப் புள்ளியும் ஒன்றுக்கொன்று மாற்றக்கூடியதாகத் தோன்றும், ஆனால் இல்லை. ஒன்று ஒவ்வொரு URL-க்கும் மதிப்பிட வேண்டிய கொள்கை நிரல்; மற்றொன்று இணைப்புகளை ஏற்கும் ஹோஸ்ட் மற்றும் போர்ட். curl இரண்டாவதை மட்டுமே புரிந்துகொள்கிறது. PAC முகவரியை --proxy க்கு அனுப்புவது ஒரு வகைப் பிழை, அது குழப்பமான முறையில் தோல்வியடைகிறது, பொதுவாக இணைய சேவையகத்திற்கு நீண்ட CONNECT காலாவதிக்குப் பிறகு.
ஒவ்வொன்றும் உண்மையில் என்ன
| உங்களிடம் உள்ளது | அது என்ன | curl அதனுடன் என்ன செய்கிறது |
|---|---|---|
http://wpad.corp.example/proxy.pac | கொடுக்கப்பட்ட URL-க்கு proxy அல்லது நேரடி இணைப்பைத் திருப்பித் தரும் JavaScript | அதைக் கோப்பாகப் பதிவிறக்கி அங்கேயே நிற்கிறது |
http://proxy.corp.example:8080 | proxy வழியாக வரும் கோரிக்கைகளை ஏற்கும் கேட்பவர் | அதைப் பயன்படுத்துகிறது, HTTPS இலக்குகளுக்கு CONNECT உட்பட |
இதைத் தெளிவாகக் கூறுகிறது curl பற்றிய அடிக்கடி கேட்கப்படும் கேள்விகள்: curl JavaScript அல்லது PAC-இன் எந்த விளக்கத்தையும் வழங்குவதில்லை. curl-ஐச் சுற்றியுள்ள PAC புரிந்துகொள்ளும் உறை அதைச் செய்யலாம், ஆனால் curl தானே இல்லை, எந்தக் கொடியும் அதை உலாவியாக மாற்றாது.
உலாவி ஏன் வேலை செய்கிறது, curl ஏன் செய்யவில்லை
உலாவி கணினியின் proxy கட்டமைப்புடன் ஒருங்கிணைகிறது, PAC கோப்பைப் பெற்று நீங்கள் திறக்கும் URL-க்கு எதிராக அதன் விதிகளை இயக்குகிறது. அந்த மதிப்பீடுதான் PAC கோப்பு வழங்கும் சேவை, அது உங்கள் முனையத்திற்குள் அல்ல, உலாவிக்குள் நடக்கிறது.
curl மூலம் PAC கோப்பைப் பதிவிறக்கினால் அதன் உரை மட்டுமே கிடைக்கும். அது curl கொள்கையை இயக்கச் செய்யாது, proxy-ஐக் கண்டுபிடிக்க அதைக் கையால் படிப்பது அதே மதிப்பீட்டின் கையால் செய்த பதிப்பு, தவறான கிளையைத் தேர்ந்தெடுக்கும் அதே வாய்ப்புடன். நீங்கள் படித்தால், கோப்பில் உள்ள முதல் proxy பெயருக்குப் பதிலாக உங்கள் ஹோஸ்ட்டுடன் பொருந்தும் return கூற்றைப் படியுங்கள். பெரும்பாலான PAC கோப்புகளில் பல உள்ளன, உங்களுக்குப் பொருந்துவது ஒரு கிளை மட்டுமே.
அனுமதிக்கப்பட்ட HTTP proxy மற்றும் அனுமதிக்கப்பட்ட HTTPS சேவைக்கு, ஒரு எடுத்துக்காட்டு கோரிக்கை இதுவாகும்:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusமுதல் முகவரி proxy-யின் கேட்பவர், இரண்டாவது நீங்கள் விரும்பும் சேவை. இவை எடுத்துக்காட்டு இறுதிப் புள்ளிகள், யாரோ செய்த சோதனை அல்ல, எனவே அவற்றை உங்கள் நிறுவனத்தின் திட்டம், போர்ட் மற்றும் அங்கீகார ஓட்டத்தால் மாற்றுங்கள்.
இந்த இலக்கிற்கு proxy-ஐத் தேர்ந்தெடுங்கள்
நிறுவனம் எந்த proxy வைத்திருக்கிறது என்பதல்ல, கொள்கை உங்களுக்குத் தேவையான URL-க்கு எந்த proxy-ஐத் தேர்ந்தெடுக்கிறது என்பதை நிர்வாகியிடம் கேளுங்கள். PAC விதிகள் உள் சேவைகள், பொது தளங்கள் மற்றும் தோல்வி-மாற்ற நிலைகளுக்கு வேறு முடிவுகளைத் தந்து, இன்று உங்கள் URL-க்குப் பொருந்தும் விதி திருத்தத்திற்குப் பிறகு வேறொன்றுக்குப் பொருந்தலாம்.
பணிப்பாய்வுக்கு ஒன்றுக்கு மேற்பட்ட தெரிந்த கோரிக்கைகள் தேவைப்பட்டால், நிர்வாகி ஆதரிக்கும் நிலையான அமைப்பு அல்லது அனுமதிக்கப்பட்ட PAC-உணர்வுள்ள ஒருங்கிணைப்பைப் பயன்படுத்துங்கள். ஒரு நகலெடுக்கப்பட்ட முகவரியை ஹார்ட்கோட் செய்வது கொள்கை மாறி அந்த முகவரி ஏன் தேர்ந்தெடுக்கப்பட்டது என யாருக்கும் நினைவில்லாத நாள் வரை வேலை செய்யும்.
பிறகு curl என்ன மரபுரிமையாகப் பெறுகிறது எனப் பாருங்கள். proxy சூழல் மாறிகள் மற்றும் NO_PROXY நீங்கள் அனுப்பிய proxy-ஐ மீறலாம் அல்லது விலக்கலாம், உங்கள் இலக்குடன் பொருந்தும் விலக்கு கோரிக்கையை அமைதியாக நேரடியாக அனுப்புகிறது. ஒவ்வொரு விலக்கையும் அழிப்பதற்கோ அல்லது எல்லாவற்றையும் ஒரே முகவரி வழியாகத் திணிப்பதற்கோ பதிலாக நோக்கமிடப்பட்ட கொள்கையைப் பேணுங்கள். கோரிக்கையை ஒரு முறை -v உடன் இயக்கி அது உண்மையில் எந்த முகவரியுடன் இணைந்தது எனச் சரிபாருங்கள்.
இரண்டு TLS அடையாளங்களைத் தனித்து வையுங்கள்
HTTPS proxy-யுடன், இரண்டு TLS இணைப்புகள் செயலில் உள்ளன: உங்களுடையது proxy-க்கு மற்றும் proxy-யின் இலக்கிற்கு. ஒவ்வொன்றும் சரிபார்க்க வேண்டிய தனி அடையாளத்தைக் கொண்டுள்ளது, அவற்றில் எதற்கேனும் சரிபார்ப்பை முடக்குவது PAC திருத்தம் அல்ல, முதல் சிக்கலுடன் சேர்க்கப்படும் இரண்டாவது சிக்கல்.
சரிபார்ப்பை இயக்கத்திலேயே விட்டு நீங்கள் பெறும் தோல்வியைப் படியுங்கள். proxy அங்கீகார சவால், அணுக முடியாத proxy மற்றும் இணையதளத்தின் மறுப்பு ஆகியவை மூன்று வேறு முடிவுகள், முதல் ஒன்று மட்டுமே சான்றுகளைப் பற்றியது. VPN இன்னும் தனியார் proxy-க்கு அனுமதிக்கப்பட்ட பாதையை வழங்க வேண்டும், proxy ஹோஸ்ட்டுக்கான பெயர் பகுப்பாய்வு உட்பட, இவற்றில் எதுவும் வெற்றிபெறும் முன்.
இறுதிப் புள்ளி, திட்டம், போர்ட், அங்கீகார முறை, விலக்குகள் மற்றும் proxy வரையிலான VPN பாதையை எழுதி வையுங்கள். அந்தப் பதிவே அடுத்த கோரிக்கையை மீள்உருவாக்கக்கூடியதாக ஆக்குகிறது, உங்கள் proxy-ஐ அறிவதற்கும் அதைப் பற்றி ஊகிப்பதற்கும் இடையிலான வேறுபாடு அதுவே.