साइट-से-साइट VPN के लिए क्या दर्ज करें: सिलेक्टर और दायरा

टनल चालू होने के छह महीने बाद एक नया सबनेट नीति से मेल खाना बंद कर देता है और शेयर पर मौजूद अकेला दस्तावेज़ कहता है ऑफ़िस VPN। यही वह विफलता है जिसे सिलेक्टर रिकॉर्ड रोकता है, और यह ठोस है: पते का एक समूह बदल गया जबकि कागज़ात नहीं बदले। रिकॉर्ड सही तरीके से लिखने का मतलब है यह जानना कि आप कई पता समूहों में से किसका वर्णन कर रहे हैं, और वही दर्ज करना जिसे सामने वाला पक्ष वास्तव में लागू करता है, न कि वह जिसे आपने कॉन्फ़िगर किया।

कॉन्फ़िगर किया गया बातचीत में तय नहीं है

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

दोनों कॉलम रखें, उस तारीख के साथ जब आपने उन्हें देखा था। कॉन्फ़िगर किया गया सिलेक्टर वह है जो आपका इरादा था; बातचीत में तय किया गया वह है जो कर्नेल अभी लागू कर रहा है। जब वे अलग होते हैं, तो यह अंतर रूटिंग की गड़बड़ी की तुलना में कहीं अधिक बार चौंकाने वाली विफलता की व्याख्या करता है।

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

रूट-आधारित टनल अलग तरीके से चुनती हैं

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

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

अनुवाद उसी तालिका में आता है

जब NAT सामने वाले पक्ष को अलग श्रेणी दिखाता है, तो मूल और अनुवादित प्रीफ़िक्स साथ दर्ज करें। वह चरण नोट करें जिस पर सिलेक्टर और एक्सेस नियम उनसे मेल खाते हैं, क्योंकि क्रम तय करता है कि दूर वाला पक्ष आपके लिखे पते को कभी देखेगा या नहीं। दोनों में से केवल एक श्रेणी वाली तालिका तालिका न होने से बुरी है, क्योंकि वह पूरी लगती है।

यही वह ब्यौरा है जो NAT बदलाव के बाद चलती हुई टनल को तोड़ता है: सिलेक्टर अब भी मूल प्रीफ़िक्स से मेल खाता है, सामने वाले पक्ष को अब अनुवादित प्रीफ़िक्स मिलता है, और उसका वापसी रूट ऐसे पते की ओर इशारा करता है जो अब मौजूद नहीं है। जिस पल दोनों मेल खाना बंद करते हैं, उस पल कोई त्रुटि दर्ज नहीं करता।

निजी DNS उसी जगह आता है। ऐसा नाम जो संबंधित साइट से अनुपयोगी पते पर हल होता है, सहायता टिकट के साथ जुड़ी दस्तावेज़ी गलती है, और उसका दोष टनल पर डाला जाएगा।

सेवा की आवश्यकता जोड़ें

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

फिर उस नेटवर्क प्रशासक का नाम लिखें जो नियम बनाए रखता है। मालिक के बिना सिलेक्टर सूची चुपचाप पुरानी हो जाती है, और रात दो बजे टनल टूटने पर पुरानी को गलत से अलग नहीं किया जा सकता। मालिक वह व्यक्ति भी है जो पुष्टि कर सकता है कि बदलाव जानबूझकर था।

रिकॉर्ड को परीक्षण योजना बनाएँ

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

swanctl --list-sas

पाँच पंक्तियों का ढाँचा आम तौर पर रिकॉर्ड को ईमानदार रखने के लिए पर्याप्त है। नीचे दिया संस्करण बिना काटे बदलाव टिकट में आ जाता है:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

केवल गेटवे तक पिंग स्वीकृति परीक्षण नहीं है। यह कभी पारगमन पथ का अभ्यास नहीं करता, इसलिए यह तब भी पास हो सकता है जब हर अग्रेषित प्रवाह विफल हो। एक ओर के होस्ट से दूसरी ओर की सेवा तक परीक्षण करें और पुष्टि करें कि उत्तर टनल से होकर आता है। यदि केवल पिंग पास होता है, तो रिकॉर्ड ने अभी-अभी वही अग्रेषण समस्या पकड़ी है जिसे रोकने के लिए वह लिखा गया था। strongSwan अग्रेषण दस्तावेज़ बताता है कि सिलेक्टर, रूट और अग्रेषण Linux साथी पर कैसे परस्पर क्रिया करते हैं।