साइट-से-साइट 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

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

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