क्या VPN लैपटॉप को तेज़ होने के लिए IP फ़ॉरवर्डिंग की ज़रूरत है?
फ़ॉरवर्डिंग इंटरफ़ेस के बीच पैकेट भेजती है; यह स्थानीय ब्राउज़र को तेज़ नहीं करती। नियम चौड़ा करने से पहले क्लाइंट भूमिका को गेटवे भूमिका से अलग करें।
लैपटॉप को राउटर बनाना ग़लत समस्या हल करने का लोकप्रिय तरीका है। फ़ॉरवर्डिंग इसलिए है कि एक मशीन ऐसे पैकेट आगे भेज सके जिनका गंतव्य वह ख़ुद न हो, और उसी मशीन पर ब्राउज़र कितनी तेज़ी से पेज लोड करता है, इस पर उसकी कोई राय नहीं है। दोनों रास्ते केवल इसलिए एक जैसे दिखते हैं क्योंकि दोनों एक ही सुरंग से ट्रैफ़िक भेजते हैं। एक बार उन्हें अलग करें, और फ़ॉरवर्डिंग सक्षम करने या फ़ायरवॉल खोलने की बहुत सी सलाह ऐसी टोपोलॉजी बताती मिलेगी जो आपके पास नहीं है।
डेस्क से एक जैसे दिखने वाले दो पैकेट रास्ते
लैपटॉप का ब्राउज़र अपना ख़ुद का अनुरोध बनाता है। होस्ट सुरंग का रूट चुनता है, क्लाइंट प्रक्रिया पैकेट को लपेटकर साथी को भेजती है, और जवाब ऐप्लिकेशन पर लौट आता है। उस क्रम में कुछ भी फ़ॉरवर्डिंग निर्णय पार नहीं करता, क्योंकि यह मशीन बातचीत का स्रोत और गंतव्य दोनों है।
अब जान-बूझकर कॉन्फ़िगर किए गए ईथरनेट सेगमेंट पर दूसरा डिवाइस रखें और लैपटॉप को उसका डिफ़ॉल्ट गेटवे बनाएं। वह डिवाइस अनुरोध शुरू करता है, लैपटॉप को कहीं और पते वाला पैकेट मिलता है, और कर्नेल को तय करना होता है कि उसे आगे भेजना है या नहीं। यही फ़ॉरवर्डिंग भूमिका है, और यह ऐसी पूर्वशर्तों के साथ आती है जिनकी क्लाइंट भूमिका को कभी ज़रूरत नहीं पड़ी: अनुमत ट्रांज़िट मार्ग, दोनों ओर रूट, और वापसी का रास्ता जो अनुवाद डिज़ाइन का हिस्सा हो तो भी काम करता रहे।
| Role | Who originates the traffic | What has to be true |
|---|---|---|
| Client only | The laptop itself | Tunnel route, working resolver, supported profile |
| Gateway | Another device | Forwarding enabled, permitted transit, routes both ways, return-path decision |
ip_forward असल में क्या बदलता है
कर्नेल का IPv4 sysctl दस्तावेज़ ip_forward को वह स्विच बताता है जो होस्ट को इंटरफ़ेस के बीच पैकेट फ़ॉरवर्ड करने देता है। यह होस्ट द्वारा ख़ुद बनाए ट्रैफ़िक के लिए तेज़ रास्ता नहीं है, और उस पैरामीटर की कोई भी व्याख्या स्थानीय ब्राउज़र को तेज़ नहीं करती। अगर कुछ है तो फ़ॉरवर्डिंग उस मशीन में स्थिति और नीति जोड़ती है जो पहले कम काम करती थी।
यही दस्तावेज़ चेतावनी देता है कि मान बदलने से दूसरे IPv4 पैरामीटर होस्ट या राउटर के डिफ़ॉल्ट पर लौट जाते हैं। यह स्विच को जाँच के बजाय कॉन्फ़िगरेशन घटना बनाता है: ट्यून की गई सेटिंग्स आपके पैरों के नीचे से वापस आ सकती हैं, और बदलाव ऐसे रिग्रेशन का कारण हो सकता है जिसे कोई उससे जोड़ने की सोच भी नहीं सकता। इसका मतलब यह भी है कि स्विच एक बार, जान-बूझकर, गेटवे भूमिका के मालिक द्वारा सेट होना चाहिए। धीमेपन की जाँच के दौरान उसे पलटना एकमात्र ऐसा मामला है जहाँ दुष्प्रभाव के लक्षण से गड़बड़ होना तय है।
तीन फ़ायरवॉल सवाल जो एक सवाल नहीं हैं
VPN श्रोता को अनुमति देना, लैपटॉप जो सेवाएँ चलाता है उन्हें अनुमति देना, और ट्रैफ़िक को लैपटॉप से गुज़रने देना तीन अलग अनुमतियाँ हैं। पहली साथी को डेमन तक पहुँचने देती है, दूसरी कुछ स्थानीय खोल देती है, और तीसरी मशीन को किसी और के लिए ट्रांज़िट बना देती है। हर एक का दायरा अलग है, और आख़िरी सामान्य बहिर्गामी ऐप्लिकेशन को ज़रूरी जवाबों से बहुत ज़्यादा चौड़ा है।
जब कोई ख़ास प्रवाह अवरुद्ध हो, तो नियम संपादित करने से पहले उसका स्रोत, गंतव्य, दिशा और नीति का मालिक बताएं। उस प्रवाह के लिए संकरा नियम सुधार है; सुरंग इंटरफ़ेस पर सब कुछ स्वीकार करना ऐसा नीति बदलाव है जो संयोग से सुधार को शामिल करता है। बाद में काम करने वाला ब्राउज़र साबित करता है कि प्रवाह काम करता है, यह नहीं कि चौड़ा नियम ज़रूरी था।
मापें तभी जब रास्ता सही हो
उसी गंतव्य, उसी कार्यभार और तुलनीय परिस्थितियों के साथ मापें, और एक बार में एक चर बदलें। जो परीक्षण फ़ॉरवर्डिंग बदलाव, फ़ायरवॉल चौड़ा करना और नक़ल की गई साइफ़र सेटिंग को एक साथ बाँधता है, वह एक संख्या देता है और कोई व्याख्या नहीं, क्योंकि उसमें कुछ भी नहीं बताता कि तीनों में से किसने परिणाम हिलाया।
रूट और रिज़ॉल्वर की विफलताओं को प्रदर्शन की बातचीत से पूरी तरह बाहर रखें। धीरे हल होने वाला नाम थ्रूपुट समस्या नहीं है, और एक तय आकार पर अटकने वाला स्थानांतरण आम तौर पर MTU का सवाल है, गति सीमा नहीं। कोई भी संख्या तुलना करने से पहले लिखें कि इन तीनों में से क्या आपने वास्तव में देखा। वरना अगला पाठक ऐसा माप विरासत में लेता है जो ग़लत चीज़ मापता है और ऐसा बदलाव जिसे कोई उचित नहीं ठहरा सकता।
अपने पास जो टोपोलॉजी है उसका वर्णन करें, क्लाइंट पर लगा लेबल नहीं
जो लैपटॉप अपना कनेक्शन साझा करता है, रूटेड कंटेनर नेटवर्क होस्ट करता है या वर्चुअल मशीन के लिए ट्रैफ़िक ढोता है, वह गेटवे है, सॉफ़्टवेयर ख़ुद को जो भी कहे। क्लाइंट शब्द बताता है कि सुरंग कैसे कॉन्फ़िगर है, यह नहीं कि पैकेट किसी और को भेजे जाते हैं या नहीं।
ऑपरेटिंग गाइड में भूमिका स्पष्ट करें: ट्रैफ़िक क्या पैदा करता है, मशीन से क्या गुज़रना चाहिए, और मौजूदा काम इन दोनों में से किस बारे में है। गेटवे भूमिका तब सक्षम करें जब वह समर्थित योजना का हिस्सा हो, ऐसी बिना समझाए गति समायोजन के रूप में नहीं जो कभी ज़रूरत न पड़ी टोपोलॉजी पर लगाई जाए।