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

पुनः लोड असफल भए सेवा रोक्नुहोस् र टुक्रा सुधार्नुहोस्; पुरानो निकाससहित सेवा दिने प्रोक्सी छोटो अवरोधभन्दा नराम्रो हो। पुनः लोड सफल भए पनि नयाँ अनुरोध अझै कतै अप्रत्याशित रूपमा बाहिर जान्छ भने ठेगाना फेरि सम्पादन गर्नुको सट्टा राउटिङ जाँचमा फर्कनुहोस्। तपाईंले प्रमाणित गरेको टनेल पुस्ता अभिलेख गर्नुहोस्, ताकि अर्को पुनः जोडिनेमा तुलना गर्न ठोस केही होस्।