ब्रिज मोड और VPN पास-थ्रू एक ही समस्या-निवारण थ्रेड में आते हैं, क्योंकि दोनों उस VPN के लिए समाधान के रूप में सुझाए जाते हैं जो कनेक्ट नहीं होता। ये राउटर के अलग-अलग कार्यों का वर्णन करते हैं, और इनमें से कोई अकेले VPN टनल नहीं बनाता। ब्रिजिंग बदलती है कि कोई डिवाइस नेटवर्क सेगमेंट से कैसे जुड़ता है या राउटिंग कौन करता है; पास-थ्रू तय करता है कि क्लाइंट का VPN ट्रैफ़िक गेटवे पार कर सकता है या नहीं। ग़लत विकल्प छोटी समस्या को पूरी दोपहर के पता-पुनर्निर्धारण में बदल देता है।

दो नाम, दो अलग कार्य

परीक्षण सरल है: क्या आप नेटवर्क का आकार बदलना चाहते हैं, या पहले से मौजूद ट्रैफ़िक को उससे गुज़रने देना चाहते हैं? ये अलग-अलग अनुरोध हैं और इनके परिणाम भी अलग हैं।

एक तालिका में तुलना:

SettingWhat it actually does
Bridge modeChanges the device's forwarding role: a modem bridge hands routing and NAT downstream, a software bridge joins selected interfaces
VPN pass-throughLets a client's VPN traffic cross the router; the credentials and encryption stay with the client
Router VPN clientTerminates the tunnel on the router, so the router becomes the endpoint
Router VPN serverAccepts inbound tunnels, which needs an upstream path that can reach it

केवल अंतिम दो ही राउटर पर टनल बनाते हैं। ब्रिजिंग और पास-थ्रू दोनों एंडपॉइंट को कहीं और छोड़ देते हैं, इसलिए इनमें से कोई भी गुम क्लाइंट या अगम्य सर्वर से पैदा हुई समस्या नहीं सुधार सकता। यह अंतर खोना आसान है, क्योंकि सेटिंग्स एक ही इंटरफ़ेस में पास-पास होती हैं। वह पृष्ठ खोलने से पहले लिख लें कि टनल किस एंडपॉइंट का है।

पास-थ्रू चेकबॉक्स भी प्रोटोकॉल समर्थन का पूरा विवरण नहीं है। IPsec में आधुनिक NAT ट्रैवर्सल मानकीकृत UDP एनकैप्सुलेशन का उपयोग करता है, जबकि पुरानी सहायक सुविधाओं का व्यवहार कार्यान्वयन पर निर्भर होता है।

VPN समर्थन का दावा करने वाला मार्केटिंग लेबल यह नहीं बताता कि इन चार भूमिकाओं में से कौन-सी अभीष्ट है।

ब्रिज मोड आपके डिवाइस पर क्या बदलता है

मॉडेम या राउटर पर ब्रिज विकल्प आमतौर पर राउटिंग और NAT की ज़िम्मेदारियाँ नीचे के दूसरे गेटवे को स्थानांतरित करता है। सॉफ़्टवेयर डिवाइस पर इसका अर्थ चुने हुए स्थानीय इंटरफ़ेस को एक ही ब्रॉडकास्ट डोमेन में जोड़ना हो सकता है। सटीक दायरा उत्पाद पर निर्भर है, इसलिए शब्द का नहीं, मॉडल का दस्तावेज़ पढ़ें। दोनों व्याख्याएँ पता आवंटन, फ़ायरवॉल सीमाएँ और प्रशासन तक पहुँचने का तरीका बदल देती हैं।

इसी कारण ब्रिजिंग VPN विफलता का ख़राब पहला उत्तर है। मूल समस्या अभी अनसुलझी रहते हुए आप प्रबंधन पथ खो सकते हैं।

नेटवर्क भूमिका बदलने से पहले कॉन्फ़िगरेशन का बैकअप रखें, क्योंकि पता-निर्धारण उसके साथ खिसक सकता है।

सेटिंग से पहले भूमिका चुनें

घर के ट्रैफ़िक को बाहरी एग्ज़िट से भेजने के लिए आपको संगत राउटर VPN क्लाइंट चाहिए, ब्रिज नहीं। कहीं और से घर लौटकर जुड़ने के लिए आपको सर्वर भूमिका और एक अपस्ट्रीम मार्ग चाहिए जो उस तक पहुँच सके। इन दोनों आवश्यकताओं में VPN शब्द के अलावा लगभग कुछ भी साझा नहीं है। मेन्यू देखने से पहले तय करें कि आप कौन-सा बना रहे हैं।

कोई डिवाइस दोनों भूमिकाएँ समर्थित कर सकता है और फिर भी जिस भूमिका की आपको ज़रूरत है उसे उस गति पर समर्थित न करे जिसकी आप अपेक्षा करते हैं।

भूमिका एक डिज़ाइन निर्णय है; सेटिंग उसका परिणाम है।

अगर केवल एक प्रोटोकॉल विफल हो

जब अन्यथा काम कर रहे राउटर के पीछे कोई एक प्रोटोकॉल विफल हो, तो पहले उस प्रोटोकॉल का ट्रांसपोर्ट और NAT मार्ग जाँचें। एक क्लाइंट ठीक करने के लिए पूरा गेटवे मोड बदलना वैसा ही है जैसे टूटे बल्ब की वजह से पूरे घर की वायरिंग दोबारा करना। जाँचें कि ट्रैफ़िक UDP में एनकैप्सुलेटेड है या नहीं, राउटर की सहायक सुविधा उस प्रोटोकॉल पर लागू होती है या नहीं, और विफलता सममित है या नहीं। फिर तय करें कि भूमिका बदलना वास्तव में उचित है या नहीं।

RFC 3948 उस UDP एनकैप्सुलेशन का वर्णन करता है जो IPsec को NAT से बचाकर निकालता है, और पास-थ्रू चेकबॉक्स पर भरोसा करने से पहले यही मानक जाँचना चाहिए।

लिख लें कि आपने क्या बदला और क्यों, क्योंकि अगला व्यक्ति डिवाइस को ब्रिज मोड में पाएगा और मान लेगा कि यह जानबूझकर किया गया था। सही परिणाम वह नेटवर्क है जिसका आकार आपने चुना, कोई समस्या-निवारण सत्र से विरासत में मिला नेटवर्क नहीं।

संबंधित लेख