ASA packet-tracer से VPN प्रवाह को कैसे मॉडल करें

ASA पर packet-tracer एक संकीर्ण प्रश्न का उत्तर देता है: क्या यह पैकेट, यहाँ इस टपल के साथ प्रवेश करते हुए, अनुमत होगा और यह कहाँ जाएगा। यह उत्तर नहीं देता कि दूर का सिरा कुछ प्राप्त करता है या नहीं। सामान्य गलती यह है कि बाहरी IKE टपल दिया जाए जबकि जिस चीज़ का परीक्षण करना है वह टनल के भीतर चलने वाला अनुप्रयोग है। पहले टपल ठीक करें, चरण पढ़ें, और फिर सिम्युलेटर जो नहीं देख सकता उस सब के लिए वास्तविक प्रमाण लें।

नीचे दिया गया दौरा मानता है कि ACL, NAT नियम और tunnel-group संदर्भ आपके सामने हैं। उनके बिना आउटपुट ऐसी नीति का वर्णन करता है जिसे आप जाँच नहीं सकते।

चरण 1: भीतरी प्रवाह सरल शब्दों में लिखें

कुछ भी टाइप करने से पहले अनुप्रयोग का वर्णन करें। भीतर का होस्ट जो दूर के गेटवे के पीछे के सर्वर के लिए SSH खोलता है, एक विशिष्ट स्रोत पोर्ट वाला एक भीतरी TCP प्रवाह है। यही वह प्रवाह है जिसका मूल्यांकन ACL और VPN फ़िल्टर करते हैं, इसलिए यही वह प्रवाह है जिसे आप टाइप करते हैं।

इसे एक वाक्य के रूप में लिखें, फिर क्षेत्र-दर-क्षेत्र अनुवाद करें:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

चरण 2: प्रवेश इंटरफ़ेस और दिशा चुनें

प्रवेश वह इंटरफ़ेस है जिस पर पैकेट आता है, न कि वह जिससे वह जाता है। आरंभ करने वाले LAN होस्ट के लिए यह inside इंटरफ़ेस है। उसी सत्र के वापसी पैकेट के लिए यह outside इंटरफ़ेस है, और टपल उलट जाता है। गंतव्य को स्रोत के रूप में लिखना विश्वसनीय पर अप्रासंगिक ALLOW पाने का दूसरा सबसे सामान्य तरीका है।

पोर्ट भी दिशा-आधारित हैं। आरंभ किए गए अनुरोध में सेवा पोर्ट गंतव्य क्षेत्र में आता है, और क्लाइंट का अस्थायी पोर्ट स्रोत क्षेत्र में आता है। TCP गंतव्य 500 वाला मॉडल 500 पर सुनने वाले TCP अनुप्रयोग का वर्णन करता है; केवल कमांड में संख्या दिखने से वह IKE परीक्षण नहीं बनता।

चरण 3: चरणों को क्रम से पढ़ें

आउटपुट का प्रत्येक चरण स्वामी वाला निर्णय है: रूट लुकअप, ACL, NAT, फिर VPN या टनल का चयन। उन्हें मुद्रित क्रम में पढ़ें और डिज़ाइन से न मेल खाने वाले पहले चरण पर रुकें।

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

चरण 4: जाँचें कि आपने कौन-से बायपास चुने

detailed रूप ऐसे विकल्प लेता है जो जाँचें छोड़ देते हैं, और Cisco bypass-checks विकल्प का दस्तावेज़ीकरण करता है जो ACL, VPN फ़िल्टर, uRPF और IPsec स्पूफ़ जाँचों को कवर करता है। उन्हें छोड़कर प्राप्त ALLOW कहता है कि रूट और NAT काम करेंगे, यह नहीं कि नीति वास्तविक पैकेट स्वीकार करेगी। परिणाम के बगल में विकल्प लिखें।

यदि आपको नीति का उत्तर चाहिए, तो बायपास के बिना चलाएँ। यदि आप रूटिंग प्रश्न अलग कर रहे हैं, तो उनके साथ चलाएँ और परिणाम को रूटिंग उत्तर के रूप में लेबल करें।

चरण 5: वास्तविक विनिमय से अंतराल भरें

सिम्युलेटेड अनुमति ASA पर रुक जाती है। दूर के गेटवे ने पैकेट डिक्रिप्ट किया या नहीं, सर्वर ने कनेक्शन स्वीकार किया या नहीं, और उत्तर वापस आया या नहीं, ये अलग अवलोकन हैं। एंडपॉइंट काउंटर का उपयोग करें या स्वीकृत पथ पर एक संकीर्ण कैप्चर।

कुछ trace और replay विकल्प पैकेट भेजते हैं या स्थिति बनाए रखते हैं। हर प्रकार को केवल-पढ़ने वाली खोज मानने के बजाय अपने रिलीज़ और स्वीकृत निदान प्रक्रिया के दस्तावेज़ी व्यवहार का पालन करें।

ट्रेस अभी भी आपको क्या नहीं बता सकता

एक नोट में चार चीज़ें रखें: टपल, मेल खाता NAT नियम, वह टनल या नीति जो प्रवाह ले जानी चाहिए, और दिशा-विशिष्ट अवलोकन। उनके बिना बाद का इंजीनियर स्थानीय नीति निर्णय को स्थापित नियंत्रण तल और कार्यशील सेवा से अलग नहीं कर सकता। पहली विफलता के बाद सफलता भी इस बात का प्रमाण नहीं कि टनल को बीच में उठना ही था; चरण और स्थिति परिवर्तन लिखें।

भीतरी टपल से शुरू करें, डिज़ाइन का विरोध करने वाले पहले चरण पर रुकें, और तभी एंडपॉइंट प्रमाण की ओर बढ़ें। ट्रेस नीति का ओरेकल है, डिलीवरी रसीद नहीं।