ISP राउटर के पास कॉल तोड़े बिना साइट VPN जोड़ें

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

जो भूमिकाएँ पहले से काम करती हैं उन्हें लिखें

डिफ़ॉल्ट गेटवे, DHCP सर्वर, रिज़ॉल्वर और वह उपकरण दर्ज करें जिसके पास प्रदाता का वॉइस पंजीकरण है। इस उदाहरण में ISP राउटर 10.50.0.1 है, नया गेटवे 10.50.0.2 पर होगा और दूर की साइट 10.60.0.0/24 है। उस योजना में कुछ भी पहली तीन भूमिकाएँ नहीं बदलता, और बात ठीक यही है। फिर पुष्टि करें कि दूसरा बॉक्स वाकई आपका टनल समाप्त कर सकता है: प्रोटोकॉल, अपेक्षित थ्रूपुट और यह कि उसे फ़र्मवेयर या पैकेज अपडेट मिलते हैं या नहीं। VPN लोगो वाला और अपडेट मार्ग के बिना उपकरण जोड़ नहीं, बोझ है।

अगर आप यह नहीं बता सकते कि वॉइस सेवा किसकी है, तो रुकें। पंजीकरण वाले राउटर को रोलबैक योजना के बिना बदलना VPN परियोजना को फ़ोन ठप्प में बदल देता है।

नए गेटवे को एक पता और एक काम दें

उसका LAN पता DHCP पूल से बाहर आरक्षित रखें ताकि रीबूट के बाद न हटे, और जब तक उसे इंटरनेट मार्ग न बनाना हो उसे अपना डिफ़ॉल्ट रूट न दें। उसका काम टनल रखना और दूर के प्रीफ़िक्स के लिए उत्तर देना है। जिन LAN होस्ट्स को दूर की साइट तक पहुँचना है, उन पर साबित करें कि वे अब कौन-सा रास्ता लेते हैं और बदलाव के बाद कौन-सा चाहिए; वही दो कमांड पहले और बाद में सबसे सस्ता सबूत हैं।

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

अगर लुकअप ISP राउटर लौटाता है और traceroute इंटरनेट के किनारे मर जाता है, तो होस्ट के पास अभी दूर का रास्ता नहीं है, जो अपेक्षित है। अगर कुछ अनपेक्षित लौटाए, तो पहले उसे सुलझाएँ, क्योंकि हर अगला कदम इसी आधार को मान लेता है।

चुनें कि दूर के प्रीफ़िक्स का रूट किसका है

विकल्प A ISP राउटर है: वह 10.60.0.0/24 के लिए गेटवे की ओर स्थिर रूट रखता है, और हर होस्ट पहले की तरह अपने डिफ़ॉल्ट गेटवे का पालन करता है। विकल्प B प्रति होस्ट है: केवल वे मशीनें जिन्हें दूर की साइट चाहिए, 10.50.0.2 से स्पष्ट रूट पाती हैं, और बाकी सब अछूता रहता है। A कई होस्ट्स के लिए साफ़ है, पर आम तौर पर माँगता है कि प्रदाता का राउटर स्थिर रूट स्वीकार करे, जो कुछ नहीं करते। B को प्रदाता के सहयोग की ज़रूरत नहीं, पर होस्ट कॉन्फ़िगरेशन का रखरखाव आपके पास छोड़ता है, इसलिए यह छोटे अनुमोदित मशीन-समूह के लिए उपयुक्त है।

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

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

प्रविष्टि को होस्ट के कॉन्फ़िगरेशन मालिक के ज़रिए स्थायी बनाएँ, लॉगिन स्क्रिप्ट से नहीं। जो रूट किसी के लॉगिन के बाद ही मौजूद होता है, वह मशीन के किसी असंबंधित कारण से रीबूट होने पर पहली बार विफल होगा।

पहुँचने योग्य इनबाउंड एंडपॉइंट तैयार करें

गेटवे को ऐसा पता चाहिए जहाँ दूर की साइट पहुँच सके। ISP राउटर के पीछे इसका मतलब पोर्ट फ़ॉरवर्डिंग या DMZ प्रविष्टि है, और दोनों इस पर निर्भर हैं कि प्रदाता ट्रैफ़िक वाकई पहुँचाता है। स्थानीय फ़ॉरवर्डिंग प्रदाता की ओर की कैरियर-ग्रेड NAT को पार नहीं कर सकती। अगर प्रदाता पहुँचने योग्य बिंदु न दे, तो दिशा उलट दें: दोनों साइटें आपके नियंत्रित हब की ओर शुरू करें। यह वैध डिज़ाइन है, पर फ़ॉरवर्डिंग, भरोसे और उपलब्धता के लिए तीसरी निर्भरता जोड़ता है, और डायनामिक DNS उसका विकल्प नहीं है।

फ़ॉरवर्डिंग की पुष्टि गेटवे पर कैप्चर से करें, पोर्ट स्कैन करने वाली वेबसाइट से नहीं। स्कैनर तब तक पोर्ट बंद बताते हैं जब तक लिस्नर बँध न जाए, और जो फ़ॉरवर्डिंग कभी ट्रैफ़िक नहीं पहुँचाती वह बाहर से बंद पोर्ट जैसी ही दिखती है।

निजी सेवा और वॉइस लाइन साथ स्वीकारें

LAN होस्ट से इच्छित कामचलाव जाँचें, निजी DNS और ऐप्लिकेशन के अपने क्रेडेंशियल के साथ। रूटेड टनल दूर के ब्राउज़िंग को स्थानीय ईथरनेट सेगमेंट जैसा नहीं बनाता, इसलिए खोज और नाम हल करने की अपनी व्यवस्था चाहिए।

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

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