क्या अपस्ट्रीम राउटर वास्तव में इनबाउंड VPN पोर्ट पहुँचाता है?

तीन शर्तें तय करती हैं कि लैब राउटर पर पोर्ट फ़ॉरवर्ड कुछ प्रकाशित करेगा या नहीं: अपस्ट्रीम एज क्या पहुँचाता है, कौन सी नीति लागू करता है, और क्या उत्तर उसी मार्ग से लौटते हैं। सार्वजनिक दिखने वाला पता इनमें से किसी का उत्तर नहीं देता। /30 प्रीफ़िक्स या काम करने वाला आउटबाउंड कनेक्शन भी नहीं। NAT बदलने से पहले उन शर्तों को क्रम में रखें, वरना स्थानीय नियम टूटा दिखेगा जबकि ब्लॉक दो हॉप दूर बैठा है।

तीन उत्तर तय करते हैं कि आप किसे एस्केलेट करेंगे

अपस्ट्रीम मालिक हैंड-ऑफ़ को तीन में से किसी एक तरीके से बता सकता है। गंतव्य सीधे आपके इंटरफ़ेस पर पहुँचाया जाता है, अलग प्रीफ़िक्स आपके अगले हॉप पर रूट किया जाता है, या आगे कुछ आपके पास पहुँचने से पहले पते का अनुवाद करता है। हर उत्तर एक अलग डिवाइस का नाम देता है जिसे इनबाउंड कनेक्शन की अनुमति देनी होती है, और एक अलग टीम का जिसे फ़ोन करना होता है जब ऐसा नहीं होता।

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

हैंड-ऑफ़ को सेवा अनुबंध की तरह पढ़ें

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

IETF की फ़ायरवॉल-व्यवहार चर्चा एक उपयोगी याद दिलाती है कि फ़िल्टरिंग और अनुवाद अलग कार्य हैं। यह समझाती है कि राउटर पते छिपाए बिना इनबाउंड नीति कैसे लागू कर सकता है, और यह क्यों सिद्ध नहीं होता कि ऊपर कहीं NAT होने से फ़िल्टरिंग वहीं हो रही है। हैंड-ऑफ़ को मालिक और परिवर्तन प्रक्रिया वाले सेवा विवरण की तरह लें।

दोनों सीमाओं पर एक प्रयास देखें

दो बिंदुओं पर सहसंबद्ध एक संकीर्ण, स्वीकृत प्रयास अंदाज़ों के ढेर की जगह लेता है। सटीक टपल के लिए लैब WAN इंटरफ़ेस पर कैप्चर चलाएँ, और अपस्ट्रीम मालिक से वही टपल एज पर देखने को कहें। दोनों दृश्यों के बीच गंतव्य, प्रोटोकॉल, पोर्ट, स्रोत और टाइमस्टैम्प समान रखें।

tcpdump -ni wan0 'tcp port 1194 and host 203.0.113.10'

परिणामों की जोड़ी को निर्णय की तरह पढ़ें। एज पर दिखा और लैब WAN पर दिखा इसका अर्थ है कि डिलीवरी और एज नीति दोनों पार हुईं, इसलिए लिसनर या DNAT के साथ आगे बढ़ें। एज पर दिखा पर लैब WAN पर नहीं दिखा डिलीवरी या मध्यवर्ती नीति की ओर इशारा करता है, और अगली कॉल अपस्ट्रीम मालिक को है। कहीं नहीं दिखा इसका अर्थ है कि फ़ायरवॉल प्रश्न से पहले ही टेस्ट टपल, स्रोत या मार्ग ग़लत है।

एक कैप्चर में प्रमाण का अभाव फ़ायरवॉल का प्रमाण नहीं है। यह सीमा का परिणाम है जो बताता है कि आगे कौन सा डिवाइस जाँचना है।

स्थानीय NAT को उत्तर छिपाने न दें

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

जाँच के दौरान पोर्ट सुरक्षा और उत्पादन हैंड-ऑफ़ बनाए रखें। अटैचमेंट नियंत्रणों को दरकिनार करने के लिए राउटर बदलना या उसका MAC पता नक़ली बनाना निदान को रुकावट से बदल देता है। मिरर पोर्ट या स्वीकृत कैप्चर लिंक साझा करने वाली सेवाओं को डिस्कनेक्ट किए बिना वही दृश्यता देता है।

स्वामित्व मानचित्र के साथ समाप्त करें: गंतव्य, पहुँचाने वाला डिवाइस, फ़िल्टर करने वाला डिवाइस, लैब इनग्रेस और लिसनर। यह मानचित्र अगली पोर्ट-फ़ॉरवर्ड समीक्षा को छोटा बनाता है, और यह VPN के बारे में कुछ भी प्रमाणित नहीं करता।