VPN को समर्पित ठेगानामा वास्तवमा कसले जवाफ दिन्छ?

संस्थाको बाँडफाँटमा प्रयोग नगरी परेको ठेगाना श्रोता होइन, र त्यसलाई फायरवालमा थप्दा एउटा पनि बन्दैन। त्यो ठेगानामा IKE अन्त्य गर्न केही चाहिन्छ, र गेटवे आफै ठेगानाको स्वामित्व राख्छ कि अपस्ट्रिम उपकरणले यसको अनुवाद गर्छ भन्नेमा कार्यविधि फरक पर्छ। प्याकेटको मार्गले नै दुवैलाई छुट्याउँछ, र कसैले परिवर्तन अनुरोध खोल्नुअघि तपाईंलाई कुन प्लेटफर्म सुविधा चाहिन्छ भन्ने पनि त्यही मार्गले निर्धारण गर्छ। पहिले मार्गको नमुना बनाउनुहोस्, त्यसपछि छान्नुहोस्।

ठेगाना पछाडिको प्याकेट मार्ग

सहभागीले आफूलाई दिइएको ठेगानामा IKE पठाउँछ, UDP 500 मा वा NAT यात्रा संलग्न हुँदा UDP 4500 मा। मार्गमा त्यो ठेगाना राख्ने जुनसुकै उपकरणले डेटाग्राम स्थानीय रूपमा स्वीकार गरी जवाफ दिन्छ, वा त्यसलाई अन्तै पठाउँछ। यी केवल दुई सम्भावना हुन्, र यस लेखको बाँकी सबै तीमध्ये कुन सत्य हो भन्नेबाट आउँछ।

स्थानीय रूपमा स्वीकार गर्नु भन्नाले त्यो उपकरणमा त्यो ठेगानासँग बाँधिएको सकेट छ भन्ने हो। पठाउनु भन्नाले डेटाग्राम पुनः लेखिएर अर्को अन्त्यबिन्दुमा पठाइन्छ, र त्यसपछि सकेट त्यहाँ हुन्छ। UDP 500 लाई अनुमति दिने फायरवाल नियमले यी दुईमध्ये कुन भइरहेको छ भनी तपाईंलाई केही बताउँदैन।

केही छुनुअघि अभिलेख लेख्नुहोस्: सहभागीहरूले सम्पर्क गर्ने ठेगाना, माथिल्लो सञ्जालले त्यो कसरी पुर्‍याउँछ, त्यो स्वीकार गर्ने स्थानीय इन्टरफेस वा तार्किक अन्त्यबिन्दु, र IKE लाई जवाफ दिने प्रक्रिया। चार लाइन, र प्रत्येक जाँच्न सकिन्छ। तिनमध्ये एक अज्ञात भए, त्यो अज्ञात नै डिजाइनको काम हो, पछि टुंग्याउने कार्यान्वयन विवरण होइन। परिवर्तन अनुरोध स्वीकृत भएपछि ती भर्नु नै गलत उपकरणमा अनुवाद नियम थपिने बाटो हो।

नमुना A: गेटवे ठेगानाको स्वामी हो

पहिलो नमुनामा गेटवे आफै ठेगाना राख्छ, विद्यमान इन्टरफेसमा दोस्रो ठेगानाका रूपमा, समर्पित इन्टरफेसमा ठेगानाका रूपमा, वा प्लेटफर्मले सुरुङ अन्त्यबिन्दुका रूपमा समर्थन गर्ने loopback का रूपमा। यी तीन फरक सुविधा हुन् तीन फरक कन्फिगरेसन मार्गसहित, र एउटालाई समर्थन गर्ने प्लेटफर्मले अरूलाई नगर्न सक्छ।

यसको वरिपरि डिजाइन गर्नुअघि प्लेटफर्म र संस्करणले ठ्याक्कै यही मिलानलाई समर्थन गर्छ भनी पुष्टि गर्नुहोस्। रुट गरिएको ब्लक, इन्टरफेसमा थप ठेगाना र loopback अन्त्यबिन्दु आपसमा साट्न मिल्दैन, र एउटा संस्करणको कागजातले अर्कोले पनि त्यही व्यवहार गर्ने वाचा गर्दैन।

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

