கார்ப்பரேட் VPN பின்னால் ஆப் கோரிக்கைகள் தோல்வியடைகின்றன, ஆனால் உலாவி வேலை செய்கிறது

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

ஆப் உண்மையில் அனுப்பும் கோரிக்கையைப் பாருங்கள்

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

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

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

யாரும் கட்டமைக்காத ப்ராக்ஸியை ஆப் வாரிசாகப் பெற்றது

பெரும்பாலான HTTP ஸ்டாக்குகள் இயக்க முறைமையிலிருந்து ப்ராக்ஸி கட்டமைப்பை இயல்பாகவே படிக்கின்றன. கார்ப்பரேட் VPN கிளையண்ட் அதைத் தன் அணுகல் சுயவிவரத்தின் பகுதியாக நிறுவுகிறது, எனவே கோரிக்கைகள் டெவலப்பர் குறியீட்டில் ஒருபோதும் குறிப்பிடாத ப்ராக்ஸி வழியாக வெளியேறுகின்றன. .NET இல் இயல்புநிலை ஹேண்ட்லர் IE/WinHTTP அமைப்புகளிலிருந்து எடுக்கிறது; Java -Dhttp.proxyHost படிக்கிறது; Node இல் நூலகம் சேர்க்கும் வரை உள்ளமைந்த ப்ராக்ஸி ஆதரவு இல்லை. தோல்வி அரிதாகவே தூய்மையான மறுப்பாக இருக்கிறது, அதனால்தான் மக்கள் சேவையகத்தைப் பார்க்கத் தொடங்குகிறார்கள்.

சோதனையின் செலவு ஒரு கோரிக்கை: ஒரு ஹேண்ட்லரில் ப்ராக்ஸியை வெளிப்படையாக அணைத்து ஒப்பிடுங்கள்.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

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

நீங்கள் தேர்ந்தெடுத்த போர்ட் கொள்கை அனுமதிக்கும் போர்ட் அல்ல

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

அதே சேவையை 443 பின்னால் வெளியிட்டு, விதிவிலக்குக் கேட்பதற்கு முன் பெயரால் அதை அடையுங்கள். விதிவிலக்கு உண்மையிலேயே தேவைப்பட்டால், அதை ஒரு மூல வரம்பு மற்றும் ஒரு இலக்குக்கு மட்டுப்படுத்தி, அதை ஒருவரின் தனிப்பட்ட தவிர்ப்பு அல்ல, சேவை வரையறையின் பகுதியாகக் கருதுங்கள்.

பாதை மீளமைக்கும் மூல TCP

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

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

பெரிய பேலோடுகளில் மட்டுமே மூடப்படும் இணைப்புகள்

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

பேலோடை ஆப் அடுக்கில் துண்டுகளாகப் பிரிக்கவும். இதை MTU வேலையிலிருந்து தனியாக வைத்திருங்கள்: சுரங்கப்பாதையின் பாக்கெட் அளவைக் குறைப்பது சாதாரண TCP அமர்வுகள் நிலையான பைட் எண்ணிக்கையில் நின்றால் உதவுகிறது, இடைநிலையாளர் மிகப் பெரியதாகக் கருதும் செய்திக்கு அது எதுவும் செய்யாது.

ஒரே படியில் நான்கையும் வேறுபடுத்துவது எப்படி

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

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