साइट-देखि-साइट वा रिमोट पहुँच VPN: दुवैले के जोड्छन्
एउटाले गेटवे जोड्छ, अर्कोले यन्त्रहरू जोड्छ। ट्राफिक चयनकर्तालाई रुटसँग तुलना गर्नुहोस्, ठेगाना योजना बनाउनुहोस्, त्यसपछि वास्तविक होस्टबाट फर्वार्डिङ र नीति परीक्षण गर्नुहोस्।
दुवै डिजाइनलाई VPN भनिन्छ र तिनीहरूले फरक समस्या समाधान गर्छन्। साइट-देखि-साइट टनेलले दुई गेटवे जोड्छ, त्यसैले तिनीहरूको पछाडिको हरेक होस्टले केही पनि स्थापना नगरी अर्को छेउको अनुमत ठेगानामा पुग्न सक्छ। रिमोट-पहुँच टनेलले व्यक्तिगत यन्त्रहरूलाई सञ्जालसँग जोड्छ, एक पटकमा एउटा क्लाइन्ट। यो तुलना महत्त्वपूर्ण छ किनकि अधिकांश तैनाती त्रुटिहरू एउटा कन्फिगर गरेर अर्कोको व्यवहार अपेक्षा गर्दा हुन्छन्, र लक्षण सामान्यतया टनेलले साँच्चै पुगेको सेवामा समय सकिनु हो।
दुई डिजाइन, दुई सीमा
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
कुनै पनि डिजाइनले LAN प्रसारण डोमेन विस्तार गर्दैन। टाढाको छेउका यन्त्रहरू स्थानीय खोज सूचीमा देखिँदैनन्, र त्यस्तो अपेक्षा गर्नु छोड्नुपर्ने पहिलो मान्यता हो। तपाईंले जानाजानी प्रकाशित गर्नुभएका निजी DNS नामहरू कुनै पनि खोज प्रोटोकलभन्दा बढी अनुमानयोग्य हुन्छन्, र आपूर्तिकर्ता बदलिँदा पनि टिकिरहन्छन्।
एउटा साइटमा 10.10.0.0/24 र अर्कोमा 10.20.0.0/24 लिनुहोस्। गेटवे A लाई 10.20.0.0/24 प्रिफिक्स टनेलमा पठाउने रुट वा ट्राफिक चयनकर्ता चाहिन्छ, र गेटवे B लाई त्यसको ऐनाजस्तो प्रतिबिम्ब चाहिन्छ। त्यसपछि दुवै छेउका होस्टहरूले सामान्य IP जडान प्रयोग गर्छन् र टनेल छ भन्ने कहिल्यै थाहा पाउँदैनन्। त्यो अदृश्यता नै विशेषता हो, र विफलताहरू टनेलका त्रुटिजस्तो नभई सामान्य सञ्जाल त्रुटिजस्तो देखिनुको कारण पनि त्यही हो।
नीति-आधारित र रुट-आधारित एउटै टनेल होइन
नीति-आधारित IPsec तैनातीमा, वार्ता गरिएका ट्राफिक चयनकर्ताले कुन स्रोत र गन्तव्य जोडी सुरक्षित छन् भन्ने ठ्याक्कै निर्धारण गर्छन्। यदि एउटा गेटवेको पछाडि नयाँ सबनेट देखा पर्यो र कुनै चयनकर्ताले त्यसलाई समेटेन भने, टनेल चलिरहन्छ र नयाँ सबनेट केवल बोकिँदैन। रुट-आधारित डिजाइनमा इन्टरफेसले ट्राफिक लिन्छ र रुटिङ तालिकाले निर्णय गर्छ, जसले प्रिफिक्स थप्ने कामलाई टनेलको पुनर्वार्ता नभई रुट परिवर्तन बनाउँछ।
StrongSwan दुवै दृष्टिकोण सिधै देखाउँछ, र तिनीहरूलाई सँगै पढ्नु भनेको तपाईंले वास्तवमा कुन मोडेल तैनात गर्नुभयो भन्ने थाहा पाउने बाटो हो।
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'तपाईंलाई आवश्यक प्रिफिक्स छुटेको चयनकर्ता सूचीले कुनै प्याकेट क्याप्चरबिना विफलता बुझाउँछ, र गलत इन्टरफेसमा देखाउने रुटले फर्कने बाटोको ऐनाजस्तो विफलता बुझाउँछ। केही पनि पुनर्वार्ता गर्नुअघि दुवै पढ्नुहोस्, किनकि कुञ्जी नवीकरणले तपाईंले कहिल्यै कन्फिगर नगरेको चयनकर्ता थप्दैन।
टनेलअघि ठेगाना योजना बनाउनुहोस्
अतिव्यापी दायराहरू त्यो डिजाइन त्रुटि हो जुन कन्फिगरेसनले सुधार्न सकिँदैन। यदि दुवै साइटले 192.168.1.0/24 प्रयोग गर्छन् भने, 192.168.1.50 चाहिने होस्टसँग दुई उम्मेदवार हुन्छन् र छान्ने कुनै बाटो हुँदैन। टनेलले प्रमाणीकरण गर्नेछ, सुरक्षा सहयोगहरू स्थापित हुनेछन्, र रुटिङ निर्णय तैपनि गलत वा अस्पष्ट रहनेछ।
तीन इमानदार विकल्पमध्ये एउटा छान्नुहोस्: एउटा साइट पुनःक्रमांकन गर्नुहोस्, गेटवेमा अतिव्यापी दायरा अनुवाद गर्नुहोस् ताकि हरेक पक्षले फरक प्रिफिक्स देखोस्, वा ती होस्टहरूका लागि सिधा रुटिङ छोडेर सेवा अर्को तरिकाले प्रकाशित गर्नुहोस्। प्रत्येकको लागत छ, र दुई वर्षको क्षितिजमा पहिलो सामान्यतया सबैभन्दा सस्तो हुन्छ। टनेल अस्तित्वमा आउनुअघि निर्णय गर्नुहोस्, किनकि पछि त्यो परिवर्तन पुरानो ठेगाना भएको हरेक यन्त्रलाई छुन्छ।
MTU प्रश्न पनि चाँडै समाधान गर्नुहोस्। टनेलले उपयोगी पेलोड घटाउँछ, र खण्डीकरणमा भर पर्ने डिजाइन गेटवेमा MSS स्थिर गर्ने डिजाइनभन्दा फरक व्यवहार गर्छ।
फर्वार्डिङ र नीति टनेलबाहिर हुन्छन्
गेटवेले टनेल इन्टरफेस र LAN इन्टरफेसबीच प्याकेट फर्वार्ड गर्न तयार हुनुपर्छ, र दुवै दिशालाई सेवालाई अनुमति दिने नीति चाहिन्छ। Linux मा यी दुई छुट्टै सेटिङ हुन्, साथै फर्वार्ड भएको प्रवाह नै अनुमत छ कि छैन भनी निर्धारण गर्ने फायरवाल नियमहरू।
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTप्राप्त गर्ने होस्टले तेस्रो तह थप्छ: उसको आफ्नै फायरवालले अझै टाढाको सबनेटबाट क्लाइन्ट स्वीकार गर्नुपर्छ। आफ्नो स्थानीय /24 मात्र अनुमति दिने फाइल सर्भरले टनेल जतिसुकै स्वस्थ देखिए पनि 10.20.0.7 बाट फर्वार्ड भएको ट्राफिक अस्वीकार गर्नेछ, र त्यो अस्वीकारलाई रुटिङ विफलता भनी पढ्न सजिलो छ।
गेटवेबाट होइन, होस्टबाट परीक्षण गर्नुहोस्
गेटवे आफैले पठाएको ping ले फर्वार्ड हुने प्रयोगकर्ता ट्राफिकभन्दा फरक स्रोत ठेगाना र फरक नीति पछ्याउन सक्छ। त्यसले यसलाई कमजोर परीक्षण बनाउँछ र कहिलेकाहीँ भ्रमित गर्ने पनि: अनुप्रयोग असफल हुँदा यो सफल हुन्छ, वा अनुप्रयोग चलिरहेको बेला यो असफल हुन्छ।
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullवास्तविक होस्ट, वास्तविक स्रोत ठेगाना र अनुप्रयोगले प्रयोग गर्ने वास्तविक प्रोटोकल प्रयोग गर्नुहोस्। त्यसपछि फर्कने बाटो छुट्टै पढ्नुहोस्, किनकि फर्कने रुटबिना चल्ने अगाडिको दिशाले अवरुद्ध सेवाजस्तै देखिने समय सकिने उत्पन्न गर्छ।
तपाईंले उत्तर दिइरहनुभएको प्रश्नअनुसार डिजाइन छान्नुहोस्: तपाईं सञ्जाल जोड्दै हुनुहुन्छ वा यन्त्र स्वीकार्दै? बाँकी सबै, कुन आपूर्तिकर्ता कन्फिगर गर्ने पनि, त्यही उत्तरबाट आउँछ।