കോർപ്പറേറ്റ് 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-ഉം പാരമ്പര്യ പ്രോക്സിയും ആപ്പിന്റെ സ്വതവെയുള്ള മൂല്യവും ഒരുമിച്ച് മൂന്ന് സാദ്ധ്യമായ കാരണങ്ങൾ നൽകുന്നു.

ഓരോ പരിശോധനയിലും ഒരു വേരിയബിൾ സൂക്ഷിച്ച്, നിങ്ങൾ ഉപയോഗിച്ച ലക്ഷ്യ ഹോസ്റ്റ് രേഖപ്പെടുത്തുക. ആ അടിസ്ഥാന രേഖയില്ലാതെ അടുത്ത വ്യക്തി നാല് ഘട്ടങ്ങളും വീണ്ടും തുടക്കം മുതൽ ആവർത്തിക്കുന്നു.