VPN ले जोडिएका दुई कार्यालयबीचको पहुँच कसरी सीमित गर्ने

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

यही क्रममा काम गर्नुहोस्, र तलका नीति चरणहरू पास नभएसम्म सुरुङको मार्ग फराकिलो नगर्नुहोस्।

गेटवे छुनुअघि म्याट्रिक्स लेख्नुहोस्

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

स्रोतहरूलाई सबनेटको सुविधाअनुसार नभई भूमिकाअनुसार समूहबद्ध गर्नुहोस्: कर्मचारी, अतिथि, प्रशासन। तीनैले एउटै समतल LAN साझा गर्दा गेटवेले नेटवर्क तहमा उनीहरूलाई छुट्याउन सक्दैन, त्यसैले पहिचान नियन्त्रण वा खण्डीकरण पहिले आउनुपर्छ। त्यसपछि प्रत्येक पङ्क्तिमा मालिक र समीक्षा मितिसहित म्याट्रिक्स लिखित रूपमा राख्नुहोस्।

प्याकेट डिक्रिप्ट हुने ठाउँमै लागू गर्नुहोस्

IKE र ESP लाई अनुमति दिने नियमहरूले बाहिरी सुरुङ मात्र बनाउँछन्। भित्री ट्राफिक सुरुङ इन्टरफेसमा खुला रूपमा आउँछ, र अनुमति सूचीको ठाउँ त्यहीँ हो: डिक्रिप्ट गर्ने उपकरणमा फर्वार्डिङ चेन, पूर्वनिर्धारित ड्रप, म्याट्रिक्सको हरेक पङ्क्तिका लागि एउटा नियम। Linux गेटवेमा यसको अर्थ फर्वार्डिङ सक्रिय छ र फिल्टर नियमहरू भौतिक अपलिङ्कमा होइन, सुरुङ उपकरणमा छन् भन्ने हो, जस्तो strongSwan फर्वार्डिङ मार्गदर्शिका ले व्याख्या गर्छ।

ट्राफिक चयनकर्ता राउटिङको निर्णय हुन्, अधिकारको निर्णय होइन। दुवै सबनेट ढाक्ने फराकिलो चयनकर्ता राउटिङका लागि ठीक हुन सक्छ, तर फायरवालले अझै एउटा होस्टतर्फ मात्र TCP 443 लाई अनुमति दिन्छ। चयनकर्ता सुरुङका लागि वार्ता गरिन्छ र त्यसमा के प्रवेश गर्न सक्छ भन्ने वर्णन गर्छ, कुनै उपकरणले के प्रयोग गर्न सक्छ भन्ने होइन। चयनकर्ता फराकिलो छ भनेर कहिल्यै फायरवाल नियम फराकिलो नगर्नुहोस्।

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT र अतिव्यापी सबनेटले नियम बदल्छन्

शाखा गेटवेले सुरुङअघि हरेक होस्टलाई एउटै ठेगानामा अनुवाद गर्दा स्रोत-आधारित हरेक पङ्क्ति त्यही एउटै ठेगानामा खुम्चिन्छ। या त सुरुङ ट्राफिकको अनुवाद रोक्नुहोस्, या नियमहरू अरू कुनै कुरामा, जस्तै अनुवादअघि रेकर्ड गरिएको मूल स्रोत ठेगानामा निर्भर हुनुपर्छ भन्ने स्वीकार गर्नुहोस्। टाढाको छेउलाई पनि त्यही समस्या छ, किनकि गन्तव्य होस्टले मूल होइन, NATपछिको ठेगाना देख्छ।

अतिव्यापी दायरा अर्को जालो हो। दुवैले 192.168.1.0/24 प्रयोग गर्ने दुई कार्यालयलाई एउटा पक्ष म्याप नगरी एउटै नीति तालिकामा वर्णन गर्न सकिँदैन, र म्यापिङ ठोकर नखाने ठेगाना-व्यवस्थाको विकल्प होइन। पछि फुकाल्नुपर्ने नियम लेख्नुअघि योजना सुधार्नुहोस्।

अस्वीकृति प्रमाणित गर्नुहोस्, मात्र सफलता होइन

मात्र अनुमति दिइएको अनुप्रयोग परीक्षण गर्नुले धेरै थोरै प्रमाणित गर्छ, किनकि माथि कतै एउटा ढिलो नियमले उही नतिजा दिन्छ।

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

सूचीलाई जीवित राख्नुहोस्

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

सुरुङपछाडि पनि होस्ट-स्तरीय प्रतिबन्ध महत्त्वपूर्ण छन्: सर्भरको आफ्नै फायरवालले शाखाको दायरा उसले प्रकाशित गर्ने सेवाका लागि मात्र स्वीकार गर्नुपर्छ। मिल्ने दुई तह पूर्ण रूपमा भरोसा गरिएको एउटा तहभन्दा अडिट गर्न सजिलो हुन्छ।