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 फेरि जोड्नुले यी कुनै पनि तहको परीक्षण गर्दैन। यसले ती तोड्ने परिवर्तन मात्र फेरि चलाउँछ, त्यसैले तीही तीन असफलता हरेक पुनःजडानपछि फर्केर आउँछन् र क्लाइन्टलाई निष्क्रिय छोड्ने हरेक रिबुटपछि हराउँछन्।