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 ACL, VPN फिल्टर, uRPF आणि IPsec बनावट तपासण्या व्यापणारा bypass-checks पर्याय दस्तऐवजीकरण करते। त्या वगळून मिळालेला ALLOW म्हणतो की मार्ग आणि NAT काम करतील, असे नाही की धोरण खरा पॅकेट स्वीकारेल। निकालाच्या शेजारी पर्याय नोंदवा।

धोरणाचे उत्तर हवे असल्यास बायपासशिवाय चालवा। मार्गनिर्देशनाचा प्रश्न वेगळा करत असाल तर त्यांच्यासह चालवा आणि निकालाला मार्गनिर्देशन उत्तर म्हणून लेबल करा।

टप्पा 5: खऱ्या देवाणघेवाणीने अंतर भरा

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

काही trace आणि replay पर्याय पॅकेट पाठवतात किंवा स्थिती टिकवतात। प्रत्येक प्रकाराला फक्त-वाचन शोध मानण्याऐवजी तुमच्या आवृत्तीसाठी आणि मंजूर निदान प्रक्रियेसाठी दस्तऐवजीकृत वर्तनाचे पालन करा।

ट्रेस अजूनही तुम्हाला काय सांगू शकत नाही

एका नोंदीत चार गोष्टी ठेवा: टपल, जुळणारा NAT नियम, प्रवाह वाहून नेणारा बोगदा किंवा धोरण, आणि दिशेस विशिष्ट निरीक्षण। त्यांशिवाय पुढील अभियंता स्थानिक धोरण निर्णयाला प्रस्थापित नियंत्रण तल आणि कार्यरत सेवेपासून वेगळा करू शकत नाही। पहिल्या अपयशानंतरचे यश हे देखील पुरावा नाही की बोगदा त्या दरम्यान उभा राहिलाच पाहिजे होता; टप्पा आणि स्थिती बदल नोंदवा।

आतील टपलपासून सुरुवात करा, रचनेच्या विरुद्ध जाणाऱ्या पहिल्या टप्प्यावर थांबा, आणि त्यानंतरच एंडपॉइंट पुराव्याकडे जा। ट्रेस धोरणाचा ओरॅकल आहे, वितरण पावती नाही।