ASA hairpin: इंटरनेट एग्झिट की साइट-टू-साइट VPN लेग?

एकाच ASA मागील दोन रिमोट-अ‍ॅक्सेस वापरकर्ते एकाच बाह्य इंटरफेसवरून ट्राफिक पाठवू शकतात आणि पूर्णपणे वेगळी वागणूक मिळवू शकतात. एकजण सार्वजनिक वेबसाइटकडे जात आहे, त्यामुळे पॅकेटला स्रोत भाषांतर आणि इंटरनेट रूट आवश्यक आहे. दुसरा त्याच इंटरफेसवर संपणाऱ्या साइट-टू-साइट टनेलमागील सर्व्हरकडे जात आहे, त्यामुळे पॅकेटला ओळख, जुळणारा टनेल सिलेक्टर आणि क्लायंट पूलकडे परतीचा मार्ग आवश्यक आहे. एकाच इंटरफेसची परवानगी दोन्हींसाठी पूर्वअट आहे आणि कोणासाठीही उपाय नाही.

दोन लेग, एक इंटरफेस

NAT नियम लिहिण्यापूर्वी कोणता लेग बांधत आहात ते ठरवा, कारण नियम परस्पर बदलण्यायोग्य नाहीत. लेग A क्लायंटकडून इंटरनेटकडे आहे: पूलचा पत्ता आत, भाषांतरित सार्वजनिक पत्ता बाहेर, त्याच इंटरफेसवरून परत. लेग B क्लायंटकडून दुसऱ्या IPsec पीअरच्या पलीकडील खाजगी प्रिफिक्सकडे आहे: पूलचा पत्ता जपला जातो, पुन्हा एन्क्रिप्ट होतो आणि पूलला कसे उत्तर द्यायचे हे माहीत असलेल्या पीअरला दिला जातो.

दोन्हींना प्रथम जे आवश्यक आहे ते म्हणजे एकाच इंटरफेसची परवानगी. ती नसल्यास ASA पॅकेट ज्या इंटरफेसवर आले तिथून पुढे पाठवण्यास नकार देते, आणि अपयश धोरणाच्या ऐवजी राउटिंगची समस्या वाटते:

same-security-traffic permit intra-interface

ती एक ओळ पाठवण्याच्या रचनेला परवानगी देते, जसे ASA NAT संदर्भ एकाच इंटरफेसच्या मार्गांसाठी वर्णन करतो. ती क्लायंट रूट जोडत नाही, संसाधनाला परवानगी देत नाही, पत्ता भाषांतरित करत नाही किंवा IPsec सिलेक्टरवर वाटाघाटी करत नाही, त्यामुळे त्यानंतर आणखी तीन किंवा चार गोष्टी जोडण्याची अपेक्षा ठेवा आणि त्याची स्वीकृती प्रगती म्हणून वाचू नका.

लेग A: क्लायंटला इंटरनेट हवे आहे

इंटरनेट एग्झिटसाठी पॅकेट उपकरण सोडण्यापूर्वी पूलचा पत्ता खाजगी राहणे थांबवले पाहिजे. सामान्य PAT रचनेत नियम पूलचे बाह्य इंटरफेसच्या पत्त्यात भाषांतर करतो, आणि परतीची स्थिती क्लायंटकडील प्रवाह पुनर्संचयित करते:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

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

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

लेग B: क्लायंटला खाजगी साइट हवी आहे

हा लेग अधिक ठिकाणी अयशस्वी होतो, म्हणून तो क्रमाने लिहा. प्रथम क्लायंट रूट: गंतव्य प्रिफिक्स स्प्लिट-टनेल यादीत असणे आवश्यक आहे, अन्यथा क्लायंट तो टनेलमध्ये ठेवणार नाही. दुसरे टनेल सिलेक्टर: साइट-टू-साइट क्रिप्टो ACL ने पूलच्या पत्त्यापासून दूरच्या प्रिफिक्सपर्यंत व्यापले पाहिजे, केवळ स्थानिक LAN पासून दूरच्या प्रिफिक्सपर्यंत नाही. तिसरे ओळख, जेणेकरून पूलचा पत्ता वाटेत इंटरनेट PAT मध्ये भाषांतरित होणार नाही.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

दूरची बाजू हा लोक विसरतात तो भाग आहे. पीअरला पूलकडे परतीचा रूट आणि तो समाविष्ट करणारा सिलेक्टर आवश्यक आहे, आणि त्याच्या स्वतःच्या धोरणाने त्याला दिसणाऱ्या स्रोत पत्त्यांना परवानगी दिली पाहिजे. साइट ऐवजी भाषांतरित दृश्यातून वापरली जात असल्यास ती वैध रचना आहे, परंतु तेव्हा दोन्ही पीअर, दोन्ही सिलेक्टर आणि दोन्ही राउटिंग तक्त्यांनी भाषांतरित पत्त्यांबाबत सहमत असले पाहिजे.

नियमांचा क्रमही तपासा. ओळख नियमाच्या वरचा व्यापक PAT नियम खाजगी देवाणघेवाण ओळख नियमाचे मूल्यांकन होण्यापूर्वीच भाषांतरित करेल, आणि लक्षण NAT त्रुटी नसून जुळणारे SA नसलेले साइट टनेल असेल.

तुम्ही कोणता लेग बांधला हे सांगणारी चाचणी

कॉन्फिगरेशन वाचून अपेक्षा ठेवण्याऐवजी ASA चे स्वतःचे मार्ग मूल्यमापन वापरा. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed एका प्रवाहासाठी NAT निर्णय, रूट आणि ACL निकाल दाखवते; खाजगी गंतव्यासह ते पुन्हा करा. NAT टप्पा खाजगी-ते-खाजगी प्रवाह पुन्हा लिहीत असेल, तर लेग B आवश्यक असलेल्या पॅकेटसाठी तुम्ही लेग A बांधला आहे.

आणखी दोन आदेश अंतर बुजवतात. show nat detail packet-tracer ने अनुसरलेला नियम क्रम छापते, आणि show crypto ipsec sa तुम्ही अपेक्षित असलेल्या जोडीसाठी सिलेक्टर आहे का ते दाखवते. गहाळ SA हा सिलेक्टर किंवा पीअर कॉन्फिगरेशनचा प्रश्न आहे, NAT नियम दुरुस्त करू शकतो अशी गोष्ट नाही.

प्रत्येक लेगची त्याची सेवा करणाऱ्या ट्राफिकने पडताळणी करा

लेग A क्लायंटच्या सामान्य सार्वजनिक विनंतीने स्वीकारा, आणि लेग B खरोखर अस्तित्वात असलेल्या खाजगी संसाधनाच्या विनंतीने स्वीकारा. नंतर प्रत्येकाची नाकारलेल्या संसाधनासह पुनरावृत्ती करा, कारण “परवानगी दिली” आणि “अ‍ॅक्सेस धोरणाने मंजूर केले” हे एकच पुरावा नाही, आणि हबमधून निघणारा ping क्लायंट मार्गांपैकी कोणत्याही मार्गाचा सराव करत नाही.

तिकिटात दोन्ही चाचणी नोंदी वेगळ्या ठेवा: स्रोत पत्ता, गंतव्य, जुळलेला NAT नियम आणि निकाल. पुढील अहवाल “VPN तुटले आहे” असे म्हणेल तेव्हा ती जोडी एका मिनिटात कोणता लेग मागे पडला ते सांगते, आणि उत्तर सहसा रूट किंवा सिलेक्टर असते, सर्वांनी प्रथम संशय घेतलेली तीच-इंटरफेस ओळ नाही.