VPN फिर से कनेक्ट होने के बाद प्रॉक्सी अब भी पुराने टनल पते पर है?
फिर से कनेक्ट होना आपके फ़ॉरवर्डर को ऐसे पते से बँधा छोड़ सकता है जो अब टनल के पास नहीं है। चार क्रमबद्ध जाँच, एक क्रमांकित हस्तांतरण और एक वास्तविक परीक्षण अनुरोध।
VPN क्लाइंट को फिर से शुरू करना केवल यह साबित करता है कि टनल लौट आया है। यह उस प्रॉक्सी के बारे में कुछ नहीं कहता जिसे उसके ज़रिए बाहर जाने का आदेश दिया गया था। Squid, tinyproxy और अधिकांश अन्य फ़ॉरवर्डर शुरुआत में मिला स्थानीय स्रोत पता तब तक थामे रखते हैं जब तक कोई चीज़ उन्हें फिर से लोड करने को मजबूर न करे। जब फिर से कनेक्ट होने पर नया टनल पता मिलता है, तो फ़ॉरवर्डर या तो हर बाहर जाने वाले कनेक्शन पर विफल होता है, या आपके सामान्य मार्ग से बाहर जाने लगता है।
दूसरी विफलता वही खतरनाक है: टनल चालू है, पेज लोड हो रहे हैं, और केवल बाहर जाने वाला पता गलत है।
टनल से नहीं, लिसनर से शुरू करें
तीन पते खेल में हैं, और फिर से कनेक्ट होना उनमें से केवल कुछ को खिसकाता है। लिसनर वह जगह है जहाँ आपका ब्राउज़र इशारा करता है, आम तौर पर 127.0.0.1 या कोई LAN पता, और उसे इससे कोई फ़र्क नहीं पड़ता कि टनल बदल गया। बाहर जाने वाला स्थानीय स्रोत वह है जो फ़ॉरवर्डर अगले हॉप को डायल करते समय कर्नेल से इस्तेमाल करने को कहता है, और वह टनल डिवाइस से बँधा होता है। सार्वजनिक निर्गम वह है जो वेब सर्वर दर्ज करता है, और वह कई हॉप दूर का अनुवादित पता हो सकता है।
सार्वजनिक IP की खोज केवल अंतिम प्रश्न का उत्तर देती है। यह आपको नहीं बता सकती कि फ़ॉरवर्डर को किस स्थानीय पते से बँधना चाहिए, क्योंकि एक सार्वजनिक निर्गम कई आंतरिक स्रोतों को छिपा सकता है। पता उससे पढ़ें जिसके पास कनेक्शन है: क्लाइंट का स्टेटस आउटपुट, इंटरफ़ेस स्वयं, या वह नेमस्पेस जहाँ टनल रहता है। टनल जैसा दिखने वाला नाम रखने वाला पहला इंटरफ़ेस पकड़ना दूसरी प्रोफ़ाइल होते ही गलत उत्तर देता है।
कंटेनर और नेमस्पेस लेआउट इस धारणा को चुपचाप तोड़ देते हैं। एक नेटवर्क नेमस्पेस में रहने वाला फ़ॉरवर्डर दूसरे में मौजूद टनल से नहीं बँध सकता, और कॉन्फ़िगरेशन संपादन का कोई भी मात्रा उसे ठीक नहीं करती।
कुछ भी संपादित करने से पहले चार जाँच
इन्हें क्रम से करें। जो पहली जाँच विफल होती है वहीं रुकें, क्योंकि बाद वाली पहले वाली को सही मानती हैं।
- पुष्टि करें कि इस्तेमाल हो रहा टनल वही प्रोफ़ाइल है जिसके इर्द-गिर्द प्रॉक्सी बना था, न कि कोई दूसरी प्रोफ़ाइल जो अपने आप जुड़ गई।
- उस डिवाइस पर अभी मौजूद पता प्रिंट करें और उसकी तुलना चालू कॉन्फ़िगरेशन के पते से करें।
- डिस्क पर रखी फ़ाइल जो दावा करती है उसके बजाय फ़ॉरवर्डर से पूछें कि उसने कौन-सा स्रोत खोजा।
- पुष्टि करें कि फ़ॉरवर्डर का ट्रैफ़िक वास्तव में उसी रूटिंग और फ़ायरवॉल नीति के अधीन है जिसकी आप अपेक्षा करते हैं।
डिवाइस का पता आसान है: ip -4 addr show dev tun0 वर्तमान पता छापता है, और ip -4 route get 1.1.1.1 दिखाता है कि कर्नेल उस गंतव्य के लिए कौन-सा इंटरफ़ेस चुनेगा। सटीक पते से बँधने वाला फ़ॉरवर्डर पता गायब होने पर ज़ोर से विफल होता है। डिवाइस से बँधने वाला, या डिफ़ॉल्ट स्रोत पर लौटने वाला फ़ॉरवर्डर काम करता रहता है और लीक करता है, और यही शांत परिणाम है।
दस्तावेज़ीकरण को उस रिलीज़ से मिलाएँ जो आप चलाते हैं, न कि शीर्ष खोज परिणाम से। Squid का आउटगोइंग-पता निर्देश v7 और उससे पहले के लिए दस्तावेज़ीकृत है, और v8 का दस्तावेज़ीकरण स्पष्ट कहता है कि वहाँ निर्देश उपलब्ध नहीं है, इसलिए उसके इर्द-गिर्द बनी स्क्रिप्ट उस सीमा को पार नहीं करती (देखें Squid tcp_outgoing_address संदर्भ)। कुछ भी फिर से लोड करने से पहले उत्पाद के अपने पार्सर से सत्यापित करें: squid -k parse त्रुटियाँ बताता है और चल रही प्रक्रिया को छुए बिना बाहर निकल जाता है।
हर टनल को क्रमांक दें और पुरानी अदला-बदली छोड़ दें
फिर से कनेक्ट होना एक हस्तांतरण है, और हस्तांतरण को क्रम चाहिए। हर देखे गए कनेक्शन पर काउंटर या टाइमस्टैम्प का टैग लगाएँ जो हर सफल स्थापन पर बढ़े, फिर वह टैग उम्मीदवार कॉन्फ़िगरेशन के भीतर ले जाएँ। जब उम्मीदवार पर टैग वर्तमान से पुराना हो, तो उम्मीदवार को लागू करने के बजाय छोड़ दें, क्योंकि पिछले टनल के लिए लिखा धीमा अद्यतन अन्यथा वर्तमान की सेटिंग्स को मिटा देगा। घटनाओं के झोंकों को एक करें ताकि झूलती लिंक पंद्रह के बजाय एक संक्रमण दे।
काम को चार चालों में व्यवस्थित करें: पुरानी निर्गम स्थिति को अमान्य करें, कनेक्शन के मालिक के पूर्णता की रिपोर्ट की प्रतीक्षा करें, केवल प्रबंधित अंश बनाएँ, फिर सेवा प्रबंधक के ज़रिए सत्यापित और सक्रिय करें। दो पता मानों से पूरी फ़ाइल फिर से बनाना ही वह तरीका है जिससे लिसनर प्रतिबंध, प्रमाणीकरण और गंतव्य नीति चुपचाप गायब हो जाते हैं। जानबूझकर रोक का भी सम्मान करें। उपयोगकर्ता द्वारा बंद किए गए टनल पर डायल करते रहने वाला सहायक बग है, लचीलापन नहीं।
खुले सॉकेट नए पते का पालन नहीं करेंगे
फ़ॉरवर्डर को फिर से कॉन्फ़िगर करना पहले से स्थापित कनेक्शनों के बारे में कुछ नहीं कहता। वे खाली होंगे या मरेंगे यह उत्पाद पर निर्भर है, इसलिए मानने के बजाय व्यवहार देखें।
बदली से पहले खोले गए सॉकेट पर परोसा गया अनुरोध नई कॉन्फ़िगरेशन सही होने पर भी पुराने मार्ग से बाहर जाता है। यदि यह मायने रखता है तो स्पष्ट निर्णय लें: छोटी खालीकरण विंडो दें और नया काम स्वीकार करना बंद करें, या पुराने सॉकेट बंद करें और त्रुटियाँ स्वीकारें। फिर ताज़ा कनेक्शन से परीक्षण करें और उस परिणाम को खालीकरण जाँच से अलग रखें। स्रोत से बँधना भी सुरक्षा सीमा नहीं है। जब ट्रैफ़िक को कभी सामान्य मार्ग नहीं छूना चाहिए, तो उसे चिह्नों और फ़ायरवॉल नियमों से लागू करें, DNS और IPv6 सहित, ताकि विफल पुनःलोड प्रॉक्सी को खुला रखने के बजाय स्पष्ट रूप से बंद छोड़े।
नए निर्गम को ताज़ा अनुरोध से साबित करें
मायने यह रखता है कि अनुरोध सक्रियण के बाद खोला गया हो, ping नहीं और पहले से कैश किया गया पेज नहीं। प्रॉक्सी से वास्तविक URL माँगें और दूर के छोर द्वारा बताया गया निर्गम पता पढ़ें, फिर जब प्रदाता एक दिखाए तो क्लाइंट के टनल के अपने दृष्टिकोण से तुलना करें।
पार्सिंग, पुनःलोड और अनुरोध को अलग कमांड रखें ताकि विफलता एक ही चरण की ओर इशारा करे। पहले दो विफल होने पर कुछ नहीं बदलते, और इसीलिए वे पुनः आरंभ से पहले चलते हैं।
squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.comयदि पुनःलोड विफल हो, तो सेवा रोकें और अंश ठीक करें; पुराने निर्गम के साथ सेवा देने वाली प्रॉक्सी छोटी रुकावट से बुरी है। यदि पुनःलोड सफल हो पर ताज़ा अनुरोध अब भी कहीं अप्रत्याशित जगह से बाहर जाए, तो फिर से पते संपादित करने के बजाय रूटिंग जाँच पर लौटें। जिस टनल पीढ़ी के विरुद्ध आपने सत्यापन किया उसे दर्ज करें, ताकि अगली बार फिर से कनेक्ट होने पर तुलना के लिए कुछ ठोस हो।