ASA साइट-टू-साइट VPN वरून अंतर्गत सेवा प्रकाशित करणे

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

तपासणी 1: टनेल स्रोताच्या पत्त्याचे संरक्षण करते

आधीच रहदारी पाठवणाऱ्या टनेलपासून सुरुवात करा, नंतर तुम्ही प्रकाशित करायच्या पत्त्याची संरक्षित श्रेणीत आहे याची खात्री करा। ASA वर ती श्रेणी क्रिप्टो ACL मधून किंवा VTI च्या मार्गांमधून येते, आणि तिने स्रोताचा खरा पत्ता व्यापला पाहिजे, शाखा व्यवस्थापनासाठी वापरत असलेला सबनेट नाही। स्रोत चुकवणारा निवडक तुम्हाला वर असलेले टनेल आणि त्यात कधीही न शिरणारा प्रवाह देतो।

भाषांतराला हात लावण्यापूर्वी टनेल काउंटर आणि मार्ग सारणीने हे तपासा। जर हबपासून टनेलमार्गे स्रोत गाठता येत नसेल, तर या यादीत पुढे काहीही ते दुरुस्त करू शकत नाही।

संरक्षित श्रेणी आणि स्रोताचा पत्ता जुळत नसल्यास इथे थांबा।

तपासणी 2: शाखेला कोणता स्रोत दिसेल ते ठरवा

शाखेला क्लायंटचा मूळ पत्ता किंवा भाषांतरित पत्ता दिसतो, आणि ती निवड परतीचा मार्ग ठरवते। क्लायंटचा पत्ता जपून ठेवल्यास स्रोताच्या नोंदींमध्ये ते स्वच्छ दिसते, पण मग शाखेला सार्वजनिक क्लायंटसाठीचे प्रतिसाद टनेलमार्गे परत पाठवावे लागतात; सामान्य इंटरनेट डीफॉल्ट ते दुसऱ्या दिशेने पाठवतो आणि कनेक्शन एका दिशेने मरते। स्रोताचे अशा पत्त्यात भाषांतर करणे, ज्याकडे शाखा आधीच टनेलमार्गे मार्गक्रमण करते, ती अट काढून टाकते।

भाषांतर स्रोत काय नोंदवू शकतो आणि स्रोत-आधारित नियम कशाशी जुळू शकतात हेही बदलते। अनुप्रयोगाला विनंतीमागील व्यक्ती जाणून घ्यायची असेल, तर त्याची जागा प्रमाणित रिव्हर्स प्रॉक्सी आहे, NAT चा निर्णय नाही।

तपासणी 3: खऱ्या इंटरफेसांनुसार भाषांतर लिहा

ASA भाषांतर नियमांचे क्रमाने मूल्यांकन करते आणि कोणता जुळला ते सांगते, म्हणून नियमातील इंटरफेसची जोडी सजावटीची नाही। बाहेरून आतल्या मार्गासाठी लिहिलेला नियम, तुम्ही गृहीत धरलेल्यांपेक्षा वेगळे प्रवेश आणि निर्गम असलेल्या प्रवाहाशी जुळणार नाही।

तुम्ही बांधत असलेल्या मार्गाला चार भाग आहेत, आणि चारही जुळले पाहिजेत:

त्या सारणीतील श्रेणी प्लेसहोल्डर माना। महत्त्वाचे हे की भाषांतरानंतरचा ट्युपल हा शाखा टनेलमार्गे स्वीकारणारा पत्ता असेल, आणि NAT स्थितीत उलट मॅपिंग असेल जेणेकरून बाहेर जाताना प्रतिसाद पुनर्संचयित होईल।

तपासणी 4: प्रवेश नियम प्रकाशित पोर्टपुरता मर्यादित करा

पोर्ट प्रकाशित करा, होस्ट नाही। प्रत्येक सेवेवर स्रोताला अनुमती देणारा नियम एका प्रकाशित अनुप्रयोगाचे स्रोत चालवत असलेल्या सर्व गोष्टींकडे जाणारा मार्ग बनवतो, ज्यात तुम्ही जाणूनबुजून इंटरनेटबाहेर ठेवलेला व्यवस्थापन इंटरफेसही येतो। भाषांतरित स्रोतापासून स्रोतापर्यंत प्रकाशित पोर्टला अनुमती द्या, आणि प्रशासकीय सेवा त्यांच्या फक्त-VPN मार्गावर ठेवा।

त्याच वेळी नियमांचा क्रम तपासा। तुमच्या विशिष्ट नियमाच्या वर बसलेली व्यापक अनुमती विशिष्ट नियम अदृश्य करते।

तपासणी 5: एक विनंती आणि तिचा प्रतिसाद शोधा

ब्राउझरने सुरुवात करू नका, कारण ब्राउझर कोणता भाग अपयशी झाला हे लपवतो। हबवर प्रवाह शोधा आणि काहीही बदलण्यापूर्वी निकाल वाचा।

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

शोध जुळलेले भाषांतर, प्रवाहाला अनुमती देणारा किंवा नाकारणारा प्रवेश नियम, आणि पॅकेट टनेलमध्ये मार्गक्रमण झाले का हे सांगतो। प्रवाह तुम्ही अपेक्षा न केलेल्या इंटरफेसातून बाहेर पडत असल्याचे दाखवल्यास, NAT नियमातील इंटरफेसची जोडी चुकीची आहे। नकार दाखवल्यास, नियमांचा क्रम चुकीचा आहे। ते टनेलपर्यंत पोहोचले पण स्रोत कधीही उत्तर देत नसेल, तर समस्या शाखेचा परतीचा मार्ग आहे।

मग बाहेरून एक खरी विनंती पाठवा आणि प्रतिसाद त्याच टनेलमार्गे परत येतो याची खात्री करा। प्रकाशित नोंद, भाषांतर, संरक्षित पत्त्यांची जोडी आणि परतीचा मार्ग प्रकाशन अभिलेख म्हणून नोंदवा।