सुनिरहेको सकेट नै प्रमाण हो। ठेगानासँग केही बाँधिएको छैन भने रुटिङ तालिका जे भने पनि गेटवे अन्त्य गर्ने होइन, र प्याकेट क्याप्चरले डेटाग्राम आइरहेका छन् तर जवाफ दिने कोही छैन भनी देखाउँछ।

टोपोलोजीमा अन्तै पहिले नै रहेको सबनेटमा दोस्रो इन्टरफेस नराख्नुहोस् र प्लेटफर्मले मिलाउँछ भनी नमान्नुहोस्। ओभरल्याप हुने इन्टरफेस सबनेटले अस्पष्ट स्रोत छनोट उत्पन्न गर्छ र धेरै प्लेटफर्ममा कन्फिगर गर्नैबाट पूर्ण इन्कार गर्छ।

नमुना B: अपस्ट्रिम उपकरणले यसको अनुवाद गर्छ

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

तर त्यो अपस्ट्रिम उपकरणले स्थानीय VPN सकेट पाएको प्रमाण भने होइन। अनुवादले प्याकेट पठाउँछ; यसले माथिल्लो बाकसलाई IKE उत्तरदाता बनाउँदैन। माथिल्लो नियम हटाइयो वा यसको फिर्ती मार्ग टुट्यो भने, गेटवे स्वस्थ र यसका आफ्नै श्रोता अक्षत भए पनि VPN रोकिन्छ।

दुवै ठेगाना अभिलेख गर्नुहोस्: सहभागीहरूले सम्पर्क गर्ने र गेटवेले वास्तवमा देख्ने। त्यसपछि यातायात र फिर्ती मार्ग अभिलेख गर्नुहोस्, किनभने UDP 500 का लागि काम गर्ने तर इन्क्याप्सुलेटेड ESP का लागि नगर्ने अनुवाद जोडिन्छ र त्यसपछि ट्राफिक बोक्न असफल हुन्छ, जो पछि डिबग गर्न अलमल्याउने असफलता हो।

पहिचान बाहिरी ठेगाना होइन

IPsec ले सुरुङ अन्त्यबिन्दुलाई यसले सुरक्षा गर्ने ट्राफिकबाट छुट्याउँछ, र संरचना ती निर्णयहरू फरक फरक ठाउँमा राख्छ। सहभागीहरूले सम्पर्क गर्ने ठेगाना बदल्दा कुन आन्तरिक प्रिफिक्सलाई अनुमति छ, कुन रुट स्थापना हुन्छन् वा सत्र कुन स्रोतसम्म पुग्न सक्छ भन्ने स्वतः बदलिँदैन।

प्रमाणित पहिचान फेरि अलग छ। IKEv2 ले बाहिरी प्याकेट ठेगानासँग मिल्नु नपर्ने पहिचान पेलोड र प्रमाणीकरण आदानप्रदान बोक्छ, र त्यसै कारण अनुदित डिजाइनले पनि सही रूपमा प्रमाणीकरण गर्न सक्छ।

त्यो स्वतन्त्रता उपयोगी छ र सँगै फन्दा पनि। एउटा साधारण श्रोतामा समाधान हुने दुई DNS नामले फरक VPN ब्याकएन्ड छान्दैनन्, र एउटा पहिचानको नाम राख्ने प्रमाणपत्रले अर्को अपेक्षा गर्ने सहभागीलाई सन्तुष्ट पार्दैन। ठेगाना मात्रले यो निर्धारण गर्छ भनी मान्नुअघि सहभागीले के प्रमाणित गर्छ त्यो पुष्टि गर्नुहोस्।

एउटा जडान हेरेर डिजाइन स्वीकार गर्नुहोस्

नयाँ अधिकृत जडान वास्तवमा कहाँ पुर्‍याइन्छ, कुन पहिचानले जवाफ दिन्छ र त्यसपछि कुन निजी प्रवाहलाई अनुमति दिइन्छ त्यो जाँच्नुहोस्। तीन अवलोकन, तीन फरक तह, र ठेगानाको सफल सार्वजनिक खोजीले तीमध्ये एउटै जाँच्दैन।

नकारात्मक अवस्था पनि राख्नुहोस्: स्वीकार गर्न नहुने सहभागी, वा पुग्न नहुने आन्तरिक प्रिफिक्स, परिवर्तनपछि प्रमाणित गरिएको। सुरुमा लेखिएको अभिलेख नै स्मृतिबाट डिजाइन पुनर्निर्माण नगरी त्यो परीक्षण सम्भव बनाउँछ।

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