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 वापरणाऱ्या दोन कार्यालयांचे एक बाजू मॅप न करता एका धोरण तक्त्यात वर्णन करता येत नाही, आणि मॅपिंग टक्कर न होणाऱ्या पत्ता-रचनेचा पर्याय नाही। नंतर सोडवाव्या लागणाऱ्या नियमांच्या आधी योजना दुरुस्त करा।

नकार सिद्ध करा, फक्त यश नाही

फक्त परवानगी असलेल्या अनुप्रयोगाची चाचणी फार कमी सिद्ध करते, कारण वर कुठेतरी सोडक्या नियमामुळे तोच निकाल मिळतो।

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

यादी जिवंत ठेवा

अनुप्रयोग हलतात, आणि स्वतःच्या अनुप्रयोगापेक्षा जास्त जगणारा नियम असा भोका बनतो ज्याचा कोणी मालक नाही। पुनरावलोकन तारीख ओळीला जोडा, आणि सेवा पत्ता बदलल्यास त्याच देखभाल टप्प्यात निवडकाची व्याप्ती आणि फायरवॉल नियम बदला।

बोगद्यामागेही होस्ट-स्तरीय निर्बंध महत्त्वाचे आहेत: सर्व्हरचा स्वतःचा फायरवॉल शाखा श्रेणी फक्त तो प्रकाशित करत असलेल्या सेवेसाठी स्वीकारावा। जुळणारे दोन स्तर पूर्णपणे विश्वास ठेवलेल्या एका स्तरापेक्षा तपासणे सोपे आहे।