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

टाढाको गेटवेमा अप्रत्याशित स्रोत ठेगानासहित देखा पर्ने अनुरोधले कहिल्यै नमिल्ने नियम व्याख्या गर्छ, र गलत इन्टरफेसमा आउने जवाफले स्टेटको अमिलता व्याख्या गर्छ। त्यसपछि स्वीकृत दायराभित्र एउटा गन्तव्य र बाहिर एउटा परीक्षण गर्नुहोस्, ताकि सीमा अनुमान नगरी देखाइयोस्।

अनुवादपछिको स्रोत ठेगाना, डिक्रिप्ट गरिएको प्याकेटले प्रयोग गरेको इन्टरफेस र मिलेको नियम रेकर्ड गर्नुहोस्। ती तीन तथ्यले पूरै अनुसन्धान नदोहोर्याई अर्को टिकटको जवाफ दिन्छन्।