साइट-ते-साइट VPN: नक्की कोणत्या दिशेला नियम हवा?

दोन्ही टोके स्थापित टनेलची नोंद देतात, दूरची शाखा गेटवेमधून उत्तर देते, आणि एका बाजूच्या वापरकर्त्यांसाठी ॲप्लिकेशन तरीही वेळ संपते। नेहमीचा सल्ला दोन्ही दिशांना फायरवॉल नियम जोडण्याचा असतो। कधी ते बरोबर असते, कधी तो आधीपासून असलेल्या नियमाची पुनरावृत्ती करतो, आणि कधी दुसरा नियमच स्टेट तोडतो। कोणती स्थिती लागू होते हे फायरवॉल पॅकेट कुठे पाहतो यावर अवलंबून आहे।

स्टेटफुल परतीचा रहदारी संख्या बदलतो

स्टेटफुल फायरवॉल विनंती नोंदवतो आणि दुसऱ्या नियमाशिवाय प्रतिसाद सोडतो, म्हणून फक्त एक नियम लागणारी रचना सामान्य आहे। स्टेटलेस प्रवेश सूचीत अशी स्मृती नसते, आणि प्रतिसादाला स्पष्ट परवानगी द्यावी लागते। दोन्ही आपापल्या प्लॅटफॉर्मवर बरोबर आहेत, म्हणून सल्ले एकमेकांशी विसंगत आहेत।

तुमच्यासमोरच्या प्लॅटफॉर्मचे फॉरवर्डिंग दस्तऐवज वाचा, आणि तुम्ही संपादित करत असलेले धोरण पॅकेट पाहण्याच्या ठिकाणी स्टेटफुल आहे का ते तपासा। स्थापित रहदारीवर स्पष्ट बंदी, किंवा स्टेट तक्त्यापूर्वी प्रतिसादाचे मूल्यांकन करणारा नियम क्रम, कार्यरत रचनेला कोडे बनवतो। नियमांची संख्या अंमलबजावणीचा तपशील आहे, तर आवश्यकता ही आहे की परवानगी असलेल्या संभाषणाच्या दोन्ही दिशा पूर्ण होऊ शकतील।

फायरवॉल डिक्रिप्ट केलेले पॅकेट कुठे पाहतो

धोरण-आधारित टनेलमध्ये फायरवॉल डिक्रिप्शनपूर्वी एन्क्रिप्टेड पॅकेट आणि त्यानंतर डिक्रिप्ट केलेल्या पॅकेटचे, वेगवेगळ्या इंटरफेसवर मूल्यांकन करू शकतो। चुकीच्या इंटरफेससाठी लिहिलेला नियम उपस्थित असतो, बरोबर असतो आणि कधीही जुळत नाही। अशा प्रकारे कार्यरत उपयोजनातून नकल केलेला नियम-संच समान हार्डवेअरवर अपयशी ठरू शकतो।

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

असममित राउटिंग गृहीत तोडते

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

दोन्ही बाजूंना व्यापक परवानगी नियम जोडण्यापूर्वी प्रतिसादाचा मार्ग तपासा। प्रत्येक इंटरफेसवर सर्व काही सहन करणे राउटिंग चूक लपवते आणि त्याच वेळी प्रवेश वाढवते, हे उपलब्ध सर्वात वाईट संयोजन आहे।

खऱ्या स्रोत पत्त्यांसह दोन्ही दिशा तपासा

दूरची बाजू प्रत्यक्षात जो पत्ता पाहते त्याने चाचणी करा, कारण भाषांतरामुळे स्रोत नियमाला कशाशीही जुळणी होणार नाही। दोन्ही गेटवेवर एकाच वेळी कॅप्चर चालवा।

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

दूरच्या गेटवेवर अनपेक्षित स्रोत पत्त्यासह दिसणारी विनंती कधीही न जुळणारा नियम स्पष्ट करते, आणि चुकीच्या इंटरफेसवर येणारा प्रतिसाद स्टेटची विसंगती स्पष्ट करतो। नंतर मंजूर व्याप्तीत एक गंतव्य आणि त्याबाहेर एक तपासा, जेणेकरून सीमा गृहीत न धरता दाखवली जाईल।

भाषांतरानंतरचा स्रोत पत्ता, डिक्रिप्ट केलेल्या पॅकेटने वापरलेला इंटरफेस आणि जुळलेला नियम नोंदवा। ती तीन तथ्ये संपूर्ण तपासणी न करता पुढील तिकिटाचे उत्तर देतात।