Windows VPN गेटवे: तीन काम, तीन मालिक

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

पठनीय डिज़ाइन मशीन को भूमिका के रूप में वर्णित करने के बजाय हर प्रवाह के मालिक का नाम लेता है।

समाप्त करें, फ़ॉरवर्ड करें, रूपांतरित करें

RRAS Windows के मूल मामले में टनल सँभालता है: उपयोगकर्ता को प्रमाणित करता है, पूल से पता देता है और तय करता है कि कौन-से गंतव्य अनुमत हैं। कोई दूसरा VPN उत्पाद इसके बजाय श्रोता और वर्चुअल अडैप्टर रख सकता है, और डिक्रिप्ट किए गए पैकेट फ़ॉरवर्ड करने का काम Windows को छोड़ सकता है। Microsoft का Remote Access दस्तावेज़ VPN, साइट-से-साइट और रूटिंग भूमिकाओं को अलग करता है, और रूटिंग भूमिका स्थापित करने से दूसरी VPN पहचान नहीं बनती। दूसरा VPN अनुप्रयोग जोड़ना भी उसके अडैप्टर को हर मौजूदा गेटवे सुविधा को नहीं देता।

रूपांतरण तीसरा और सबसे वैकल्पिक काम है। यह फ़ॉरवर्डिंग के बाद आता है और दूरस्थ नेटवर्क को दिखने वाला स्रोत पता बदलता है। इसकी ज़रूरत आपको है या नहीं, यह इस पर निर्भर है कि गंतव्य नेटवर्क स्रोत के रूप में क्या स्वीकार करेगा, इस पर नहीं कि मशीन को VPN गेटवे कहा जाता है।

अडैप्टर और पूल का मालिक कौन है

जब कई उत्पाद मेज़बान साझा करते हैं, चार चीज़ों को हर एक के लिए एक ही मालिक चाहिए: सुनने के पोर्ट, अडैप्टर का जीवनकाल, क्लाइंट पता पूल और रूट। अडैप्टर सबसे मुश्किल है, क्योंकि VPN सेवा इसे गतिशील रूप से बना सकती है और डिस्कनेक्ट पर नष्ट कर सकती है। उस इंटरफ़ेस को स्थायी रूप से नामित नेटवर्क कार्ड मानना और उसके नाम के विरुद्ध नियम लिखना अगली पुनःकनेक्शन तक काम करता है। इंटरफ़ेस का नाम हार्डकोड करने के बजाय उत्पाद के समर्थित एकीकरण बिंदु का उपयोग करें।

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

स्रोत बचाएँ या फिर से लिखें

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

निजी नेटवर्क तक पहुँच, इंटरनेट निकास और गेटवे पर ही समाप्त होने वाले कनेक्शन तीन अलग रास्ते हैं। सबको एक जैसा व्यवहार नहीं चाहिए।

प्रवाह को एक वाक्य में बताएँ

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

कॉन्फ़िगरेशन के पास भूमिकाओं की सूची रखें: कौन-सा उत्पाद समाप्त करता है, कौन-सा फ़ॉरवर्ड करता है, कौन-सा रूपांतरित करता है और हर एक को कौन बदल सकता है। वही सूची अगले बदलाव को समीक्षा-योग्य बनाती है।

जब वाक्य अस्पष्ट हो जाता है, तो एक और रूपांतरण परत जोड़ने से वह शायद ही स्पष्ट होता है। एक हटाने से आम तौर पर होता है।