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 पुन्हा जोडणे यापैकी कोणत्याही स्तराची चाचणी करत नाही। तो फक्त ते तोडणारा बदल पुन्हा चालवतो, म्हणून तेच तीन अपयश प्रत्येक पुनर्जोडणीनंतर परत येतात आणि क्लायंट निष्क्रिय ठेवणार्या प्रत्येक रीबूटनंतर अदृश्य होतात।