साइटबाट साइटमा जाने 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 पियरमा सिलेक्टर, रुट र फर्वार्डिङ कसरी अन्तरक्रिया गर्छन् भन्ने व्याख्या गर्छ।