Cisco ASA टनेल्ड डीफॉल्ट रूट: ते प्रत्यक्षात कधी लागू होते

रिमोट-अ‍ॅक्सेस वापरकर्त्याला ASA च्या पलीकडे काहीही पोहोचत नाही, तर तोच सर्व्हर आतील LAN मधून येणाऱ्या पिंगला उत्तर देतो. टनेल उभे राहते, क्लायंटला pool मधून पत्ता मिळतो, तरीही पॅकेट इंटरनेट डीफॉल्टमधूनच बाहेर पडते किंवा गायब होते. हा नमुना सहसा असा अर्थ देतो की डिक्रिप्ट केलेल्या रहदारीला स्वतःचा रूट सापडला नाही आणि ती सामान्य डीफॉल्टवर पडली. दुरुस्ती हा आणखी एक NAT नियम नाही; दुरुस्ती म्हणजे टनेल्ड डीफॉल्ट.

कॉन्फिगपासून नाही, लक्षणापासून सुरुवात करा

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

show vpn-sessiondb मध्ये टनेल निरोगी दिसते, आणि म्हणूनच लोक IKE डीबग करत राहतात.

ACL ड्रॉपपासून याला वेगळे करणारी गोष्ट दिशा आहे. ACL ड्रॉप लॉग होतो व मोजला जातो, तर गहाळ रूट जुळणारी नोंद नसलेली शोध-अयशस्वीता निर्माण करतो. क्लायंटच्या गंतव्यासाठी show route चालवा आणि ASA ने प्रत्यक्षात काय निवडले ते वाचा, डीफॉल्ट निवडला गेला का आणि कोणता, हेदेखील.

टनेल्ड शोध वेगळा कसा आहे

Cisco च्या ASA 9.23 स्टॅटिक-राउटिंग मार्गदर्शकात स्टॅटिक किंवा शिकलेला रूट नसलेल्या डिक्रिप्ट केलेल्या VPN रहदारीसाठी स्वतंत्र डीफॉल्टचे दस्तऐवजीकरण आहे. tunneled कीवर्ड त्या रूटला चिन्हांकित करतो, त्यामुळे डिक्रिप्ट केलेले पॅकेट ASA स्वतःच्या ट्रान्सपोर्टसाठी वापरतो त्या पुढील हॉपपेक्षा वेगळ्या हॉपवर पडू शकते. अधिक विशिष्ट रूट तरीही जिंकतात, म्हणूनच क्लायंट अंतर्गत गेटवेमार्फत 10.0.0.0/8 पर्यंत पोहोचू शकतो आणि बाकी सर्व गमावू शकतो.

किमान मांडणी वेगवेगळ्या पुढील हॉपसह दोन डीफॉल्ट ठेवते. एक ASA ची स्वतःची रहदारी नेते, दुसरा अधिक चांगला रूट नसलेली डिक्रिप्ट केलेली रहदारी नेते. दोन्ही पुढील हॉप तुम्ही ज्या इंटरफेसला जोडता तिथून पोहोचण्यायोग्य असलेच पाहिजेत.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

दोन्ही डीफॉल्ट एकाच पुढील हॉपकडे निर्देश करत असतील, तर कीवर्ड काहीच बदलत नाही आणि लक्षण हलणार नाही.

ते चालेल की नाही हे ठरवणारे निर्बंध

तोच मार्गदर्शक फक्त एका टनेल्ड डीफॉल्टला परवानगी देतो आणि त्यासाठी ECMP समर्थित नाही असे सांगतो, त्यामुळे त्या मार्गावर भार विभागता येत नाही. तो रूट ट्रॅकिंग, रिव्हर्स-पाथ पडताळणी आणि काही इन्स्पेक्शन व व्यवस्थापन प्रवाहांशी संबंधित निर्बंधही सूचीबद्ध करतो. वैशिष्ट्याभोवती रचना करण्यापूर्वी ते तुमच्या इन्स्टॉल केलेल्या रिलीझच्या तुलनेत वाचा. ते दुर्लक्षित करणारी रचना सहसा सर्वत्र नाही, तर एका विशिष्ट ठिकाणी अयशस्वी होते, म्हणूनच लक्षण अधूनमधून येणारे वाटते.

असममित रचनांमध्ये रिव्हर्स-पाथ पडताळणीच सर्वात जास्त चावते. उत्तर ASA अपेक्षित असलेल्या इंटरफेसपेक्षा वेगळ्या इंटरफेसने आले तर राउटिंग महत्त्वाचे होण्याआधीच पॅकेट टाकाऊन दिले जाते. पडताळणी बंद करून पुढील हॉप लादण्याऐवजी टोपोलॉजी किंवा परतीचा मार्ग दुरुस्त करा.

रूट ट्रॅकिंग हा वेगळा सापळा आहे: ट्रॅक केलेला ऑब्जेक्ट सहसा सामान्य डीफॉल्टचे रक्षण करतो, टनेल्डचे नाही.

कीवर्ड काय करत नाही

IKE बांधण्यासाठी ASA वापरत असलेला स्रोत पत्ता तो निवडत नाही. बाहेरील टनेल टोक प्लॅटफॉर्मच्या स्वतःच्या इंटरफेस व स्रोत निवडीचे अनुसरण करते, आणि त्या निर्णयात टनेल्ड डीफॉल्टचा काही वाटा नाही. तो बदलल्याने चुकीच्या पत्त्यावरून सुरू होणारा phase 1 बरा होणार नाही.

ते पुढील हॉपचा प्रॉक्सीही करत नाही. गंतव्याला HTTP CONNECT देवाणघेवाण अपेक्षित असेल, तर प्रॉक्सी होस्टला कच्चे IP पॅकेट पाठवल्याने त्यांचे राउटिंग न करणारा होस्टच मिळतो. त्याऐवजी क्लायंटला समर्थित प्रॉक्सी यंत्रणा कॉन्फिगर करा.

आणि ते खालच्या दिशेने फॉरवर्डिंग तयार करत नाही. तुम्ही निर्देश करता त्या गेटवेला अजूनही VPN pool कडे परतीचा रूट लागतो, शिवाय रचना जिथे मागते तिथे स्रोत भाषांतरही लागते.

मार्ग सुरुवातीपासून शेवटपर्यंत पडताळा

रूट बसवल्यानंतर चार गोष्टी क्रमाने तपासा: pool ला लागणाऱ्या गंतव्यासाठी show route, नवीन पुढील हॉपच्या दिशेने असलेल्या इंटरफेसवर कॅप्चर, गेटवेवरच कॅप्चर, आणि त्या गेटवेपासून pool च्या पत्त्यापर्यंत परतीचा मार्ग. पहिले दोन ASA ने तो मार्ग निवडला हे सिद्ध करतात, शेवटचे दोन तिथे कोणीतरी उत्तर देत आहे हे सिद्ध करतात.

गेटवे उत्तर देतो पण क्लायंटला कधीच उत्तर दिसत नाही, तर राउटिंग टेबलला पुन्हा हात लावण्यापूर्वी स्रोत भाषांतर आणि परतीचा रूट पहा.

तुम्ही पडताळणी केलेली रिलीझ नोंदवा, कारण निर्बंधांची यादी आवृत्तीनुसार वेगळी असते आणि एका ट्रेनवर चालणाऱ्या रचनेला दुसरीकडे वेगळा मार्ग लागू शकतो. ती नोंद कॉन्फिग स्निपेटपेक्षा जास्त काळ टिकते.