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 क्षेत्रमा गरिएको आरक्षण सुरुङभित्रको ग्राहकका लागि केही पनि आरक्षित गर्दैन। त्यो एउटै लाइनले सबैभन्दा सामान्य पुनःकाम रोक्छ, जहाँ कसैले आरक्षण थप्छ र सुरुङको ठेगाना त्यसलाई पछ्याउने अपेक्षा गर्छ।

सम्बन्धित लेखहरू