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-ஐ மீண்டும் இணைப்பது இந்த அடுக்குகளில் எதையும் சோதிக்கவில்லை. அது அவற்றை உடைத்த மாற்றத்தை மட்டுமே மீண்டும் இயக்குகிறது, அதனால்தான் அதே மூன்று தோல்விகள் ஒவ்வொரு மறுஇணைப்புக்குப் பிறகும் திரும்பி வந்து, கிளையனைச் செயலற்றதாக விட்டுச் செல்லும் ஒவ்வொரு மறுதொடக்கத்திற்குப் பிறகும் மறைந்துவிடுகின்றன.