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 उपयोग करते हैं, उन्हें एक पक्ष का मैपिंग किए बिना एक नीति तालिका में नहीं बताया जा सकता, और मैपिंग टकराव-रहित पता-निर्धारण का विकल्प नहीं है। बाद में खोलने पड़ने वाले नियम लिखने से पहले योजना सुधारें।

अस्वीकृति साबित करें, केवल सफलता नहीं

केवल अनुमत एप्लिकेशन का परीक्षण बहुत कम साबित करता है, क्योंकि ऊपर कहीं एक ढीला नियम वही परिणाम देता है।

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

सूची को जीवित रखें

एप्लिकेशन बदलते हैं, और अपने एप्लिकेशन से अधिक जीने वाला नियम ऐसा छेद बन जाता है जिसका कोई स्वामी नहीं। समीक्षा तिथि पंक्ति से जोड़ें, और जब सेवा पता बदले तो उसी रखरखाव चरण में चयनकर्ता का दायरा और फ़ायरवॉल नियम बदलें।

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