mitmproxy, DevTools, Gradle: VPN-ന് പിന്നിലെ മൂന്ന് പാളികൾ
loopback ഒരിക്കലും ടണലിൽ പ്രവേശിക്കുന്നില്ല. ലക്ഷണത്തെ ശ്രോതാവ്, ട്രസ്റ്റ് സ്റ്റോർ അല്ലെങ്കിൽ പാക്കറ്റ് ഫിൽട്ടർ എന്ന് വർഗ്ഗീകരിച്ച് യഥാർത്ഥത്തിൽ പരാജയപ്പെട്ട പാളി നന്നാക്കുക.
VPN കണക്റ്റ് ചെയ്യുന്നു, കൂടാതെ ബന്ധമില്ലാത്ത മൂന്ന് ഉപകരണങ്ങൾ മൂന്ന് വ്യത്യസ്ത രീതികളിൽ പരാജയപ്പെടുന്നു അതേ ഉച്ചയ്ക്ക്. mitmproxy അഭ്യർത്ഥനകൾ കാണുന്നത് നിർത്തുന്നു, Chrome ഡീബഗ്ഗർ നിരസിക്കുന്നു, Gradle BindException ലോക്കൽ സോക്കറ്റ് ബൈൻഡ് ചെയ്യുമ്പോൾ എറിയുന്നു. പൊതുവായ സംശയം ടണൽ localhost തടയുന്നു എന്നതാണ്. അതിന് സാധിക്കില്ല: 127.0.0.1 കേർണലിനുള്ളിൽ കൈകാര്യം ചെയ്യപ്പെടുന്നു, ഒരിക്കലും അഡാപ്റ്ററിലെത്തുന്നില്ല, ഗേറ്റ്വേയുടെ കാര്യം പറയേണ്ടതില്ല.
മൂന്ന് പാളികൾ, മൂന്ന് വ്യത്യസ്ത തകരാറുകൾ
ക്ലൈന്റിനൊപ്പം മാറിയത് loopback-ലേക്കുള്ള വഴിയല്ല. അത് ഒരു ലോക്കൽ പ്രോക്സി, മെഷീന്റെ ട്രസ്റ്റ് സ്റ്റോർ, പാക്കറ്റ് ഫിൽട്ടർ എന്നിവയാണ്, ഓരോന്നും ഡെവലപ്പറുടെ വർക്ക്ഫ്ലോയുടെ വ്യത്യസ്ത ഭാഗം തകർക്കുന്നു. ലക്ഷണത്തെ ശരിയായ വരിയിൽ ഉൾപ്പെടുത്തുന്നതാണ് രോഗനിർണ്ണയത്തിന്റെ വലിയ ഭാഗം:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
ഇത്തരത്തിലുള്ള മിക്കവാറും എല്ലാ റിപ്പോർട്ടുകളും അവസാന വരിയിൽ നിന്ന് ആരംഭിച്ച് മുകളിലേക്ക് പോകുന്നു, അത് തലകീഴാണ്. loopback ട്രാഫിക് കാണാൻ കഴിയില്ലെന്ന് തെളിയിക്കാവുന്ന ഏക പാളി ടണലാണ്, അതിനാൽ ഏറ്റവും കുറഞ്ഞ സംശയം അതിനാണ്. പ്രോസസ് എന്ത് ബൈൻഡ് ചെയ്തു എന്നതിൽ നിന്ന് തുടങ്ങി, പിന്നീട് അത് ഏത് സർട്ടിഫിക്കറ്റുകളെ വിശ്വസിക്കുന്നു എന്ന് ചോദിക്കുക, അതിനുശേഷം മാത്രം മെഷീനിലെ നയം നോക്കുക.
ടണലിൽ നിന്നല്ല, ശ്രോതാവിൽ നിന്ന് തുടങ്ങുക
എപ്പോൾ 127.0.0.1:8080 ഒരു പ്രോക്സി ട്രാഫിക് സ്വീകരിക്കുന്നത് നിർത്തുന്നു, മൂന്നിൽ ഒന്ന് സംഭവിച്ചു: അത് ഒരിക്കലും ആരംഭിച്ചില്ല, മറ്റൊരു പോർട്ട് ബൈൻഡ് ചെയ്തു, അല്ലെങ്കിൽ ഫിൽട്ടർ loopback കണക്ഷൻ ഉപേക്ഷിച്ചു. കേൾക്കുന്ന സോക്കറ്റുകൾ ലിസ്റ്റ് ചെയ്യുന്നത് ഒരു കമാൻഡിൽ ഉത്തരം നൽകുന്നു, ഒപ്പം രണ്ട് ഉപകരണങ്ങൾ ആദ്യം ആരായിരുന്നു എന്നതിൽ യോജിക്കാതിരിക്കുമ്പോൾ ഏത് പ്രോസസിനാണ് പോർട്ട് എന്നും കാണിക്കുന്നു.
റൂട്ട് തിരയലിൽ ലോക്കൽ വിലാസം മറുവശത്തുനിന്ന് അതേ കാര്യം സ്ഥിരീകരിക്കുന്നു. ip route get loopback ലക്ഷ്യത്തിലേക്ക് അത് loopback ഉപകരണം റിപ്പോർട്ട് ചെയ്യുന്നു, ഒരിക്കലും ടണൽ അല്ല, ഒരാൾ റൂട്ടിംഗ് മാറ്റം പരിഹാരമായി നിർദ്ദേശിക്കുമ്പോൾ തയ്യാറായി സൂക്ഷിക്കാവുന്ന ഉപയോഗപ്രദമായ വാക്യമാണിത്.
പ്രോക്സി പാളി: പരിസ്ഥിതി കോൺഫിഗറേഷൻ അല്ല
നിരവധി കോർപ്പറേറ്റ് ക്ലയന്റുകൾ HTTP പ്രോക്സി പ്രവർത്തിപ്പിക്കുന്നു, ആപ്ലിക്കേഷനുകൾ അത് ഉപയോഗിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു. സെറ്റ് ചെയ്യുന്നത് HTTPS_PROXY ഒരു ഷെല്ലിൽ അത് മാനിക്കുന്ന കമാൻഡ് ലൈൻ ഉപകരണങ്ങൾ നന്നാക്കുന്നു, സ്വന്തം സെറ്റിംഗ്സ് ഫയൽ വായിക്കുന്ന ഉപകരണത്തിന് ഒന്നും ചെയ്യുന്നില്ല. Gradle, Selenium, gRPC ഓരോന്നും സ്വന്തം കോൺഫിഗറേഷൻ പരിശോധിക്കുന്നു, ഒരു ടെർമിനലിൽ എക്സ്പോർട്ട് ചെയ്ത പ്രോക്സി IDE ആരംഭിച്ച ഡെമണിന് അദൃശ്യമാണ്.
കണ്ടെയ്നർ ഉപകരണങ്ങൾ ഇത് ദൃശ്യമാകുന്ന സാധാരണ സ്ഥലമാണ്. ഒരു കണ്ടെയ്നറിന്റെ loopback അതിന്റേതാണ്, അതിനാൽ 127.0.0.1 കണ്ടെയ്നറിനുള്ളിൽ ഒരിക്കലും ഹോസ്റ്റിന്റെ പ്രോക്സി അർത്ഥമാക്കുന്നില്ല; ഹോസ്റ്റ് വിലാസമോ ഹോസ്റ്റ് നെറ്റ്വർക്ക് ക്രമീകരണമോ ആവശ്യമാണ്. ഷെല്ലിൽ പ്രവർത്തിച്ച് ബിൽഡിൽ പരാജയപ്പെടുന്ന പരിഹാരം സാധാരണയായി ഈ വരിയാണ്, ടണലല്ല.
ട്രസ്റ്റ് പാളി: ഉപകരണം മറ്റൊരു സ്റ്റോർ വായിക്കുന്നു
ഇന്റർസെപ്ഷൻ രണ്ടാമത്തെ മാറ്റമാണ്, അത് ഏറ്റവും തെറ്റിദ്ധരിപ്പിക്കുന്ന പിശകുകൾ സൃഷ്ടിക്കുന്നു. പരിശോധിക്കുന്ന കണക്ഷനുകൾക്ക് ക്ലയന്റ് സ്വന്തം സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്നു, അതിനാൽ കോർപ്പറേറ്റ് റൂട്ട് വിശ്വസിക്കുന്ന ബ്രൗസർ വിജയിക്കുന്നു, ബണ്ടിൽ ചെയ്ത CA സ്റ്റോർ ഉള്ള ഉപകരണം പരാജയപ്പെടുന്നു. certifi വഴിയുള്ള Python requests ആണ് ക്ലാസിക് കേസ്: ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ സ്റ്റോർ ശരിയായിരിക്കാം, എന്നിട്ടും അഭ്യർത്ഥന പരാജയപ്പെടുന്നു, കാരണം ആ റൺടൈം അത് ഒരിക്കലും വായിക്കുന്നില്ല. പിശക് ടെക്സ്റ്റ് ഇന്റർസെപ്ഷൻ അപൂർവ്വമായി മാത്രം പരാമർശിക്കുന്നു, അതുകൊണ്ടാണ് ഈ വരി തകർന്ന എൻഡ്പോയിന്റ് എന്ന് തെറ്റായി രോഗനിർണ്ണയം ചെയ്യപ്പെടുന്നത്.
എൻഡ്പോയിന്റ് യഥാർത്ഥത്തിൽ എന്ത് അവതരിപ്പിക്കുന്നു എന്നതിനെ ഉപകരണം സാധൂകരിച്ചതുമായി താരതമ്യം ചെയ്യുക. openssl s_client സെർവർ അയച്ച ശൃംഖല കാണിക്കുന്നു; ഉപകരണത്തിന്റെ സ്വന്തം സാധൂകരണ ഔട്ട്പുട്ട് അത് എന്ത് തീരുമാനിച്ചു എന്ന് കാണിക്കുന്നു. അവ ഒത്തുപോകാത്തപ്പോൾ, REQUESTS_CA_BUNDLE അല്ലെങ്കിൽ SSL_CERT_FILE ആ റൺടൈമിനുള്ള ലിവറാണ്, കോർപ്പറേറ്റ് റൂട്ട് ആ റൺടൈം വായിക്കുന്ന സ്റ്റോറിലായിരിക്കണം, ചില ഉപകരണങ്ങൾ മാത്രം മാനിക്കുന്ന ആഗോള സ്ഥലത്തല്ല.
SSL പിശക് പരിഹരിക്കുന്ന പതിപ്പ് മാറ്റം VPN-നെക്കുറിച്ചല്ല, ട്രസ്റ്റ്, സൈഫർ നയത്തെക്കുറിച്ചുള്ള തെളിവാണ്. SOAP ക്ലയന്റ് പ്രവർത്തിപ്പിച്ച Python ഡൗൺഗ്രേഡ് ബണ്ടിൽ ചെയ്ത CA സ്റ്റോറും ഡിഫോൾട്ട് TLS ക്രമീകരണങ്ങളും മാറ്റി; നെറ്റ്വർക്ക് പാത നീങ്ങിയില്ല.
ഫിൽട്ടർ പാളി: അതിന് loopback-ഉം ഉപേക്ഷിക്കാം
മൂന്നാമത്തെ മാറ്റം പാക്കറ്റ് ഫിൽട്ടറാണ്, ചില ഉൽപ്പന്നങ്ങൾ ടണലിൽ പ്രവേശിക്കാത്ത ട്രാഫിക് ഉപേക്ഷിക്കുന്ന നിയമങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ലോക്കൽ ശ്രോതാക്കളും ഉൾപ്പെട്ടേക്കാം. അത് പ്രവർത്തിക്കുന്ന സോക്കറ്റിനെ നിരസിക്കപ്പെട്ടതോ സമയപരിധി കഴിഞ്ഞതോ ആയ കണക്ഷനാക്കുന്നു, ഫലമായുണ്ടാകുന്ന പിശക് മെഷീനിലെ നയമല്ല, ആപ്ലിക്കേഷനിലെ ബഗ് പോലെ തോന്നുന്നു.
പോർട്ട് ഉടമസ്ഥത ഈ പാളിയുടെ മറ്റേ പകുതിയാണ്. BindException സോക്കറ്റ് തുറക്കാൻ കഴിഞ്ഞില്ല എന്നർത്ഥം, ഇത് കണക്ഷൻ നിരസിക്കപ്പെടുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ പരാജയമാണ്. ഫിൽട്ടറെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് മറ്റൊരു പ്രോസസ് പോർട്ട് കൈവശം വച്ചിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുക, പിന്നീട് ലോക്കൽ ട്രാഫിക് ഉപേക്ഷിക്കുന്ന നിയമം കണ്ടെത്തി ഉൽപ്പന്നം പിന്തുണയ്ക്കുന്ന ഏറ്റവും ഇടുങ്ങിയ അനുമതി ചേർക്കുക. ഒരേ ഡീബഗ് പോർട്ടിനായി മത്സരിക്കുന്ന രണ്ട് ഉപകരണങ്ങൾ നയ തടയലിന് സമാനമായ അതേ സന്ദേശം നൽകുന്നു, അവയിൽ ഒന്ന് മാത്രമാണ് ഫയർവാൾ മാറ്റത്തിലൂടെ ശരിയാകുന്നത്.
Chrome-ന്റെ ഡീബഗ് പോർട്ടും അതേ കുടുംബത്തിൽ പരാജയപ്പെടുന്നു. ബ്രൗസർ ആരംഭിക്കുന്നു, ഡ്രൈവർക്ക് DevTools എൻഡ്പോയിന്റിൽ എത്താൻ കഴിയുന്നില്ല, സന്ദേശം നെറ്റ്വർക്കിനെക്കാൾ DevTools-നെ പേര് പറയുന്നു. അധിക ലോഞ്ച് ഫ്ലാഗുകളും അനാവശ്യ ഡ്രൈവർ മാനേജറും ഏത് പ്രോസസിനാണ് പോർട്ട് എന്നത് മാറ്റുന്നു, അതുകൊണ്ടാണ് അവ നീക്കം ചെയ്യുന്നത് ചിലപ്പോൾ VPN ശരിയാക്കിയതായി തോന്നുന്നത്.
പരാജയപ്പെട്ട പാളി നന്നാക്കുക
ടണലല്ല, പരാജയപ്പെട്ട പാളി നന്നാക്കുക. എത്തിച്ചേരാനാകാത്ത loopback ശ്രോതാവിന് അതിന്റെ ശ്രോതാവോ പോർട്ടോ തിരുത്തേണ്ടതുണ്ട്. വിശ്വസനീയമല്ലാത്ത സർട്ടിഫിക്കറ്റിന് ആ നിർദ്ദിഷ്ട റൺടൈം നോക്കുന്നിടത്ത് കോർപ്പറേറ്റ് റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യണം, ഒഴിവാക്കൽ ഇടുങ്ങിയതായി സൂക്ഷിക്കണം. ലോക്കൽ ട്രാഫിക് ഉപേക്ഷിക്കുന്ന ഫിൽട്ടറിന് നിഷ്ക്രിയ ഫിൽട്ടറല്ല, നിർദ്ദിഷ്ട അനുമതി നിയമം ആവശ്യമാണ്, കാരണം നിഷ്ക്രിയമാക്കുന്നത് അത് സംരക്ഷിച്ച മറ്റെല്ലാം വീണ്ടും തുറക്കുന്നു.
VPN വീണ്ടും കണക്റ്റ് ചെയ്യുന്നത് ഈ പാളികളിൽ ഒന്നും പരിശോധിക്കുന്നില്ല. അവ തകർത്ത മാറ്റം മാത്രം വീണ്ടും പ്രവർത്തിപ്പിക്കുന്നു, അതുകൊണ്ടാണ് അതേ മൂന്ന് പരാജയങ്ങൾ ഓരോ പുനഃസംപർക്കത്തിനും ശേഷം തിരികെ വരുന്നതും ക്ലൈയന്റിനെ നിഷ്ക്രിയമായി വിടുന്ന ഓരോ റീബൂട്ടിനും ശേഷം അപ്രത്യക്ഷമാകുന്നതും.