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 नियम, प्रवाह बोक्नुपर्ने सुरुङ वा नीति, र दिशा-विशिष्ट अवलोकन। तिनीहरू बिना पछिको इन्जिनियरले स्थानीय नीति निर्णयलाई स्थापित नियन्त्रण तल र कार्यरत सेवाबाट अलग गर्न सक्दैन। पहिलो असफलतापछिको सफलता पनि सुरुङ बीचमा उठ्नैपर्ने प्रमाण होइन; चरण र स्थिति परिवर्तन लेख्नुहोस्।

भित्री टुपलबाट सुरु गर्नुहोस्, डिजाइनसँग बाझिने पहिलो चरणमा रोक्नुहोस्, र त्यसपछि मात्र एन्डप्वाइन्ट प्रमाणतर्फ जानुहोस्। ट्रेस नीतिको ओरेकल हो, डेलिभरी रसिद होइन।