VPN தளத்தின் 403 ப்ராக்ஸி தோல்வி ஏன் இல்லை
மூலத்திலிருந்து 403, நிராகரிக்கப்பட்ட CONNECT மற்றும் 407 சவால் வெவ்வேறு எல்லைகளைக் குறிக்கின்றன. முதலில் ப்ராக்ஸியின் வெளியேற்றப் பாதையை உலாவியின் VPN முகவரியுடன் ஒப்பிடுங்கள்.
பயனர்கள் VPN-ஐ துண்டிக்கிறார்கள், உள் தளத்தில் 403-ஐ சந்திக்கிறார்கள், ப்ராக்ஸி பழுதடைந்துள்ளதாகத் தெரிவிக்கிறார்கள். அந்தப் பக்கத்தை மூன்று தனித்தனி விஷயங்கள் உருவாக்கலாம்: மூலம் கோரிக்கையை நிராகரித்தது, முன்னோக்கு ப்ராக்ஸி சுரங்கப்பாதையைத் திறக்க மறுத்தது, அல்லது ப்ராக்ஸி தனது சொந்தச் சான்றுகளைக் கேட்டது. இவை ஒவ்வொன்றும் வேறு கேள்விக்கான சரியான பதில், அவற்றை ஒரே பொதுவான தோல்விப் பக்கமாகத் தட்டையாக்குவது உங்களிடமுள்ள ஒரே சான்றை அழிக்கிறது. நிராகரிப்பை உருவாக்கிய கூறுகளின்படி பிரித்து, பின்னர் ஒவ்வொரு கூறும் உண்மையில் பயன்படுத்தும் பிணையப் பாதையை ஒப்பிடுங்கள்.
403-ஐ உருவாக்கிய கூறைப் பெயரிடுங்கள்
HTTP நிலைக் குறியீடு அதை அனுப்பிய தரப்புக்கு உரியது. மூலம் 403-ஐத் திருப்பித் தரும்போது, அது கோரிக்கையைப் பகுப்பாய்வு செய்து, அழைப்பவரிடம் ஆதாரம் இல்லாமல் இருக்கலாம் என முடிவு செய்துள்ளது, இது அனுமதிப் பதில், போக்குவரத்துப் பிரச்சினை அல்ல. முன்னோக்கு ப்ராக்ஸி CONNECT-க்கு 403 பதிலளிக்கும்போது, சுரங்கப்பாதையை முழுவதுமாகக் கட்ட மறுத்துவிட்டது, மேலே யாருடனும் தொடர்பு கொள்ளப்படவில்லை. அது 407 பதிலளிக்கும்போது, அதன் சொந்தச் சான்றுகளை விரும்புகிறது, அவற்றுக்கும் பயன்பாட்டின் உள்நுழைவுக்கும் எந்தத் தொடர்பும் இல்லை.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 இந்தப் பாத்திரங்களை வரையறுக்கிறது, ப்ராக்ஸி-குறிப்பிட்ட சவாலும் உட்பட. உடலைப் படிக்கும் முன் பதிலின் சொந்த நிலையையும் எந்த Proxy-Authenticate தலைப்பையும் படியுங்கள், ஏனெனில் நட்பான HTML பிழைப் பக்கம் எந்தக் கூறு அதை எழுதியது என்பதைப் பொதுவாக மறைக்கிறது.
CONNECT சுரங்கப்பாதை பைட் ரிலேயிடமிருந்து மறைப்பது என்ன
ப்ராக்ஸி CONNECT-க்கு 200 திருப்பித் தந்த பிறகு, அது பைட்டுகளை ரிலே செய்கிறது, உலாவி மூலத்துடன் அதன் சொந்த TLS அமர்வை வைத்திருக்கிறது. எனவே பைட்டுகளை ரிலே செய்யும் ப்ராக்ஸி அந்த அமர்வுக்குள் உள்ள மறையாக்கப்பட்ட 403-ஐப் படிக்க முடியாது, அது ஒருபோதும் நிராகரிப்பின் ஆசிரியராகாது. சுரங்கப்பாதை திறப்பதற்கு முன் நிராகரிப்பு முற்றிலும் வேறு நிகழ்வு, ஒரு அடுக்கு கீழே உருவாக்கப்படுகிறது.
TLS-ஐ முடிக்கும் தலைகீழ் ப்ராக்ஸி வேறு நிலையில் உள்ளது: அது TLS எல்லையைச் சொந்தமாகக் கொண்டுள்ளது, HTTP-ஐப் பகுப்பாய்வு செய்கிறது, பதில்களைச் சட்டப்படி மீண்டும் எழுதலாம் அல்லது இடைமறிக்கலாம். அந்தத் திறன் கட்டமைப்புத் தேர்வு, பொதுவாக ப்ராக்ஸியின் பண்பு அல்ல, அது பயன்பாட்டின் அணுகல் கொள்கையைத் தவிர்க்க அதிகாரம் தராது. பதிலைப் படிப்பது ஒரு திறன்; அழைப்பவர் எதைப் பார்க்கலாம் என்பதை முடிவு செய்வது மூலத்தின் வேலையாகவே இருக்கிறது.
நடைமுறை விளைவு என்னவென்றால், 403-ஐ விளக்கும் முன் நீங்கள் மூன்று வடிவங்களில் எதை இயக்குகிறீர்கள் என்பதை அறிந்திருக்க வேண்டும். ஸ்ட்ரீம் ப்ராக்ஸிக்கு HTTP ஆய்வு விதிகளைச் சேர்ப்பது அதற்குப் பார்வைத்திறனைத் தராது, பைட் ரிலே மூலத்தின் நிராகரிப்பை விளக்கும் என எதிர்பார்ப்பது உங்களைத் தவறான பதிவுக்கு அனுப்பும்.
ப்ராக்ஸியின் வெளியேற்றப் பாதையை உலாவியின் சுரங்கப்பாதை முகவரியுடன் ஒப்பிடுங்கள்
VPN-உடன் இணைக்கப்பட்ட உலாவி தனி ப்ராக்ஸி சேவையகத்தை தானாக அந்தச் சுரங்கப்பாதைக்கு நகர்த்தாது. மூலம் ப்ராக்ஸியின் வெளியேற்ற முகவரியை என்பதைப் பார்க்கிறது, ப்ராக்ஸி இன்னும் உள்ளூர் இயல்புநிலைப் பாதை வழியாக வெளியேறினால், பாதுகாக்கப்பட்ட தளம் நம்புவதற்கு ஒருபோதும் கட்டமைக்கப்படாத முகவரியைப் பார்க்கிறது. மடிக்கணினியின் உள் VPN முகவரி அந்த மூலத்திற்குத் தெரியாது. வேலை செய்யும் சுரங்கப்பாதையும் மற்ற அனைவருக்கும் சரியாக நடந்துகொள்ளும் தளத்திலிருந்து 403 தருவதற்கு இதுவே மிகவும் பொதுவான காரணம்.
முகவரிகள் குழப்பமடையாதபடி இரண்டு பாதைகளையும் தனித்தனியாகச் சோதியுங்கள்.
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateமுதல் கோரிக்கை மூலம் உங்கள் சொந்த முகவரிக்கு என்ன பதிலளிக்கிறது என்பதைக் காட்டுகிறது, இரண்டாவது ப்ராக்ஸியின் முகவரிக்கு என்ன பதிலளிக்கிறது என்பதைக் காட்டுகிறது. பொருந்தும் 403 இணை மூலத்தின் அனுமதி விதிகளைச் சுட்டுகிறது; 200-ஐத் தொடர்ந்து 403 வந்தால் ப்ராக்ஸி பாதையைச் சுட்டுகிறது. VPN குளம் சேர்க்கப்பட்டுள்ளது எனக் கருதுவதற்குப் பதிலாக விதித் தொகுப்பு உண்மையில் எந்த மூல முகவரிகளை ஏற்கிறது என மூலத்தின் உரிமையாளரிடம் கேளுங்கள்.
எல்லையைத் தனிமைப்படுத்தும் கோரிக்கையுடன் ஒவ்வொரு எல்லையையும் சோதியுங்கள்
பயன்பாட்டுக் காரணங்களால் ப்ராக்ஸி நிராகரிக்க முடியாத ஒன்றைக் கேட்டு ப்ராக்ஸி அடுக்கைத் தனிமைப்படுத்துங்கள். ப்ராக்ஸி அடைய அனுமதிக்கப்பட்ட புரவலனுக்கு CONNECT, வெளியீட்டைத் தூக்கி எறிந்து, சுரங்கப்பாதை நுழைவு எதற்கும் வேலை செய்கிறதா என்று சொல்லும்.
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
அது CONNECT-க்கு 200-ஐயும் பின்னர் TLS கைக்குலுக்கலை அச்சிட்டால், ப்ராக்ஸி நுழைவு நன்றாக உள்ளது, பின்னர் வந்த 403 மூலத்திலிருந்து வந்தது. அது 407-ஐ அச்சிட்டால், --proxy-user உடன் ப்ராக்ஸி சான்றுகளை வழங்கி, தளத்தைப் பற்றி எந்த முடிவுக்கும் வரும் முன் மீண்டும் செய்யுங்கள். அது CONNECT வரியில் 403-ஐ அச்சிட்டால், ஆய்வு செய்ய வேண்டிய எல்லை ப்ராக்ஸியின் சொந்த அனுமதிப் பட்டியலே, பயன்பாடு இதில் ஈடுபடவில்லை.
சான்றுகளை ஷெல் வரலாற்றிலிருந்தும் ஒட்டப்பட்ட நகல்களிலிருந்தும் விலக்கி வையுங்கள். கட்டளை வரியில் தட்டச்சு செய்யப்பட்ட ப்ராக்ஸி கடவுச்சொல் மற்ற உள்ளூர் பயனர்களுக்குத் தெரியும், சான்றுகளுடன் பிடிக்கப்பட்ட CONNECT தடயம் எந்தத் தடயமும் இல்லாததை விட மோசம்.
பக்கத்தை மீண்டும் எழுதுவதற்குப் பதிலாகத் தீர்ப்பைப் படிக்கக்கூடியதாக வையுங்கள்
எந்தக் கூறு நிராகரித்தது எனத் தெரிந்த பிறகு அந்தப் பதிலைப் பாதுகாக்கவும். மூலத்தின் 403-ஐ 504 காலாவதியாக மறுபெயரிடும், அல்லது அதை வெற்றிப் பக்கத்தால் மாற்றும் தலைகீழ் ப்ராக்ஸி அனுமதி முடிவைக் கிடைக்கும் கதைக்குப் பின்னால் மறைத்து அடுத்த பதிலளிப்பவரைத் தவறான குழுவுக்கு அனுப்புகிறது. தனிப்பயன் பிழைப் பக்கங்கள் நிலையை வைத்து சூழலைச் சேர்க்கும்போது நல்லவை.
தற்காலிகச் சேமிப்பும் அதே கவனிப்புக்கு உரியது. RFC 9111 பகிரப்பட்ட தற்காலிகச் சேமிப்புகள் பதில்களை எவ்வாறு மீண்டும் பயன்படுத்தலாம் என்பதை ஒழுங்குபடுத்துகிறது, ஒரு அழைப்பவருக்கு உருவாக்கப்பட்ட நிராகரிப்பை மற்றவருக்கு அனுமதி போல வழங்கக்கூடாது. நிராகரிப்புப் பதில்கள் எப்படியாவது சேமிக்கப்பட்டால், அவற்றைத் தனிப்பட்டதாகவும் வரம்புக்குட்பட்டதாகவும் வையுங்கள், மேல்நோக்கிய போக்குவரத்தைக் குறைக்க மட்டுமே பொது புத்துணர்ச்சி விதியை ஒருபோதும் சேர்க்காதீர்கள்.
கூறு, அது உருவாக்கிய நிலை மற்றும் மூலம் கண்ட மூல முகவரியைப் பெயரிடும் எழுத்துப்பூர்வத் தீர்ப்புடன் முடியுங்கள். சரியான கோரிக்கை, நடைமுறையில் உள்ள ப்ராக்ஸி அமைப்புகள் மற்றும் நேரத்தைப் பதிவு செய்யுங்கள், அடுத்த அறிக்கையை நினைவகத்திலிருந்து மீண்டும் பெறுவதற்குப் பதிலாக அதே சான்றுகளுடன் பொருத்த முடியும். அந்தப் பதிவு அடுத்த அறிக்கைக்கு சில வினாடிகளில் பதிலளிக்கிறது, அதே 403 மீண்டும் VPN தடையாகக் கண்டறியப்படுவதைத் தடுக்கிறது.