ब्रिज मोड VPN पासथ्रु होइन: प्रत्येकले के बदल्छ
ब्रिज मोडले राउटरको फर्वार्डिङ भूमिका बदल्छ; पासथ्रुले क्लाइन्टको VPN लाई मात्र त्यसमार्फत जान दिन्छ। दुवैले टनेल बनाउँदैनन्, त्यसैले ती अदलबदल गर्न सकिँदैन।
ब्रिज मोड र VPN पासथ्रु एउटै समस्या समाधान छलफलमा आउँछन् किनभने दुवैलाई जोडिन नसकेको VPN को उपायका रूपमा सुझाइन्छ। ती राउटरका फरक-फरक कार्य वर्णन गर्छन्, र कुनैले पनि आफैँ VPN टनेल बनाउँदैन। ब्रिजिङले उपकरणले नेटवर्क खण्डमा कसरी सहभागी हुन्छ वा राउटिङ कसले गर्छ भन्ने बदल्छ; पासथ्रुले क्लाइन्टको VPN ट्राफिक गेटवे पार गर्न सक्छ कि सक्दैन भन्ने निर्णय गर्छ। गलत छनोटले सानो समस्यालाई दिउँसोभरि ठेगाना पुनः तोक्ने काममा परिणत गर्छ।
दुई लेबल, दुई फरक कार्य
परीक्षण सरल छ: तपाईँ नेटवर्कको आकार बदल्न खोज्दै हुनुहुन्छ, वा पहिले नै रहेको ट्राफिकलाई त्यसमार्फत जान दिन खोज्दै? ती फरक अनुरोध हुन् र तिनका परिणाम पनि फरक हुन्छन्।
एउटै तालिकामा तुलना:
| Setting | What it actually does |
|---|---|
| Bridge mode | Changes the device's forwarding role: a modem bridge hands routing and NAT downstream, a software bridge joins selected interfaces |
| VPN pass-through | Lets a client's VPN traffic cross the router; the credentials and encryption stay with the client |
| Router VPN client | Terminates the tunnel on the router, so the router becomes the endpoint |
| Router VPN server | Accepts inbound tunnels, which needs an upstream path that can reach it |
अन्तिम दुईले मात्र राउटरमा टनेल बनाउँछन्। ब्रिजिङ र पासथ्रु दुवैले अन्त्य बिन्दु अन्तै छोड्छन्, त्यसैले हराएको क्लाइन्ट वा पुग्न नसकिने सर्भरका कारण भएको समस्या ती कुनैले पनि समाधान गर्न सक्दैनन्। यो भिन्नता हराउन सजिलो छ किनभने सेटिङहरू एउटै इन्टरफेसमा नजिकै बस्छन्। त्यो पृष्ठ खोल्नुअघि टनेल कुन अन्त्य बिन्दुको हो लेख्नुहोस्।
पासथ्रु चेकबक्स पनि प्रोटोकल समर्थनको पूर्ण विवरण होइन। आधुनिक IPsec NAT ट्राभर्सलले मानकीकृत UDP इन्क्याप्सुलेसन प्रयोग गर्छ, जबकि पुराना सहायक सुविधाको व्यवहार कार्यान्वयनअनुसार फरक हुन्छ।
VPN समर्थन छ भन्ने मार्केटिङ लेबलले यी चारमध्ये कुन भूमिका भन्ने बताउँदैन।
ब्रिज मोडले तपाईँको उपकरणमा के बदल्छ
मोडेम वा राउटरमा ब्रिज विकल्पले प्रायः राउटिङ र NAT को जिम्मेवारी तल्लो गेटवेमा सार्छ। सफ्टवेयर उपकरणमा यसको अर्थ छानिएका स्थानीय इन्टरफेसलाई एउटै ब्रोडकास्ट डोमेनमा जोड्नु हुन सक्छ। ठ्याक्कै दायरा उत्पादनमा निर्भर हुन्छ, त्यसैले शब्दको नभई त्यो मोडेलको कागजात पढ्नुहोस्। दुवै व्याख्याले ठेगाना तोकाइ, फायरवाल सीमा र प्रशासनमा कसरी पुग्ने भन्ने बदल्छ।
त्यही भएर VPN असफल हुँदा ब्रिजिङ पहिलो प्रतिक्रियाका रूपमा खराब हुन्छ। मूल समस्या समाधान नभएसम्म तपाईँको व्यवस्थापन मार्ग गुम्न सक्छ।
नेटवर्क भूमिका बदल्नुअघि कन्फिगरेसनको ब्याकअप राख्नुहोस्, किनभने ठेगाना त्यसैसँग सर्न सक्छ।
सेटिङभन्दा पहिले भूमिका छान्नुहोस्
घरायसी ट्राफिक बाहिरी निकासबाट पठाउन तपाईँलाई राउटरमा मिल्ने VPN क्लाइन्ट चाहिन्छ, ब्रिज होइन। अन्तैबाट घर फर्केर जोडिन तपाईँलाई सर्भर भूमिका र त्यहाँसम्म पुग्ने माथिल्लो मार्ग चाहिन्छ। VPN शब्दबाहेक ती दुई आवश्यकतामा लगभग केही समान छैन। मेनु हेर्नुअघि तपाईँ कुन बनाउँदै हुनुहुन्छ निर्णय गर्नुहोस्।
उपकरणले दुवै भूमिका समर्थन गर्न सक्छ र तैपनि तपाईँलाई अपेक्षित गतिमा चाहिने भूमिका समर्थन नगर्न सक्छ।
भूमिका डिजाइन निर्णय हो; सेटिङ त्यसको परिणाम हो।
यदि एउटा मात्र प्रोटोकल असफल हुन्छ
अन्यथा काम गरिरहेको राउटरपछाडि एउटा प्रोटोकल असफल हुँदा पहिले त्यो प्रोटोकलको ढुवानी र NAT मार्ग जाँच्नुहोस्। एउटा क्लाइन्ट ठीक गर्न सम्पूर्ण गेटवे मोड बदल्नु बत्ती बिग्रिएर घरको तार बदल्नुजस्तै हो। ट्राफिक UDP-इन्क्याप्सुलेटेड छ कि, राउटरको सहायक सुविधा त्यो प्रोटोकलमा लागू हुन्छ कि, र असफलता सममित छ कि जाँच्नुहोस्। त्यसपछि भूमिका परिवर्तन साँच्चै आवश्यक छ कि निर्णय गर्नुहोस्।
RFC 3948 ले IPsec लाई NAT मा टिकाउने UDP इन्क्याप्सुलेसन वर्णन गर्छ, र पासथ्रु चेकबक्समा विश्वास गर्नुअघि जाँच्नुपर्ने मानक त्यही हो।
तपाईँले के बदल्नुभयो र किन लेख्नुहोस्, किनभने अर्को व्यक्तिले उपकरण ब्रिज मोडमा भेट्टाउनेछ र जानाजान गरिएको हो भनी मान्नेछ। सही परिणाम भनेको तपाईँले छानेको आकारको नेटवर्क हो, समस्या समाधान सत्रबाट पाइएको होइन।