एक VPN क्लाइंट एड्रेस पूल की योजना कैसे बनाएं जो फिट बैठे

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

पूल फ़ील्ड से ही शुरू करें, किसी भी क्लाइंट के जुड़ने से पहले

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

फ़ील्ड मिलने के बाद, पहले से मौजूद रेंजों की सूची बनाएं: ऑफ़िस LAN, हर रूटेड साइट, क्लाउड VPC और सेवा में बचा कोई भी अन्य पूल। ओवरलैप प्रीफ़िक्स अंकगणित से तय होता है, इससे नहीं कि होस्ट नंबर परिचित लगते हैं या नहीं, इसलिए एग्रीगेट की तुलना उन सभी रेंजों से करें। 10.x जैसी दिखने वाली दो रेंजें हानिरहित हैं जब उनके एग्रीगेट एक-दूसरे को नहीं काटते और सपोर्ट घटना हैं जब काटते हैं।

फिर तय करें कि पता इस बात का फलन है कि कौन जुड़ता है या कि वे कब जुड़ते हैं। गतिशील आवंटन जो मुक्त है वह देता है, जबकि पहचान-आधारित आवंटन एक निश्चित पते को क्रेडेंशियल से बांधता है। चयन लिख लें, क्योंकि यह बदलता है कि बाद में पुनः कनेक्शन कैसा दिखना चाहिए।

वह पता पढ़ें जो क्लाइंट को वास्तव में मिला

एक क्लाइंट जोड़ें और पढ़ें कि टनल क्या बताता है, न कि पूल ने क्या वादा किया था। क्लाइंट कनेक्शन स्थिति में अपना आंतरिक पता दिखाता है, और Linux पर इंटरफ़ेस उसे सीधे रखता है।

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

ip -4 addr show tun0
ip route get 192.168.50.20

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

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

सेवा से जवाब को वापस ट्रैक करें

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

अनुवाद बदल देता है कि बाकी सिस्टम क्या देखता है। जब स्रोत फिर से लिखा जाता है, होस्ट फ़ायरवॉल में और एप्लिकेशन लॉग में जो पता है वह अनूदित है, इसलिए पूल पते के विरुद्ध लिखा नियम किसी से मेल नहीं खाता और लॉग की पंक्ति किसी क्लाइंट तक ट्रेस नहीं की जा सकती। strongSwan का फ़ॉरवर्डिंग दस्तावेज़ IKEv2 गेटवे के लिए उस रास्ते का सर्वर-साइड आधा हिस्सा शामिल करता है। DNS भी वही बाधा लिए है, क्योंकि ऐसे पते पर हल होने वाला नाम जहां क्लाइंट पहुंच नहीं सकता, बाद में और कहीं और विफल होता है।

दो क्लाइंट, फिर एक निरस्तीकरण

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

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

ऐसे गंतव्य के साथ समाप्त करें जिसे अस्वीकार किया जाना चाहिए। जो क्लाइंट हर जगह पहुंचता है उसे जोड़ा गया है, परखा नहीं गया।

चारों मान वहीं लिखें जहां अगला परिवर्तन उन्हें पाएगा

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

उसके साथ स्वामित्व वाली टिप्पणी रखें: टनल रेंज VPN सर्वर की है, और LAN DHCP दायरे में किया गया आरक्षण टनल के भीतर के क्लाइंट के लिए कुछ आरक्षित नहीं करता। वही एक पंक्ति सबसे आम दोबारा काम रोकती है, जहां कोई आरक्षण जोड़ता है और अपेक्षा करता है कि टनल का पता उसका अनुसरण करेगा।