VPN पुन्हा कनेक्ट झाल्यानंतर प्रॉक्सी अजूनही जुन्या टनेल पत्त्यावर आहे का?

VPN क्लायंट पुन्हा सुरू केल्याने फक्त टनेल परत आले हे सिद्ध होते। त्यातून बाहेर जाण्याची सूचना मिळालेल्या प्रॉक्सीबद्दल ते काहीही सांगत नाही। Squid, tinyproxy आणि इतर बहुतेक फॉरवर्डर सुरुवातीला मिळवलेला स्थानिक स्रोत पत्ता काहीतरी त्यांना पुन्हा लोड करायला भाग पाडेपर्यंत धरून ठेवतात। पुन्हा कनेक्ट झाल्यावर नवीन टनेल पत्ता मिळाल्यास फॉरवर्डर एकतर प्रत्येक बाहेर जाणाऱ्या कनेक्शनमध्ये अपयशी ठरतो, किंवा तुमच्या नेहमीच्या मार्गाने बाहेर पडू लागतो।

दुसरे अपयश हेच धोकादायक: टनेल सुरू आहे, पाने लोड होत आहेत, आणि फक्त बाहेर जाणारा पत्ता चुकीचा आहे।

टनेलपासून नाही, लिसनरपासून सुरुवात करा

खेळात तीन पत्ते आहेत, आणि पुन्हा कनेक्ट होणे त्यांपैकी काहीच हलवते। लिसनर म्हणजे तुमचा ब्राउझर जिथे निर्देश करतो, सहसा 127.0.0.1 किंवा LAN पत्ता, आणि टनेल बदलले याची त्याला पर्वा नाही। बाहेर जाणारा स्थानिक स्रोत म्हणजे फॉरवर्डर पुढील हॉप डायल करताना कर्नेलला वापरण्यास सांगतो, आणि तो टनेल उपकरणाशी जोडलेला असतो। सार्वजनिक निर्गम म्हणजे वेब सर्व्हर नोंदवतो, आणि तो काही हॉप दूरचा भाषांतरित पत्ता असू शकतो।

सार्वजनिक IP शोध फक्त शेवटच्या प्रश्नाचे उत्तर देतो। एक सार्वजनिक निर्गम अनेक अंतर्गत स्रोत लपवू शकतो, म्हणून फॉरवर्डरने कोणत्या स्थानिक पत्त्याशी जोडले पाहिजे हे तो सांगू शकत नाही। पत्ता ज्याच्याकडे कनेक्शन आहे त्याच्याकडून वाचा: क्लायंटचे स्थिती आउटपुट, इंटरफेस स्वतः, किंवा टनेल ज्या नेमस्पेसमध्ये आहे। टनेलसारखे नाव असलेला पहिला इंटरफेस पकडल्यास दुसरी प्रोफाइल असताच चुकीचे उत्तर मिळते।

कंटेनर आणि नेमस्पेस मांडणी हे गृहीत शांतपणे मोडते। एका नेटवर्क नेमस्पेसमधील फॉरवर्डर दुसऱ्यात असलेल्या टनेलशी जोडू शकत नाही, आणि कॉन्फिगरेशन संपादनाच्या कोणत्याही प्रमाणात ते सुधारत नाही।

काहीही संपादित करण्यापूर्वी चार तपासण्या

या क्रमाने करा। पहिली अपयशी तपासणी म्हणजे थांबण्याची जागा, कारण पुढील तपासण्या आधीच्या खऱ्या असल्याचे गृहीत धरतात।

1. वापरात असलेले टनेल ज्या प्रोफाइलभोवती प्रॉक्सी बांधला होता तेच आहे याची खात्री करा, स्वतः जोडलेली दुसरी प्रोफाइल नाही।
2. त्या उपकरणावरील सध्याचा पत्ता छापा आणि चालू कॉन्फिगरेशनमधील पत्त्याशी त्याची तुलना करा।
3. डिस्कवरील फाइल जे दावा करते ते नाही, फॉरवर्डरला कोणता स्रोत सापडला ते विचारा।
4. फॉरवर्डरकडून येणारा रहदारी खरोखर तुम्ही अपेक्षित राउटिंग आणि फायरवॉल धोरणाच्या अधीन आहे याची खात्री करा।

उपकरणाचा पत्ता सोपा आहे: 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

पुन्हा लोड अपयशी झाल्यास सेवा थांबवा आणि तुकडा दुरुस्त करा; जुन्या निर्गमासह सेवा देणारी प्रॉक्सी थोड्या खंडापेक्षा वाईट आहे। पुन्हा लोड यशस्वी झाले पण नवीन विनंती अजूनही कुठेतरी अनपेक्षितपणे बाहेर जात असेल, तर पत्ते पुन्हा संपादित करण्याऐवजी राउटिंग तपासणीकडे परत जा। तुम्ही पडताळलेली टनेल पिढी नोंदवा, जेणेकरून पुढील पुन्हा कनेक्शनला तुलना करण्यासाठी ठोस काहीतरी असेल।