साइट-ते-साइट विरुद्ध रिमोट प्रवेश 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खरा होस्ट, खरा स्रोत पत्ता आणि अनुप्रयोग वापरत असलेला खरा प्रोटोकॉल वापरा. नंतर परतीचा मार्ग वेगळा वाचा, कारण परतीच्या रूटशिवाय काम करणारी पुढची दिशा अवरोधित सेवेसारखाच दिसणारा वेळ संपणे निर्माण करते.
तुम्ही ज्या प्रश्नाचे उत्तर देत आहात त्यानुसार रचना निवडा: तुम्ही नेटवर्क जोडत आहात की उपकरणे स्वीकारत आहात? बाकी सर्व, कोणता पुरवठादार कॉन्फिगर करायचा हेही, त्या उत्तरातून येते.