साइट-टू-साइट 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 पीअरवर सिलेक्टर, राउट आणि फॉरवर्डिंग कसे परस्परसंवाद करतात हे स्पष्ट करतात।